More Java 9 Features Announced

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.

Will value types be part of Java 9?

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

FWIW, Stephen Colbourne disagrees with Oracle's decision to leave out properties:

blog.joda.org/2014/11/no-properties-in-java-lan...