
JDK 10 Early Access Release Notes - javinpaul
http://jdk.java.net/10/release-notes
======
PedroBatista
Looks like a lot of housekeeping is taking place.

I just wish they implemented a native and full code hot-reload support on the
jvm, instead of relying on external tools/hacks that work sometimes.

That alone would single-handedly improve productivity by an order of
magnitude.

~~~
vbezhenar
I agree wholeheartedly. Using jrebel is so much of a productivity boost, but I
want to avoid proprietary tools as much as possible.

~~~
severino
There're some open source alternatives, such as this one, with less features,
though:

[http://dcevm.github.io/](http://dcevm.github.io/)

However, I couldn't make it work with my current project when I tried some
years ago. I haven't tried again since.

------
ptx
If anyone other than me was concerned that the "system property to disable JRE
last usage tracking" was something like the enabled-by-default telemetry of
.NET Core[1] (which made me give up on it in disgust), it's apparently[2] not
– it's just some (commercial add-on) logging feature.

[1]
[https://github.com/dotnet/cli/issues/3093](https://github.com/dotnet/cli/issues/3093)

[2] [https://docs.oracle.com/javacomponents/usage-
tracker/overvie...](https://docs.oracle.com/javacomponents/usage-
tracker/overview/)

------
tmd83
Beyond housekeeping could only find one real big changes that is parallel full
GC for G1. That's a big one in controlling the worst case.

~~~
AlphaSite
Doesn’t java 10 add ‘var’ to the language?

~~~
pjmlp
Yes, just the initial support.

There are some additional ergonomic improvements planned for 11, like using
them in lambda parameters.

~~~
tmd83
I might have missed it but didn't find that in the release note. Could there
be language changes that are not part of this release note?

~~~
pjmlp
You can find them on the JEP list and JDK Jira.

This is a pre-release, I imagine until the actual release they will properly
update them.

------
lvh
As you can tell from the relnotes, there are a lot of removals. Fortunately,
they're all following a pretty reasonable deprecation procedure, but I still
can't shake what happened with Jigsaw and JDK9. Software broke. That didn't
happen (regularly) before unless that software was doing patently silly
things. This was different: _most_ software broke. Here's hoping that doesn't
turn into a pattern.

~~~
rhencke
I do wonder about this. Granted, Java 9 (and 10) are not LTS releases - we'll
have to wait for 11 for that.
([http://www.oracle.com/technetwork/java/eol-135779.html](http://www.oracle.com/technetwork/java/eol-135779.html))

But, Java 8 will stop receiving public updates next year, and pretty much
everywhere I've looked, folks are sticking on Java 8.

I am hoping I'm wrong, but I wonder if we will see Java 8 be forked, and live
on, by community effort, as the cost to maintain it would be lower than the
cost of risking moving to Java 11. For a lot of businesses, I don't think the
reality has set in yet, and I don't think they're going to realize what
situation they're in until Java 8 hits EOL.

~~~
pjmlp
There are companies still deploying Java 1.4 into production in 2018, just
because they don't want to touch their beloved servers.

This is nothing new.

~~~
lvh
Would you agree that the breakage between 1.4 and 1.5, 1.5 and 1.6, 1.6 and
1.7, 1.7 and 1.8 is not comparable to the breakage that Jigsaw alone
introduced between 1.8 and 1.9?

~~~
pjmlp
Yes, I do agree.

However stuff like JDBC interface changes comes up as breaking changes in
previous releases.

In what concerns Java 9, Mark Reinhold keeps doing presentations about how all
Java relevant frameworks and tools are already Java 9 compliant. Including
many that they validated against in Maven repositories.

Last presentation I saw was at FOSDEM.

So it appears to be a major issue to anyone wanting to migrate Java 9 without
updating the frameworks as well, having some kind of special case library, or
using APIs that were always documented as internal.

~~~
lvh
The QA outreach page [0] suggests maybe about half the projects are ready. The
ones that aren't include Netty and SLF4J. Those aren't small projects. Is that
page outdated or does "JDK9 ready" not really mean "JDK9 ready"?

EDIT: Maybe it's outdated; SLF4J and Netty do claim to be JDK9-ready.

[0]:
[https://wiki.openjdk.java.net/display/quality/Quality+Outrea...](https://wiki.openjdk.java.net/display/quality/Quality+Outreach)

------
malft
> The clear passwords present in jmxremote.password file will now be over-
> written by their SHA3-512 hash by the JMX agent

I must be misreading this. As far as I can tell the ability to read the new
format was added in the same version. Did someone forget about forwards
compatibility _in the jvm_?

~~~
ptx
Also it introduces a race-condition (according to the release notes) where
changes made to the file will be lost while it's being converted.

Also they don't say anything about iterating the hash, in which case the
password can be recovered anyway with rainbow tables, so what's the point of
hashing it?

------
zng00
Sexy as always

