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

131–140 of 161 posts

Re: JDK 9 release schedule

#131

Post by pgwhalen »

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.

Re: JDK 9 release schedule

#132

Post by hota_mazi »

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…

> Can anyone show me what's being done in the language to bring on newcomers

I don't think Java needs any help in that department given how crazy popular it is.

And Android has made it even more popular than it ever was these past eight years.

Java has a few issues but the learning curve is not one of them.

Re: JDK 9 release schedule

#133

Post by pjmlp »

usrusr wrote: post #95
jjoonathan wrote: post #43

Earlier quoted context omitted.

> isn't much shorter than how it is done in java The savings in screen space and visual cortex neurons doesn't come from the one or two properties that need logic, it comes from the dozen avoided /** * Gets the foo * @return the foo */ public Foo getFoo() { return foo; } /** * Sets the foo * @param foo */ public void setFoo(final Foo foo) { this.foo = foo; }

A compiler switch that makes trivial comments on accessor methods a compile error, now that would be something I could support!

Javadoc plugin?

Re: JDK 9 release schedule

#134

Post by cs02rm0 »

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…

One of the nice aspects of it is that if you have, say, a setter method which does something slightly unusual (e.g. setLastName does a call to setName(getFirstName() + " " +lastName) - unlikely example perhaps) then it stands out from the crowd of otherwise straightforward getters and setters.

Re: JDK 9 release schedule

#135

Post by pjmlp »

snuxoll wrote: post #129
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...

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.

Java the language is still very important, it is the systems programming language of the JVM.

On my .NET projects we get a full installation from Visual Studio on the development machines. Which means C#, F#, C++ and VB.NET available.

On my Java projects those machines have usually Eclipse + JDK. JARs are either vendored or make use of an internal Maven server.

I am yet to be allowed to use anything other than Java (the language) on those kind of projects.

Most customers want replaceable consultants so they don't allow us to go outside of their standard stack.

Re: JDK 9 release schedule

#136

Post by pjmlp »

bitmapbrother wrote: post #123
pjmlp wrote: post #41

Earlier quoted context omitted.

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.

Check the bios of many of the major Android team leads, some of them were former Java developers at Sun, which I think has a big weight on Java's role on Android.

As for Fuchsia and Brillo, it remains to be seen if they will ever be productified.

Also I don't believe that Dart is a better option than Java in regards to performance.

Re: JDK 9 release schedule

#137

Post by nradov »

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…

Most of that seems overly specific and wouldn't be appropriate for the core of a general purpose language. There's a whole world of software outside of web applications. Leave that stuff to separate libraries and frameworks.

Re: JDK 9 release schedule

#139

Post by Tharkun »

ape4 wrote: post #86

If you are doing dates the nice way as yyyy/mm/dd you should use dashes - ie yyyy-mm-dd. Let the slashes mean other styles.

Or you could not make assumptions like this. There are more ways to represent dates than there are bones in my body. What seems like a silly way to you might be the preferred way for someone else, for a variety of reasons.

Re: JDK 9 release schedule

#140

Post by skoczymroczny »

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…

But then you switch to JavaFX and you realize Lombok won't help you with JavaFX properties generation :(
Post reply on HN