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

141–150 of 161 posts

Re: JDK 9 release schedule

#141

Post by hiram112 »

grogenaut wrote: post #127
smoyer wrote: post #100

Earlier quoted context omitted.

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…

Lombok is a bad idea, IMO.

Getters and Setters are verbose, but usually model classes are contained in a single class anyway, and can be generated automatically with any IDE. I can glance at a typical bean and ignore the code bloat without any problem.

The real issue is that Lombok generated classes don't play well with the dozens of libraries that expect Java bean style methods for auto marshaling and serialization: json generators, commons bean utils, binding libs, etc.

The savings aren't worth the trouble.

Re: JDK 9 release schedule

#142

Post by potatosareok »

hiram112 wrote: post #141
grogenaut wrote: post #127

Earlier quoted context omitted.

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…

Lombok is a bad idea, IMO. Getters and Setters are verbose, but usually model classes are contained in a single class anyway, and can be generated automatically with any IDE. I can glance at a typical bean and ignore the code bloat without any problem. The real issue is that Lombok generated classes don't play well with the dozens of libraries that expect Java bean style methods for auto marshaling and serialization:…

What problems do you have? Lombok does bytecode generation, I've never had a problem using it with things such as Jackson. How would an external library even know when the bytecode looks the same? I'm entirely aware I might be missing something obvious, this is a genuine question.

You can argue against Lombok for other reasons but was wondering about this specific one.

Re: JDK 9 release schedule

#143

Post by ivanche »

ksec wrote: post #138

Does anyone know if Truffle and Graal will ship with JDK 9 ?

While I can't say with 100% confidence, I listened Graal presentation at Voxxed Days Belgrade one month ago and the presenter (IIRC, Martin Tonchev) said it won't be ready for JDK9 and that they aim at JDK10.

Re: JDK 9 release schedule

#144

Post by imtringued »

jwn wrote: post #4
merb wrote: post #2

well not too bad if they could deliver the jdk 10 (valhalla) a faster. jdk 9 is less important than jdk 10.

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?

Value types combined with generic specialisation results in less memory usage, higher data locality, less gc pressure. Basically a big increase in performance on top of the already very good JIT.

Re: JDK 9 release schedule

#145

Post by wtetzner »

lacampbell wrote: post #112
clusmore wrote: post #99

Earlier quoted context omitted.

I agree that setter properties are often a code smell, but getter properties are nice for calculated fields. As a very simple example, consider the following (C#): class Circle { public Circle(int radius) { Radius = radius; } public int Radius { get; } public int Diameter => Radius * 2; }

Diameter is a nice example of a getter property. However you could change radius to simply public int Radius;

I think you mean

    public final int radius;

Re: JDK 9 release schedule

#146

Post by parasubvert »

haalcion3 wrote: post #121
gshx wrote: post #118

Earlier quoted context omitted.

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,…

I work for Pivotal so I'm biased. But I'd take a long look at Sprint Boot in terms of "fun , productive , practical" Java: https://projects.spring.io/spring-boot/

In particular: - curated and tested open source library dependencies to the point that you can generate a single JAR for anything you might want to build on the server: http://start.spring.io/

- Annotations and APIs to make REST service development a breeze

- native support to build apps that use SQL, NoSQL and other Data systems without plumbing: http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/refe...

- SSH shell/CLI into your JVM to manage your JVM

- Actuator to provide production metrics for your system

- declarative security that allows you to build Oauth2 enabled apps in maybe 20 lines of code/annotations

- great symbiosis with modern JavaScript for responsive sites, eg https://spring.io/blog/2015/01/12/spring-and-angular-js-a-se...

- Cloud connectors to make it easy to run your app on Heroku, Kubernetes, Mesos or Cloud Foundry, or to leverage NetflixOSS components, or to build stream processing applications (Spring cloud stream / data flow)

It is being downloaded and used at a very high rate (a couple million a month).

Re: JDK 9 release schedule

#147

Post by samch »

theandrewbailey wrote: post #126
samch wrote: post #122

Earlier quoted context omitted.

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.

I think I see where you're coming on that. For most of my applications, I terminate TLS connections with nginx. I do use ChaCha for high-speed encryption in other areas, though. The BC libraries have always worked great for me.

Re: JDK 9 release schedule

#148

Post by snuxoll »

pgwhalen wrote: post #131
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…

>Make it compile low-level vs. byte code so it's fast as shit. AOT compilation is not automatically faster than JIT compilation. Java already is fast as shit. If you're worried about that first 100 milliseconds, works is being done on AOT compilation.

AOT isn't for the first 100ms, it's to avoid the 10K invocations required on a method for HotSpot to determine a hot code path and optimize the method - that can take a lot longer than 100ms and why when you see the JVM used in the financial sector, for example, they go through a lot of effort to "warm" the JVM.

Of course without runtime profiling the AOT built code may not be optimized for the hot path correctly, HotSpot will still deoptimize in this case and begin profiling again - so it's not going to be suitable for everything until they allow you to capture profiling details and feed it into the AOT compiler.

Re: JDK 9 release schedule

#149

Post by snuxoll »

parasubvert wrote: post #146
haalcion3 wrote: post #121

Earlier quoted context omitted.

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,…

I work for Pivotal so I'm biased. But I'd take a long look at Sprint Boot in terms of "fun , productive , practical" Java: https://projects.spring.io/spring-boot/ In particular: - curated and tested open source library dependencies to the point that you can generate a single JAR for anything you might want to build on the server: http://start.spring.io/ - Annotations and APIs to make REST service development a breeze…

Spring Boot is awesome, thank you guys for your massive contribution. All of my co-workers are .Net guys and keep trying to say that Java is dead now that .Net Core is out, but I still haven't found a server-side solution better than Spring yet :)

Re: JDK 9 release schedule

#150

Post by int_19h »

jsmith0295 wrote: post #101
int_19h wrote: post #57

Earlier quoted context omitted.

Aside from backwards compatibility, what's good about type erasure for generics?

Doing it a better way is hard

Is it, though? The most basic implementation, where things are still erased at runtime by the JIT, should be fairly simple, although it will not give the expected perf gains, of course.

Either way, CLR and C# did it a long time ago, and in the same time period when Java acquired its type-erased generics.

Post reply on HN