Oracle have announced more features to be delivered as part of JDK 9. The headline features is modularity, as we reported on Monday. However, a large number of other features have also been announced. The new features include:
- Unified JVM Logging - a complete overhaul of how the JVM reports events in its subsystems, replacing the ad-hoc and separate logs that Hotspot current generates.
- Remove GC Combinations Deprecated in JDK 8 - this is the removal of 3 outdated garbage collection combinations: DefNew + CMS, ParNew + SerialOld and Incremental CMS. These combinations were already deprecated in Java 8.
- Compiler Control - fine grained control of the Hotspot JIT compiler down to the level of being able to switch a specific optimization on or off at a per-method level.
- Milling Project Coin - tidying up a few leftover edge cases from Java 7's Project Coin (which delivered some small language changes).
The feature list also includes the completion of the warnings cleanup project that has been running for several years, as well as a cleanup of import handling. Importing deprecated classes will now no longer trigger warnings and some long-standing type resolution problems in javac will also be fixed.
Support for a couple of modern technologies was also announced - Datagram Transport Layer Security (DTLS) and an upgrade to the javadoc tool to output HTML5.
The current status of the in-flight JEPs also shows that primitive specialization of generics (to allow types such as List<int> without boxing of the primitive type) is not on the road map for JDK 9, and instead would target JDK 10.
A roadmap, milestones and expected release date for Java 9 have not been announced, but expectations are that it will be Autumn 2016. Oracle are trying to keep roughly a 2-year cadence between Java releases and the timeline for Java 8 shows that the GA release of Java 8 was almost exactly 2 years after the M1 build was released.
Community comments
Value Types
by Luke deGruchy,
Re: Value Types
by Ben Evans,
Value Types
by Luke deGruchy,
Mediocre Target and Innovation
by Suminda Dharmasena,
Re: Mediocre Target and Innovation
by Luke deGruchy,
Re: Mediocre Target and Innovation
by Suminda Dharmasena,
Re: Mediocre Target and Innovation
by Luke deGruchy,
Re: Mediocre Target and Innovation
by Suminda Dharmasena,
Re: Mediocre Target and Innovation
by Ben Evans,
Re: Mediocre Target and Innovation
by Suminda Dharmasena,
Re: Mediocre Target and Innovation
by Ben Evans,
Re: Mediocre Target and Innovation
by Suminda Dharmasena,
Re: Mediocre Target and Innovation
by Suminda Dharmasena,
Re: Mediocre Target and Innovation
by Ben Evans,
Suggestion Java 9....Make annations @Getter @Setter from project Lombuk standard
by Colbert Philippe,
Re: Suggestion Java 9....Make annations @Getter @Setter from project Lombuk
by Ben Evans,
Re: Suggestion Java 9....Make annations @Getter @Setter from project Lombuk
by Luke deGruchy,
Value Types
by Luke deGruchy,
Your message is awaiting moderation. Thank you for participating in the discussion.
What about value types? Will they also be left out of Java 9? If so, it'll be a shame since other JVM languages would have benefited.
Value Types
by Luke deGruchy,
Your message is awaiting moderation. Thank you for participating in the discussion.
Will value types be part of Java 9?
Re: Value Types
by Ben Evans,
Your message is awaiting moderation. Thank you for participating in the discussion.
I don't know that they have been committed to for 9 & my personal take is that it's unlikely, as the specialization mechanism will presumably be needed if value types do not inherit from Object (which is my understanding of the current situation & plan).
Mediocre Target and Innovation
by Suminda Dharmasena,
Your message is awaiting moderation. Thank you for participating in the discussion.
I seriously think that Oracle should think about changing the Java Executives / Management. Any other company with such a poor resent track record of innovation you will be let go of. I am surprised how they manage to get away with this. Many of the features targeted at Java 9 and 10 should have come long before.
Re: Mediocre Target and Innovation
by Luke deGruchy,
Your message is awaiting moderation. Thank you for participating in the discussion.
Huh? The way I see it Java development was stagnating under Sun during its dying days and Oracle turned things around dramatically after taking over. Remember that Oracle didn't finalize the takeover of Sun until 2010:
en.wikipedia.org/wiki/Sun_acquisition_by_Oracle
Since then Oracle has introduced Method Handles, invokedynamic, the G1 garbage collector, improved exception handling (multi-catch, etc), Lambdas, the Collections Stream API, the new Date/Time API, improvements in concurrency libraries, getting rid of permgen, etc.
Re: Mediocre Target and Innovation
by Suminda Dharmasena,
Your message is awaiting moderation. Thank you for participating in the discussion.
Compare this to the competition. How much they are doing.
Also looking at what they have done "Method Handles, invokedynamic, the G1 garbage collector, improved exception handling (multi-catch, etc), Lambdas, the Collections Stream API, the new Date/Time API, improvements in concurrency libraries, getting rid of permgen, etc." how significant is this any way? Also look at what has not been done: openjdk.java.net/jeps/0 or unduly delayed. Anything ground breaking is delayed until 10 and also many missing things which don't appear in the list like Continuations and Fibers, Unsafe / Internal replacement, etc.
Re: Mediocre Target and Innovation
by Luke deGruchy,
Your message is awaiting moderation. Thank you for participating in the discussion.
First of all, which "competition" are you referring to?
Remember that Java is an almost 20 year old language and runtime that Oracle is tasked with maintaining and for which it has made certain guarantees about backward compatibility. Ensuring 20 year backward compatibility, especially binary compatibility, is a challenge the maintainers of newer JVM languages don't have to worry about.
For instance, Scala still breaks binary compatibility with each new release. If Oracle tried to do that with Java there would be hell to pay.
So the maintainers of Scala, Ceylon, Kotlin, Groovy, Closure, and, to a lesser extent, .NET, really don't have this onerous burden to worry about. For instance, Microsoft has been able to implement so many more modern technologies in .NET simply because they didn't have 10 years of legacy to support by the time the platform started really taking off (ex Delegates).
Why do think Oracle left out function types in Lambdas? I'm sure they really wanted to, but realized the risks were too great with Java's type system having the legacy behaviour that it does. For similar reasons, offering reified generics or value types will be a challenge, given how the JVM is currently structured.
Another roadblock to change is the lack of modularity. Once the JVM is modularized Oracle will be able to (at least in theory) make changes to the Java language and class libraries separately, and shove a lot of legacy cruft (ex CORBA) out of the main class libraries.
So before playing armchair quarterback and convincing yourself that Oracle has simply chosen not to get blood out of a stone (as opposed to being unable to), I suggest your put yourself in the shoes of people like Brian Goetz and understand the challenges he and other Java maintainers face every day to keep their customers running mission critical apps while moving the platform forward.
One thing I will say is that Oracle should continue to give the developers of alternative JVM languages good JVM features to be able to move those languages forward so that those languages can evolve as quickly as possible. Java modularity is one such tool that will make things easier for the whole JVM ecosystem.
Re: Mediocre Target and Innovation
by Suminda Dharmasena,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think breaking compatibility of very old versions are fine as long as there is a migration tool which converts old format to new. What I feel this risk has been taken out of proportion and always siding towards in action than doing something.
Functional types without would have been a good addition. Maybe this should be re evaluated in the future.
As of lately Brian Goetz seams to be the one of the few who is doing something. There maybe quite a few who might have not show much initiative.
Having said this success is more often management support and culture. I guess this department needs working on.
Also leave a local saying "one who washers plates only breaks plates". If you do something only things break and this might be inevitable. Even compatibility. Compatibility should be approached differently than that is currently done. You should have a migration utility which can convert old format to new. In case an old Jar is used with different class format the JVM should bee able to load an instrumentation / agent which does the conversion. This may be show if they are not been already migrated. But this is better than holding things back.
Re: Mediocre Target and Innovation
by Ben Evans,
Your message is awaiting moderation. Thank you for participating in the discussion.
OK, so you, and a certain subset of the Java community think that breaking compatability and moving faster would be a good thing. However, the platform guardians (currently Oracle) have to think about the community as a whole. Java has upwards of 10 million developers and is one of the most important software ecosystems on the planet (only HTML / JS comes close to Java in terms of importance). Java is an extremely broad church, and we have to consider a diverse set of requirements and viewpoints.
Two of the most important quotes about Java and its design philosophy come from James Gosling himself:
"Java is a blue collar language"
"If I did not know the right way to do something in the language design, I would rather do nothing than do the wrong thing"
Conservative, practical and cautious are the principles that underlie what Java is. If, as a programmer, you are at a stage in your intellectual development where you value rich abstractions and concepts that Java currently lacks, then by all means look at other languages (many of them even run on the JVM).
However, please recognize that Java has to serve a wide audience, including many junior programmers. It isn't the place for experimentation in language design or changes made without a lot of planning and introspecting about the consequences.
"Move Fast & Break Things" is fine, when you're basically a monopoly and your customers have no choice but to accept what you force on them, but as a principle it can be restated as: "Don't Care About The Harm You Inflict On Your Customers Or The Externalities", and that is not, has not, and never will be the Java philosophy.
Re: Mediocre Target and Innovation
by Suminda Dharmasena,
Your message is awaiting moderation. Thank you for participating in the discussion.
If compatibility is used as a precursor for doing nothing this does not work for me. I am not saying ignore compatibility. But this can be achieved any many ways. This should not be used to justify being mediocre.
You can change the underlying JVM but still use a compatibility agent / instrumentation to have compatibility. This way you don't have to break anything but can decouple the underlying JVM implementation with long term compatibility goals. The agent can be loaded without the user even knowing. Also you can have a migration manager to do AOT migration of old format bytecode.
Re: Mediocre Target and Innovation
by Ben Evans,
Your message is awaiting moderation. Thank you for participating in the discussion.
Migration utilities are simply impractical for a large class of Java end users. That idea has been extensively discussed and pretty comprehensively rejected.
In the immortal words of Spock - "The needs of the many outweigh the needs of the few". If you are one of the few, you are free to choose a different path, but the platform is not about to potentially harm large classes of users just because some more cutting-edge users think that the platform is not evolving fast enough.
Unfortunately, the design goals of the platform differ from your desirables.
Oh, by the way, mitigating / removing access to Unsafe is very much on the roadmap for Java 9 - it comes as part of modularity.
Re: Mediocre Target and Innovation
by Suminda Dharmasena,
Your message is awaiting moderation. Thank you for participating in the discussion.
I am saying to provide 2 solutions:
1) Migration manager
2) Instrumentation agent based solution - any old byte code will be converted to the new format in the fly. With so much open source code written in Java this can extensive tested for regressions.
Re: Mediocre Target and Innovation
by Suminda Dharmasena,
Your message is awaiting moderation. Thank you for participating in the discussion.
Just not Unsafe I feel much of the other private classes also should be migrated to public API. Over the years many would be relying on these functionality and also other projects which do not directly use them would be indirectly dependent on them.
Re: Mediocre Target and Innovation
by Ben Evans,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Sumida,
If you read the archives of the OpenJDK mailing lists, you can find out more about exactly what's being worked on for JDK 9, and why the approach that's been chosen is the way it is.
Instrumentation & agent-based solutions are incredibly complex to implement even for relatively simple cases, and one of the complexity you propose is just not feasible - production customers would never be able to have the required confidence in it.
Suggestion Java 9....Make annations @Getter @Setter from project Lombuk standard
by Colbert Philippe,
Your message is awaiting moderation. Thank you for participating in the discussion.
I want java to have annotations for generating getters and setters (like on Project Lombuk projectlombok.org/ ) to become standard in Java. It's always optional if one needs more elaborate getters and setters. I use it and it makes source code far shorter!!! The space savings alone is worth making it standard.
Re: Suggestion Java 9....Make annations @Getter @Setter from project Lombuk
by Ben Evans,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Colbert,
Once again - I'd advise you to read the archives of the relevant mailing lists. This idea has been extensively discussed - it's not like the development of the core JDK happens in isolation from the community. There are practical considerations which mean that this type of approach is more complicated than it first appears. As with everything in the Java platform, when it comes to making changes the Devil is in the detail.
Re: Suggestion Java 9....Make annations @Getter @Setter from project Lombuk
by Luke deGruchy,
Your message is awaiting moderation. Thank you for participating in the discussion.
FWIW, Stephen Colbourne disagrees with Oracle's decision to leave out properties:
blog.joda.org/2014/11/no-properties-in-java-lan...