BT

Your opinion matters! Please fill in the InfoQ Survey!

Java 10 - The Story So Far

| by Ben Evans Follow 13 Followers on Nov 21, 2017. Estimated reading time: 4 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

It has been exactly two months since the release of Java 9, so as per the new schedule, the next release of Java is now only four months away. The complete scope for Java 10 is still being confirmed and locked down. This means that there is still the possibility of significant changes to the scope and content of the release between now and the GA data. However, it is possible to get some idea of what features developers can reasonably expect to arrive with Java 10, in around four months time.

New features and enhancements are tracked through either the Java Enhancement Process as JEPs, or through the Java Community Process for standardization requests (JSRs). With the short timescale and accordingly small scope, Java 10's changes will be arriving as JEPs and can be tracked via their JEP number.

The features that Java 10 seems most likely to contain are those with JEPs currently in Targeted or Proposed to Target state. Currently, this consists of the following features:

  • 286: Local-Variable Type Inference
  • 296: Consolidate the JDK Forest into a Single Repository
  • 304: Garbage-Collector Interface
  • 307: Parallel Full GC for G1
  • 310: Application Class-Data Sharing
  • 312: Thread-Local Handshakes

Of these, JEP 296 is purely housekeeping and JEP 304 increases code isolation of different garbage collectors and introduces a clean interface for garbage collectors.

The latter means that it will be easier for vendors to produce JDK builds that contain, or exclude a specific GC algorithm. With new GC approaches such as Shenandoah, ZGC and Epsilon in development, then this makes sense. There are even efforts within the community to deprecate and even remove the Concurrent-Mark-Sweep collector (CMS) although at present there is no production-quality feasible replacement for it.

The change that is likely to provoke the most interest is JEP 286, which will allow the developer to reduce boilerplate in local variable declarations by enhancing type inference. This means that the following becomes legal Java as of the next release:

var list = new ArrayList<String>();  // infers ArrayList<String>
var stream = list.stream();          // infers Stream<String>

This syntax will be restricted to local variables with initializers and local variables in for loops.

It is purely syntactic sugar implemented in the source code compiler and has no semantic significance. Nevertheless, experience shows that this feature is likely to provoke lively debate among Java developers.

The remaining three changes all have some impact, albeit potentially small, on performance.

JEP 307 solves a problem with the G1 garbage collector - as of Java 9 the current implementation of the full GC for G1 uses a single threaded (serial) algorithm.
This means that if G1 ever has to fall back to a full GC then a nasty performance shock awaits. The aim of JEP 307 is to parallelize the full GC algorithm so that in the unlikely event of a G1 Full GC then the same number of threads can be used as in the concurrent collections.

JEP 310 extends a feature called Class-Data Sharing (CDS), which allows a JVM to record a set of classes and process them into a shared archive file. This archive can then be memory-mapped into the JVM process on the next run to reduce startup time. The file can also be shared across JVMs and this can reduce overall memory footprint when multiple JVMs are running on the same host.

This capability has existed since Java 5, but as of Java 9, CDS only allows the bootstrap class loader to load archived classes. The aim of JEP 310 is to extend this to allow the application and custom classloaders to make use of archive files. This feature actually already exists but is currently only available in Oracle JDK, not OpenJDK.
This JEP therefore essentially consists of moving the feature into the open repo from the private Oracle sources, as from Java 10 onwards, regular (non-LTS) releases will be of OpenJDK binaries. That Oracle is moving this feature to the open repos indicates that they have production customers who are using it, and so Oracle will now need to support them on an OpenJDK binary.

Finally, JEP 312 lays the groundwork for improved VM performance, by making it possible to execute a callback on application threads without performing a global VM safepoint. This would mean that the JVM could stop individual threads and not just all of them. Some of the small, low-level improvements that this will enable include:

  • Reducing the impact of acquiring a stack trace sample (e.g. for profiling)
  • Better stack trace sampling by reducing reliance on signals.
  • Improving biased locking by only stopping individual threads for revoking biases.
  • Removing some memory barriers from the JVM

Overall, it seems that Java 10 is unlikely to contain any major new features or performance improvements. This is perhaps to be expected - instead of vast change, it represents the first release in the new, more frequent and gradual release cycle.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

'var' is a no-brainer to me by wakin imgen

I just don't understand why the long wait to implement such a simple feature

Re: 'var' is a no-brainer to me by Ben Evans

Java's first-class virtues include strict backwards compatibility, the principle of least surprise and a certain amount of design conservatism.

Given those, there are no simple features. In this case, what is the correct type to infer on the LHS? If it is the exact type of the RHS, then that actually changes the meaning away from the standard Java idiom.

In many cases one would write an interface type as the type of the LHS. Any method calls on that variable would then be compiled to invokeinterface. With exact type inference then the exact type is visible throughout the rest of the scope, and so method calls will now be compiled to invokevirtual instead.

Now, does that matter? Maybe, maybe not - but it is not completely straightforward and requires some thought, potentially some experimentation, prototyping, discussion, etc. That is for just *one* aspect of *one* very minor feature. I can see at least another two or three aspects of this feature that may also requirew thinking about. Then it has to be considered in the context of how it will interact with other, already existing language features.

There is detailed discussion of all of these aspects in the relevant mailing lists - but the general principle is that if you care about backwards compatibility and take responsibility to existing users and applications seriously, then there are no simple features when changing a mature language like Java.

Still there's no Reified Generic by Hung Nguyen

So, still there's no Reified Generic.
Java's generics is still just a work around.
C# was designed far better than Java, and it will always be.

Re: Still there's no Reified Generic by Ben Evans

There are some nice features in C# and in some ways it definitely benefited from having Java's choices as a reference. However, there are still plenty of things in the C# language and VM that have problems or unfortunate consequences as well.

Language design is about compromise, tradeoffs and the art of the possible. Different languages and systems make different choices, for various reasons and varying priorities. In my opinion, that's a good thing.

Re: 'var' is a no-brainer to me by Martijn Verburg

Type inference for starters. Have a read of the JVM language specification to get an idea of what's involved at compiler or VM level changes :-).

Re: Still there's no Reified Generic by Hung Nguyen

I believe what need to do for the Java language is to have a new version, just one new version, that accept NOT backward-compatibility to fix all the wrong designs have been made so far. Two of them are the lack of a Unified type system (having two different Primitive type such as int and Reference type such as Integer) and the ugly design of Type Erasure Generics. Java's lambda is still a work around in compared with C#'s implementation, for example I cannot mutate a variable declared outside of a lambda. It just make the languages worse if we try adding more new features while keeping backward compatibility. The idea of having a big-non-backward-compatibility has already raised before from this blog blog.joda.org/2010/09/next-big-jvm-language_964...

Have a look how fast and how nice new features are being added to the C# language. That's one of the reason why C# is in both the top 10 most popular and most loved programming language of Stack Overflow survey 2017.

Why don't we conduct a survey to ask for Java developers all from the world to vote for that idea? When we have enough the supporting votes, we can persuade the vendor - the old man Oracle - to make such a big change to the language. I'm sure there're more than 70% developers will support that.

But to conduct that survey, we really need someone who have the impact to the vendor the community. Can you do that Ben?

Re: Still there's no Reified Generic by Ben Evans

Unfortunately, in the ~10 years I've been looking at the development of the Java platform, I have never seen any indication from Sun (and later Oracle) that they'd be interested in making a backwards-incompatible Java version.

MSFT has complete control over .NET and has a completely different business model (and until recently had a product that only had to work on a single operating system that they fully controlled). So, despite some similarities between the languages, I don't believe they're actually that similar from a business perspective.

Re: Still there's no Reified Generic by William Smith

My real worry with this is that features that one developer might hate could be features that another developer loves; Java’a feature set is honestly pretty solid and well balanced. And while it is true that c# has some bells and whistles that Java lacks Java is used far more widely that c# at least according to Tiobe. Can you think of any major language that has done a major abasement of backwards compatibility this late in it’s lifecycle and it not been a disaster?

Re: Still there's no Reified Generic by Hung Nguyen

Just so you are aware that .NET has been rebuilt to be open source and cross platform from 2014, it's called .NET Core.

Re: Still there's no Reified Generic by Hung Nguyen

Java is more popular than .NET because Java is open source and cross platform from the beginning, and that's the reason it get great support from the community. But .NET has been rebuilt from 2014 to be open source and cross platform, called .NET Core, and since then there've been a growing number of great open source projects created such as the Pivotal's SteelToes or Project Polly for building microservices.

But I didn't intend to compare between .NET and JAVA. I love both. What I meant is just Java is already great, but it really need a non backward compatibility version to fix all the wrong design so far to become a "perfect" platform.

Re: Still there's no Reified Generic by Ciprian Khlud

"it will always be" - maybe I'm the guy to disagree: why use strong statements?

There are definitely places where Java language is better designed. For example: lambdas as one method interface and default method interfaces. C# will copy default method interfaces.

Even more, Java tended to have an uniform code-style so it made it more readable. Baking a feature more pays it off.

Out of my mind, Java 9 the language today has better design around: string concatenation (using silently a string builder) and using compact strings, having virtual by default with no runtime cost most of the time. Similarly, I like the idea of having just signed integers, so it avoids a lot of compiler warnings of sign based code.

And, when you will bash me as a Java fanboy: no, I'm a C# developer by trade, but I can see the elephant in the room. Today I'm also doing C++.

Re: 'var' is a no-brainer to me by Henady Hezer

var request = context.getRequest();

what is the request? HttpRequest, KeyExchangeRequest, MockRequest? most idiotic thing that can be introduced to the language to become trash like javascript, scala, python and others.

Re: 'var' is a no-brainer to me by wakin imgen

I am no lang spec reader, but 'var' is not a big feature, it's not trivial, but small if you ask me, actually very small compare to better generics, lambda, etc.

Re: Still there's no Reified Generic by wakin imgen

I am pretty sure one-method interface as lambda is not that great, .NET has delegate from the get-go which is a much better design IMHO. But I'd like one-method interface compatibility with delegate in C#, that would be nice, but no big deal anyway, the issue doesn't come that often anyway. Go does have one feature that I like around func which is that a obj.Func(x, y, z) is compatible with method Func(obj, x, y, z) as anonymous function, I find that quite handy, but then again, no big deal

Re: 'var' is a no-brainer to me by Jonathan Allen

What's context? If you know that, then you probably already know what type of request it is.

Not that it matters. In C#, the vast majority of the time all you really care about is the semantic meaning of the request object and what methods are available when you type "request." The actual type is just trivia.

This is even more true in Java, where we are so obsessed with abstract interfaces that we usually don't know the real type anyways. HttpRequest, KeyExchangeRequest, MockRequest? No, it's a Request interface that could be any of them.

Re: 'var' is a no-brainer to me by Jonathan Allen

In C#, the vast majority of the time it is simply omitting the compile time type check.

The exception is delegates and expressions, both of which change meaning based on what value is assigned.

Re: 'var' is a no-brainer to me by Steve Zara

'var' looks like a bad idea to me. The reason is that it removes the type information from the point of declaration. I have long thought that Java has, to date, got type inference the right way around:

List<String> strings = new ArrayList<>();

The type of the right-hand-side is inferred from the type of the left. But with var:

var strings = .... there is no immediate indication of type. Indeed, the type may not be known until after much compilation.

var == bad by Michael McCutcheon

I agree with the others, var is a BAD idea. When you can't determine the type by looking at the code, the code sucks.

var x = doSomething();

what type is x?

I hope they cancel their plans for including var in Java.

I welcome var by Richard Richter

Seems a lot of var opponents are here. I like it in the arsenal. Instead of PersonDetail personDetail = new PersonDetail() I can just use var personDetail = ... and of course, personDetail name says it all. Can it lead to messy code too? Sure - like many already existing features. I welcome this option that is limited to local variables within methods that should have couple of lines anyway. If I need to scroll for what request means and what type it is something is wrong - var or not.

var != bad by Pavel Grushetzky

I'll be the one to disagree that vars are bad. Not because I had extensive experience with these, but because I think the argument against them is flawed. And it somehow reminds me the arguments against autoboxing back in the day.

If "var x = doSomething()" is confusing in a particular context - don't use it there. Use it in a well-understood context where it helps readability.

I for one would like to be able to write the code bits like this:


var intToName = Map.of(1, "one", 2, "two", 3, "three");
for (var entry : intToName.entrySet())
{
registerNewInteger("New integer discovered!", entry.getKey(), entry.getValue());
}

Re: Still there's no Reified Generic by Dmitry Yegorov

In Java-world we use Kotlin (or Scala) for that.

Re: Still there's no Reified Generic by Ladislav Jech

I also think this way... Make it greenfield, reuse what is reusable and make it happen. Push fresh air into old pipes... just wish.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

22 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT