Java 8 vs. Java 9 | Hacker News Reader

Java 8 vs. Java 9

romexsoft.com

I love Java. I think it has changed the world for the better.

That being said, I just can't get excited about new language features now that I have discovered Kotlin. It is essentially Java but with a much smarter compiler and a more modern and sane syntax.

Similarly, I can't get excited about Kotlin's features because they're all things I've been using for 5 years already in Scala.

Does Scala/sbt still take 5 years to compile moderately sized apps?

Kotlin syntax is a well-thought subset of Scala.

The designers basically removed everything that made Scala slow to process and hard to optimize. As a side-effect, Kotlin is much easier to read and understand than Scala.

They've had to add back a lot of things piecemeal as they realised they'd missed important use cases for Scala's more general features as they tried to "simplify" them. The language's history so far suggests the original design was far from well-thought, and I expect that trend to continue in a more visible way post-1.0.

(E.g. as applications get larger you tend to need to understand the reasons for why something didn't happen, so you move from Option on to using an Either-style type that carries some information in the failure case. But Kotlin is hardcoded around using null to express absence and it's impossible to migrate from that to something that includes a reason).

That's what I feel as well. I feel that Scala started "too big" and gets "slimmed down" over time (like, implicit is now not-so-recommended), while Kotlin goes the other way around. I still prefer Scala whenever possible, but Kotlin really shines for Android (I tried Scala, I couldn't stand build time on top of the already-long Android build).

> Kotlin is much easier to read and understand than Scala.

No. It's not.

I've programmed Scala professionally for the last 4 years. The compiler used to be rather slow, but nowadays, it is fast enough for my taste. Just be careful with the cake-pattern, which slows down compilation substantially.

Also, I notice that, as I write type-safe code, I don't usually compile that often and, when it compiles, it is likely correct.

It's down to 4 years give or take.

It has improved somewhat. Also with incremental compilation, compile times aren't really an issue.

I think it is on par with other "slow" language compilers that perform to inference: Kotlin, Swift, Haskell

The incremental compilation is pretty good.

ICE BURN

I used to like Java when it was simpler. Generics I thought were great, but the new features just seem like attempts to shoehorn features of dynamic languages onto a business language. And I still can't have multiline strings (on a language used for Web programming!).

The caretakers of Java strayed. Adopting goofy dynamic and lambda features, trying to attract the cool kids was a mistake.

They should have stuck to their original mission of reducing programming mistakes and boosting productivity.

String processing, a la perl, Python, is something every single developer does every day. We need multilines, intrinsics, first class regexes, etc. every day.

They should have made 'utf8', 'utf16', etc first class scalars, reducing the memory footprint of java.lang.String, and everything reliant on String, ages ago.

They should have increased conciseness, a la Kotlin, Ceylon, Nice, Boo (minus the duck typing), ages ago.

I'm also eager for lightweight objects (value types?), a la Kava, which I think has been pushed back to JDK 10.

The multi line issue pisses me off on a daily basis, esp when writing tests that deal with JSONs. It's so much readable with multi line strings in python and groovy.

I usually use groovy for my fun/toy projects but at my day job writing enterprise code the tests have huge JSON building blocks before the actual assertion happens.

Why not embed the JSON as a file in the test resources and read it in during the test setup? Is there a particular reason it needs to be embedded in the source code of the test?

Its to maintain context. If a developer is looking at a large test code then it becomes difficult to switch back and forth between 10s of JSON files and the main test code. Having the input, output and the test data in the same file is much more convenient.

Um, you really should be loading that sort of text/data from an external resource rather than embedding it in source code. Those sort of text blocks really don't belong in source code.

Why not? Why should a developer need to go through hoops like saving a string to a file then performing IO to load the string into a test case? What's the advantage of moving a string literal into a non-source file?

If I'm trying to test how my system will parse a specific JSON case into a domain object, isn't it easier to read if my test case is completely expressed on the screen?

The I/O will happen anyway, either at the start of the test when loading the compiled test program WITH the big chunk of a string or when reading it from disk, of course you'll add a bit of latency for opening the file itself but it's a very small price to be paid for maintainability.

Even when I develop in Python with multiline strings I use fixture files to better organise my code.

Edit: removed an "even" before maintainability that was part of a first draft.

This is just nonsense not everything will go into a file. Somethings are easier to read on the test itself. It's a case by case problem and choosing is a great asset.

> but the new features just seem like attempts to shoehorn features of dynamic languages onto a business language

None of the new features has anything to do with dynamic languages[0]. Streams and lambdas are still statically typed.

[0] Well, there is DynamicInvoke, but this is not a Java feature, but a JVM feature.

JEP 110: HTTP/2 Client

* The API and implementation will not be part of Java SE.

* The API will live under the jdk.incubtor namespace.

* The module will not resolve by default at compile or run time.

Modular source code is internal reorganization of JDK. Hopefully it will not affect Java developers negatively.

Process API: It can provide PIDs finally. Seems like big feature for Java 9.

JShell: May find some use. Not sure how many Java developer care about it.

re JShell. nodejs has raised my awareness of the joys of shell scripting. So something like this would be cool:

  #!/usr/bin/env java

For my own projects, I foresee replacing all those goofy build tools with straight Java. Less impedance mismatch.

Check out kotlin-script https://github.com/andrewoma/kotlin-script

It does not mention internals, changes in Unsafe or concurrency are pretty big deal

"Modular code"

I thought Jigsaw was rejected.

Rejected by Oracle's competitors. I'm pretty sure that Oracle will do what it does the best and be a dick and release it anyway. IMHO, that would be the right choice.

AFAIK, the core JVM will still be modular. The disagreements were around how to expand that modularity out of just the JVM "kernel" and into user space.

I'm not entirely sure what that actually buys, when classes are loaded only on demand anyway...

No, what what rejected was the lack of certain features due to OSGi political discussion.

However they have been talking how to solve this and the new release is planned for end September.

I think it just keep causing delays due to complexity.

It was started 10 years ago.

Nice summary. I'm pretty sure there is a new default GC as well.

No new GC but Java 9 makes the G1 collector the default GC

Ah, thanks for the clarification!

Site appears to be down, here's an archive/mirror: https://archive.is/6tger

I can't connect to the site... HN hug of death?

Works already. Fallen due to huge traffic.

WoW, it's 2017 and Java finally gets a REPL and it's only 30 years behind the market. Congratulations!

Java already had REPLs in the form of Beanshell, Groovy and Eclipse scratchpad.

It's 2017, where are the REPLs for Go and Rust?

I used a REPL in Java right around when they did the name change to J2SE, so that must have been 20 years ago? By the OPs definition it was still 10 years too late though so there is that.

Do you remember the name?

I know Java since the early releases and the only thing that comes to mind is Beanshell, which was around that time.

It was some third party thing I found on FTP servers at the time. It might have been Beanshell but I can't really recall.

Ah ok, thanks for the info.

I wrote this one a while ago - https://github.com/argonium/jsnip. May be helpful.

Although there's no REPL provided with Go, I've found that gore (https://github.com/motemen/gore) works pretty well. It feels similar to the old Java REPLs you'd find hidden in Intellij or other Java IDEs -- sometimes you can see the seams in its facade.

Interesting, thanks for pointing it out.

>It's 2017, where are the REPLs for Go and Rust?

Nobody's gonna make a REPL for languages nobody uses :^)

Could you explain when one would need Java REPL?

Also, are you familiar with Groovy and Scala and their intended uses?

> Could you explain when one would need Java REPL?

Like, all the time?

REPL becomes an integral part of the programming process if your language has one.

Not sure I understand, maybe your development process differs from mine.

Could you give me an actual example on how you use REPL during development?

For iteratively developing a piece of code. For quickly checking what a function X does with arguments Y and Z. For interactively manipulating a data structure until I finally know exactly what transformation I want to do, which I then save in the source code. For exploring and possibly modifying the run-time state of the program.

Simply being able to repeatedly invoke functions from the REPL without breaking your flow changes the way you program. It's a completely different experience from the usual edit->compile->run cycle, and even from the TDD edit->run tests cycle.

Also, if the language didn't just bolt a REPL on top of itself because it's fashionable, but actually was designed as an interactive programming medium, you'll have powerful introspection and runtime code modification possibilities that together speed up the debugging process. (Experienced readers will know which language families I have in mind here - the ones which surprisingly weren't even mentioned in JEP222 which this article links to).

This makes sense if you are using JavaScript or Python.

But not Java, which is statically typed and an IDE that takes care of most of the stuff you mentioned.

edit: java also has hot swapping of running code.

I do Java for my $dayjob and I can tell you that while IDE helps a lot with types and moving around the code, it doesn't give you interactivity offered by a proper REPL.

(Conversely, a language with a decent support for interactivity enables IDE developers to provide tools further enhancing interactive programming.)

Hot swapping breaks in arcane ways that most people won't bother searching how to avoid, code swap is simply considered unreliable by most of my colleagues. But this is anecdotally speaking, of course.

I'm also curious. I routinely use the Python REPL, for example; so it's not that I don't see how a REPL can be useful - it's that Java is so much more verbose that I find it difficult to imagine using a Java REPL. I struggle to think of a good use case for this.

Java is not that verbose anymore. Java 8, in particular, made the language much more concise. Also, I expect Java IDEs will offer their power of autocomplete to be usable in REPL too.

For you.

I've programmed in numerous languages that offer a REPL. I've never found them useful.

I'm sure you'll now tell me I was using the wrong languages, or just needed to do it differently and by God I'd see the light!

I would suggest that instead you accept that not everyone is like you. Everyone's creative process is different. A REPL has never fit into mine.

I'm not going to tell you you're doing things wrong or you need to see the light. Only that maybe you're missing out on a pretty powerful feature that's really worth checking out.

I've been writing software for 20 years.

You think I haven't experimented with REPLs from time to time? :)

The rest of the world is behind Java in some developments like container-style isolation of different applications in the same runtime environment. However people still mock Java in things the community is behind. Wait till the cool kids discover conatiner managed transactions. Then it will THE GREATEST THING EVAH !!

.Net has done such a thing with Application Domains since its very early days on Windows. Recently they've decided it's not worth the trouble to move over to .Net Core.

https://docs.microsoft.com/en-us/dotnet/framework/app-domain...

The original Java REPL was called Eclipse

Nitpick, but God, I hate this hero image. It's "fantasy UI" is so lazily done it hurts the eyes. It's just the same block copy-pasted around and resized multiple times. Did whoever made this picture think nobody would notice?

(Yes, I hate half-assed design.)

Also they use contrast ratio of 3.0 for main text (gray font on white background). WCAG minimum is 4.5 and recommended is 7.0.

But triangle buttons! Unlabeled ones, at that. The guy in the picture is thinking, "I wonder what this one does..."

Okay, this is completely tangential to the article, but I see this footer on the website:

"We are using cookies to improve your experience of our site. By clicking ‘Agree’ or ignoring the banner, you are assenting to our use of cookies."

I don't really care, but is this strictly speaking legal? "If you don't read this, you agree to it"? If I read it, am I "ignoring the banner"? Usually if you don't agree, they are supposed to not store cookies and ask every time, which is something I'm actually OK with.

Boring.

I'll tell you a little secret, Java is the number one programming language in the world just because it is used by millions of programmers for Android apps and a few enslaved programmers in corporate gulags. Once Kotlin takes the Android world by storm Java will sit next to Cobol in the history books of technology.

At one point Scala was going to take over the world. It was hot favorite of many fastest growing companies. Then the companies grew and moved to Java with or without much fuss.

Your secret does seem like secret to lot of people. In my knowledge Java is big because lots and lots of companies use Java stack for boring enterprise applications. And in those places people could care less about cool stuff and work on things that pays.

Cobol is still used in very critical software at big Banks. Java along with it quite respectful place. Whereas Kotlin is a little bit of lot of things. Runs of JS/JVM/Native but none of them a unique strength for Kotlin. So it will be very difficult to compete with languages which committed to single platform and have serious business use cases.

One of Kotlin's design goals was 100% compatibility with java.

Whenever I work on a java-codebase and see a class that could be expressed much simpler in Kotlin I press "Cmd+Option+Shift+K".

Intellij IDEA automatically converts this file to Kotlin. The codebase continues to work without issues and I can proceed extending this part in Kotlin.

You hugely underestimate how much of large corporations work in java. Android, compared to the enterprise software, is peanuts.

Our enterprise used a lot of Oracle (e.g. Java) products but never committed to actual Java development. As of late they have been heavily divesting themselves of Oracle as rapidly as possible.

> Java is the number one programming language in the world just because it is used by millions of programmers for Android apps and a few enslaved programmers in corporate gulags

This is an incorrect and terribly biased opinion. I have been working primarily in Java for over five years and neither of those applies to me. Java has been a core language in ML and NLP for at least a decade.

In what language and runtime will Kotlin run on?

Kotlin is a language that runs on JVM6.

That's true, but don't forget Kotlin also compiles to plain JavaScript, and a native compiler is in the works too.

Yea, but the benefits of any jvm language fall of a cliff without the jvm.

Without the libraries, performance or profiling tools that Java has, so it remains to be seen how much uptake it will have.

Kotlin is 100% java-compatible, you can mix source-files side-by-side in one project. You can easily call kotlin from java and java from kotlin.

That means you have all the libraries, performance and profiling tools that java has.

Not when targeting "plain JavaScript, and a native compiler is in the works too".

Please read the OP before commenting.

Agreed, sorry.

Well, without the libraries and profiling tools anyway ;-)

Nowadays this means nothing because everything compiles to plain JavaScript.

Will Kotlin on Android run on a JVM or ART? Or do I have a fundamental misunderstanding of things?

On Android it runs on ART.

But Android tooling is heavy dependent on Java and Google even had to drop their Jack/Jill compiler replacement, because they weren't able to make it work properly with all the tooling that targets the JVM.

So they pivoted to translating JVM bytecodes into ART ones (originally Dalvik ones, DEX) again.

However even with the way Google has handled the Java story, the whole Android eco-system is heavyly dependent on it.

They also pivoted the Brillo project with the promise of a set of C++ userspace frameworks, into Android Things using Java instead, including the ability to write device drivers in Java.

Hence why thinking that Kotlin can manage without Java and its eco-system is kind of strange, even on Android.

EDIT: Of course it runs on Dalvik as well when targeting pre-Lolipop devices.

Thanks! I don't do native development on Android <gasp!> so I only follow the comings and goings superficially.

Yes. You can mix Kotlin and Java in the same-project. Kotlin can call all Java-code and Java can call all Kotlin-code.

Reply on news.ycombinator.com