Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JDK 9 release schedule

mail.openjdk.java.net

Post reply on HN
Print view View original

121–130 of 161 posts

Re: JDK 9 release schedule

#121

Post by haalcion3 »

gshx wrote: post #118
haalcion3 wrote: post #116

Been coding Java for close to 20 years. Can anyone show me what's being done in the language to bring on newcomers, or did that ship sail 10-15 years ago? Some ideas that would bring people back: * Wildly new, terse, and clear syntax and a great library of built-in tools that are briefly and intuitively named. * Easily write and design interfaces that generate both/either back-end or matching integrated front-end cod…

Thanks for the bullets. This is a good list but some of the points like "Easily scalable" and "DB support" are not cheaply available in any runtime and require careful attention to detail as well as domain-specific thinking. IMHO, the JVM already does a lot of heavy-lifting in this regard.

It comes down to this: are those developing the language thinking about how to add features just to try to hone and hold on to the enterprise developers that still use it, or are they thinking about what would make it more fun, productive, and practical?

Java's going to be around a long time. Those that stick with it will be fine. COBOL programmers made a lot of money in 1999, and some people still use Fortran.

But, Java's original big mantra was "write once, run anywhere." Such idealism then. Cool things have been done in the past few years, but can't we do more?

Re: JDK 9 release schedule

#122

Post by samch »

theandrewbailey wrote: post #61
jwn wrote: post #4

Earlier quoted context omitted.

Looking at http://openjdk.java.net/projects/valhalla/ , I don't see a whole lot of value compared to JDK9. What's your basis for wanting 10 so badly?

JDK 10 will have TLS Fallback SCSV and native ChaCha20 support, though I wish they were in JDK 9.

Not sure why you have to wait. I use ChaCha in production in JDK 8: https://github.com/bcgit/bc-java/blob/master/core/src/main/j...

Why would native be any better? I would think that as long as the implementation matches the reference it wouldn't matter.

Re: JDK 9 release schedule

#123

Post by bitmapbrother »

pjmlp wrote: post #41
bitmapbrother wrote: post #36

Earlier quoted context omitted.

Hopefully they'll ditch Java and go with a superior language.

I don't believe, given what they repeat at every Google IO when people ask about it. Also I don't have any issue with Java as I do like the language and use it since JDK 1.0.1. My issue is with Android Java, a forked version of Java with cherry picked features of Java 6, 7 and now 8, just because Google didn't want to pay Sun. A version that will be even harder to write portable code when Java 9 and 10 come out.

Or perhaps they know better than to release confidential information about their roadmap?

I believe Google is running out of solutions to further optimize Android because they keep running into self inflicted Java roadblocks. If Fuchsia is any indication of their future efforts their next major overhaul will support multiple first class languages.

Re: JDK 9 release schedule

#124

Post by markelliot »

smoyer wrote: post #111
ap22213 wrote: post #105

Earlier quoted context omitted.

I'm embarrassed to say that I've never understood the use case for Lombok. So, I write my code in Java with Lombok extensions. Then, another Java programmer goes to maintain it... and they have to learn Lombok?

That was my reaction the first time I was introduced to it. I looked at it again two years later and it just clicked. What's really cool is that the developer who has to go maintain it has 20% as much code to maintain. Say you want a POJO with accessors, mutators along with equals and hashcode. Let it generate the methods by defining a class like: @Data public class something { String name; int age; } Lombok generate…

It might be worth a look at Immutables (http://immutables.github.io/) or FreeBuilder (https://github.com/google/FreeBuilder), both of which also use Java's built-in annotation processors to do code generation, but involve slightly less magic and produce generated classes which are not overwriting the original class.

Re: JDK 9 release schedule

#125

Post by lacampbell »

carterehsmith wrote: post #120
lacampbell wrote: post #117

Earlier quoted context omitted.

I guess not. Sometimes the cleanest thing to do is to just mutate a field - particularly for GUI objects. I don't know if it's worth the overhead of having unthinking developers writing { get; set } for every field in every class because it makes things "easier".

> I guess not. Sometimes the cleanest thing to do is to just mutate a field - particularly for GUI objects. I don't know if it's worth the overhead of having unthinking developers writing { get; set } for every field in every class because it makes things "easier". I do not understand your point. First you claim that we should not mutate the field, then you claim that we should mutate the field. Which one is it? Muta…

Generally not mutate. And if we must mutate, mutate in a batch with a single method with a descriptive name.

We should generally not use goto or local variables either. Avoid reaching for these constructs first. But if it's by far the cleanest, and simplest way of solving the problem - which it usually isn't - go ahead and do it.

Re: JDK 9 release schedule

#126

Post by theandrewbailey »

samch wrote: post #122
theandrewbailey wrote: post #61

Earlier quoted context omitted.

JDK 10 will have TLS Fallback SCSV and native ChaCha20 support, though I wish they were in JDK 9.

Not sure why you have to wait. I use ChaCha in production in JDK 8: https://github.com/bcgit/bc-java/blob/master/core/src/main/j... Why would native be any better? I would think that as long as the implementation matches the reference it wouldn't matter.

Last weekend, I added Bouncy Castle as the security provider in my dev environment, but my server did not show ChaCha20 in the list of available TLS ciphers. I was not convinced that my server was even using BC. Knowing that if you don't know what you're doing and mess around with crypto too much that you can get burned, I gave up. ECDHE RSA AES GCM for now.

Re: JDK 9 release schedule

#127

Post by grogenaut »

smoyer wrote: post #100
merb wrote: post #8

Earlier quoted context omitted.

well as others already pointed out, value types. this changes the way how the JVM uses Memory in certain ways and might be a huge improvement for a lot of stuff. specialized generics. this is a huge one, too, less boxing is always a win. JEP-286 less typing. Maybe Project Panama and maybe a even better AOT. Compared to what JDK 9 brings, this is huge. JDK 9 brings a Module system which was already possible (and a lot…

If you want less typing, then you definitely want Lombok ( https://projectlombok.org/ ). At JavaOne this year, they also showed a proposed shortcut for data object (@Data in Lombok). public class something(String name, int age) { ... }

if you want somthing that will send people over the edge and let you cackle with glee...

https://projectlombok.org/features/val.html

I've been doing C# for while... soo nice to have this. Coming back to java was like "why am I repeating myself". They already did the diamond operator on the right hand side, this makes the left just as nice.

now let the flames begin!!!

Oh also found a use for SneakyThrows today... I'm bootstrapping a test server in my unit test, where all of the code and interfaces are designed for safety and no-crash... and this lets me short circuit right out of it when something bad happens, which in a test setup is what I want.

Re: JDK 9 release schedule

#128

Post by snuxoll »

haalcion3 wrote: post #116

Been coding Java for close to 20 years. Can anyone show me what's being done in the language to bring on newcomers, or did that ship sail 10-15 years ago? Some ideas that would bring people back: * Wildly new, terse, and clear syntax and a great library of built-in tools that are briefly and intuitively named. * Easily write and design interfaces that generate both/either back-end or matching integrated front-end cod…

> Wildly new, terse, and clear syntax

Kotlin

> great library of built-in tools that are briefly and intuitively named.

I dunno, guess this depends on what you need. The Java class library has so much in it, but I guess it's not overly intuitive due to the age of a lot of the packages. Personally, I don't think I'd have a hard time getting my .Net-loving colleagues accustomed to everything as is.

Java EE is another matter entirely, I gave up on it after the Java EE 8 clusterfuck that's going on and have just decided to use Spring for everything.

> Easily write and design interfaces that generate both/either back-end or matching integrated front-end code which is off in its own directory and can easily be used by existing JavaScript and HTML.

What are you looking for here? Automagic API's? spring-data-rest says hello. I still find it's better to write my own, but if you need something for a quick prototype there you go.

> Easily scalable.

How are you wanting to scale? Where is your bottleneck? This isn't on the language to solve, it's how you design your application. I can throw up 2,000 instances of an application, but whether the database behind it can handle 100K/tx/sec is another story entirely.

> Relational, noSQL, versioning DB (noms) support.

We've had JDBC, JPA, jOOQ, QueryDSL, etc, forever for the relational story. There's plenty of support out there for various NoSQL databases (Spring even has spring-data-cassandra which I am looking at using right now for an ES/CQRS design).

> Make it integrate with every browser, even some older versions, operating systems.

Why? Java in the browser is dead. If you want to write client-side stuff just use JavaFX and package using WebStart or an installer that bundles your JRE and dependencies.

> Make it compile low-level vs. byte code so it's fast as shit.

Java is already "fast as shit". The warmup time for HotSpot and initializing the JVM is probably the big complaint everyone has, but unless you are writing small command line tools it is a complete non-issue.

With that said, Java 9 will support limited AOT compilation of modules to reduce the time to get basic compiled versions of your classes - HotSpot will still profile the compiled modules, and if finds it is required it will deoptimize, re-profile through bytecode interpretation and reoptimize - just like it does with normal .class files (which are still required to run).

Re: JDK 9 release schedule

#129

Post by snuxoll »

papercrane wrote: post #35
pjmlp wrote: post #34

Earlier quoted context omitted.

This will happen: http://www.oracle.com/technetwork/java/javase/community/jlss...

Probably not at the language level. If you watch the Goetz talk you linked to he answers this at 50m36s. The bytecode and JVM will be able to represent riefied generics, but at the Java language level they'll still likely maintain erasure for Object types. https://www.youtube.com/watch?v=Tc9vs_HFHVo&list=PLX8CzqL3Ar...

Good thing Kotlin already supports reified generics (with the current caveat that they must be used in inline functions), Java the language is less important these days than the JVM having support for the feature.

Re: JDK 9 release schedule

#130

Post by pron »

pjmlp wrote: post #40
papercrane wrote: post #35

Earlier quoted context omitted.

Probably not at the language level. If you watch the Goetz talk you linked to he answers this at 50m36s. The bytecode and JVM will be able to represent riefied generics, but at the Java language level they'll still likely maintain erasure for Object types. https://www.youtube.com/watch?v=Tc9vs_HFHVo&list=PLX8CzqL3Ar...

I know, but with the JVM having full support, that might eventually change in Java 11 lets say, after the experience how everything went. Brian did not state they will never do it. Also the other languages could take advantage of it anyway, even a reiffied version of Java for example.

Reified generics for reference types is a really, really bad idea. It solves a minor, itsy-bitsy-tiny problem, but pretty much ruins sharing of data structure among languages, because it bakes a specific variance model into the classes. For value types that's not a problem because they don't support subclassing anyway.
Post reply on HN