
JDK 9 release schedule - erl
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-October/005092.html
======
spullara
The next interesting thing for the JVM is value types in Java 10. It may
convince me to use it pre release.

~~~
namelezz
Yeah. Unfortunately, unsafe is removed in JDK 9. :(

Edit: It seems removing unsafe is just a rumor.

~~~
needusername
BS

~~~
needusername
No seriously Unsafe is not removed, it's not even deprecated because there is
no replacement. I don't know where people get this idea from. Did anybody
check the source? Of course not. Just repeating something somebody wrote on
the internet somewhere.

Unsafe is going to stay

[https://www.youtube.com/watch?v=4HG0YQVy8UM&t=1s](https://www.youtube.com/watch?v=4HG0YQVy8UM&t=1s)

------
merb
well not too bad if they could deliver the jdk 10 (valhalla) a faster. jdk 9
is less important than jdk 10.

~~~
jwn
Looking at
[http://openjdk.java.net/projects/valhalla/](http://openjdk.java.net/projects/valhalla/),
I don't see a whole lot of value compared to JDK9. What's your basis for
wanting 10 so badly?

~~~
merb
well as others already pointed out, value types. this changes the way how the
JVM uses Memory in certain ways and might be a huge improvement for a lot of
stuff.

specialized generics. this is a huge one, too, less boxing is always a win.

JEP-286 less typing.

Maybe Project Panama and maybe a even better AOT.

Compared to what JDK 9 brings, this is huge. JDK 9 brings a Module system
which was already possible (and a lot of stuff around it which didn't exist),
a new GC algorithm, Tiff Image I/O, jshell, ALPN, http2 client, reactive-
streams. (P.S.: not everything is complete here, but this stuff will probably
be used by most)

JDK9 mostly brings stuff that was already missing and provided by other
libraries. JDK10 will probably change a lot of more things in the JVM
ecosystem.

~~~
smoyer
If you want less typing, then you definitely want Lombok
([https://projectlombok.org/](https://projectlombok.org/)). At JavaOne this
year, they also showed a proposed shortcut for data object (@Data in Lombok).

    
    
      public class something(String name, int age) {
        ...
      }

~~~
ap22213
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?

~~~
smoyer
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 generates:

    
    
      public String getName() { ... }
      public void setName(String name) { ... }
      public int getAge() { ... }
      public void setAge(int age) { ... }
      public boolean equals(Something other) { ... }
      public int hashcode() { ... }
      public String toString() { ... }

~~~
marktangotango
The real win is when you do Effective Java chapter 1 immutable objects with
@Builder. I worked at a Big Dumb corp that eschewed lombok, and required full
test coverage of getter, setters, builders, toString, equals, and hash
mehtods, and 100% javadoc coverage for all methods (even private methods). It
was insanity, and carpal tunnel inducing. Lombok would have reduced the
workload by 90%.

~~~
smoyer
Yes! ... And there are a lot of stages between a fully immutable object @Value
and @Data (described above). The @Builder is so much better than most but you
can also easily create a POJO with a portion of its fields immutable too (a
combination of @NonNull, @Getter, @Setter and @RequiredArgsConstructor).

------
gravypod
Does anyone have the full changelog of added/new features.

~~~
geodel
Here is the list:

[http://openjdk.java.net/projects/jdk9/](http://openjdk.java.net/projects/jdk9/)

~~~
djsumdog
Am I missing properties? Dear god it's 2016, with Java8, and we still don't
have real, language-defined properties? I mean you can use Lombok (and if
you're not, you should be!), but that's something that really need to be built
into the language. C# has them, Python has them, Ruby has them .. even other
JVM languages like Scala have them!

I'm really glad I get to do Scala development full time. Even with all the
recent improvements to Java 8, I feel the future of Java isn't the language,
but the JVM and all the other languages that run on top of it (Scala, Groovy,
Clojure, JRuby, etc.)

~~~
pjmlp
> Scala, Groovy, Clojure, JRuby, etc.

I am yet to work in a Java project where I am allowed to use any of them.

Regarding the properties I really don't get what is the big deal.

No one used to complain about C++ properties, that besides having to write
accessors and mutator methods, one needs to declare them on the header files
as well.

Or the first version of C# properties isn't much shorter than how it is done
in Java, which is still required when extra logic needs to be implemented.

It is been a few years since I have done any Python, but don't do they require
two separate functions that are then mapped to a property declaration?

~~~
jjoonathan
> 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;
        }

~~~
fauigerzigerk
Adding 8 comment lines doesn't help your argument. More importantly though,
you need to consider the mental load of constantly thinking about and
remembering whether something is a property or a method.

I used to be an advocate property syntax, but after seeing them used in C# and
now in Swift I have completely changed my mind. It's an inconsistent mess that
Java has avoided at the small price of some more lines of code (that are
mostly auto generated and need no documentation)

~~~
int_19h
Can you clarify what's inconsistent about properties in C# (seeing how this is
the most obvious counterpart), and how it doesn't apply to Java's properties-
by-convention?

~~~
fauigerzigerk
In Java you can be reasonably sure that whenever you need something from an
object you call a method of its class. That's one thing you rarely have to
think about in practice. Yes there are exceptions (sometimes painfully
inconsistent ones) where fields are accessed directly, but at least that gives
you some performance guarantees. It's generally not a big concern.

In C# you do have to think about it all the time. Most types have both
properties and methods and in many cases it's not obvious whether the author
of that type had the same idea about whether or not something should be a
property or a method as you do. Where you only have to remember a name in
Java, you have to remember both a name and its syntactic category in C#. One
more thing to keep in mind equals greater mental load.

In fact, the guidelines for choosing between one and the other include
considerations that should be of no concern to the user of a public interface
([https://msdn.microsoft.com/en-
us/library/ms229054(v=vs.100)....](https://msdn.microsoft.com/en-
us/library/ms229054\(v=vs.100\).aspx)). If any of these implementation details
change, the logical conclusion would be to change the public interface from
property syntax to method syntax or vice versa. That's what I call
inconsistent.

If you're saying that the choice between getX() and x() in Java is also
somewhat inconsistent then you are absolutely right. It's just not a problem
on the same scale as in C#.

~~~
breischl
I would argue that the distinction is actually a good thing. If you're working
with a reasonably well-designed library, then the fact that something is a
method instead of a property tells you it might be doing some serious (or just
slow) work. Whereas in Java calling getX() might do just about anything.

And if the implementation of a C# property changes in any of the ways that
would make it a method, that probably deserves to be surfaced as a breaking
change in the API. That's a feature, not a bug. eg, I would certainly want to
know if the implementation of a property was changed from a field access to a
network call.

~~~
fauigerzigerk
The syntactical distinction makes us believe that there is a technical
difference as well, but that is not the case. I find that misleading. If
properties don't give us any technical guarantees, then a naming convention as
in Java seems more appropriate to me.

And if you look at the guidelines I linked to, you'll see that the criteria
that are supposed to tell us whether or not to use a property are much more
subtle than making a network call vs accessing a field. Can you really justify
a breaking change to a public interface because a type conversion is
introduced in the implementation of property?

I think disguising a function call as a direct variable access is much more
problematic than calling a function that may or may not do more than return
the value of a variable.

That said, I do realize that reasonable people can absolutely disagree on this
issue.

~~~
breischl
I think disguising a _simple_ function call as a variable access is sensible.
But yes, people can disagree on this. I think the C# and Java designers are
probably all smart people who thought about this a lot more than the two of
us. :)

>>Can you really justify a breaking change to a public interface because a
type conversion is introduced in the implementation of property?

I just quickly re-read that page, but I don't see what you're referring to
here.

~~~
int_19h
I think it's a reference to this:

"The operation is a conversion, such as the Object.ToString method."

But this only pertains to the conversion of the object on which the property
is defined. In other words, you should have methods like ToString or
AsEnumerable, rather than properties like String or Enumerable, even though
other rules would indicate property to be valid (idempotent, fast, no
arguments). This rule is just an indication that properties represent
conceptual attributes of an object; and the result of a conversion of an
object to something else is not an attribute.

------
javanese
So, uh, how many people are using Java 8?

I still see projects using Java 5...

~~~
djsumdog
> I still see projects using Java 5...

Are you serious? Even the worst shops I've been at have at least moved their
JVMs to Java7 back around 2014. I mean you can take all your existing JARs
from Java4 and run them on Java8 and nothing should break. Recompiling them
might be another issue, but still not a huge one.

~~~
josho
True, but if you are running something like WebSphere or Weblogic then
upgrading your JVM invalidates product support. So, now you have to upgrade
product versions, which often requires changes to deployment scripts, breaking
changes in those products, new software licenses, etc.

Having said that being on and old supported version of these products means
you are at least enjoying Java 6.

~~~
kpil
... and we use WebSphere 7 because we like to read hackernews while publishing
our code ...

~~~
pjmlp
You lucky ones!

My last contact with Websphere was in 2014 and the customer was still using
6.1 on their production servers.

------
haalcion3
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 code which is off in its own directory and can easily be used by existing JavaScript and HTML.

* Similarly be able to generate the JavaScript front-end code that use those JS client libraries with easily writable/pluggable generators so that it can generate Angular 1.x, 2, ReactJS, Bootstrap, etc. in "best-practice" ways that can be updated frequently as the community changes.

* Simultaneously provide the option to serve very similar pages using straight HTML, degrading even to the point that a text only browser could use the site easily.

* Easily define responsiveness of pages.

* Support multiple 3D, 4D, etc. interfaces with customizable inputs to be forward-compatible without overdoing complexity (i.e. it's really pluggable).

* Similarly support generation of almost any kind of service integration, with easy pluggable authN/R.

* Easily scalable.

* Relational, noSQL, versioning DB (noms) support.

* Make fun books for kids and a site where they can share what they've written, write games, build things, etc.

* Make it integrate with every browser, even some older versions, operating systems.

* Make it compile low-level vs. byte code so it's fast as shit.

~~~
gshx
Thanks for the bullets. This is a good list but some of the points like
"Easily scalable" and "DB support" are not cheaply available in any runtime
and require careful attention to detail as well as domain-specific thinking.
IMHO, the JVM already does a lot of heavy-lifting in this regard.

~~~
haalcion3
It comes down to this: are those developing the language thinking about how to
add features just to try to hone and hold on to the enterprise developers that
still use it, or are they thinking about what would make it more fun,
productive, and practical?

Java's going to be around a long time. Those that stick with it will be fine.
COBOL programmers made a lot of money in 1999, and some people still use
Fortran.

But, Java's original big mantra was "write once, run anywhere." Such idealism
then. Cool things have been done in the past few years, but can't we do more?

~~~
parasubvert
I work for Pivotal so I'm biased. But I'd take a long look at Sprint Boot in
terms of "fun , productive , practical" Java:
[https://projects.spring.io/spring-boot/](https://projects.spring.io/spring-
boot/)

In particular: \- curated and tested open source library dependencies to the
point that you can generate a single JAR for anything you might want to build
on the server: [http://start.spring.io/](http://start.spring.io/)

\- Annotations and APIs to make REST service development a breeze

\- native support to build apps that use SQL, NoSQL and other Data systems
without plumbing: [http://docs.spring.io/spring-boot/docs/current-
SNAPSHOT/refe...](http://docs.spring.io/spring-boot/docs/current-
SNAPSHOT/reference/htmlsingle/#boot-features-nosql)

\- SSH shell/CLI into your JVM to manage your JVM

\- Actuator to provide production metrics for your system

\- declarative security that allows you to build Oauth2 enabled apps in maybe
20 lines of code/annotations

\- great symbiosis with modern JavaScript for responsive sites, eg
[https://spring.io/blog/2015/01/12/spring-and-angular-js-a-
se...](https://spring.io/blog/2015/01/12/spring-and-angular-js-a-secure-
single-page-application)

\- Cloud connectors to make it easy to run your app on Heroku, Kubernetes,
Mesos or Cloud Foundry, or to leverage NetflixOSS components, or to build
stream processing applications (Spring cloud stream / data flow)

It is being downloaded and used at a very high rate (a couple million a
month).

~~~
snuxoll
Spring Boot is awesome, thank you guys for your massive contribution. All of
my co-workers are .Net guys and keep trying to say that Java is dead now that
.Net Core is out, but I still haven't found a server-side solution better than
Spring yet :)

~~~
parasubvert
Hey thanks ... .NET core is awesome too, they should check out
[http://www.steeltoe.io/](http://www.steeltoe.io/) for our attempt to bring
Spring love their way :p

~~~
snuxoll
Cool, but much less useful than the full suite of Spring projects (which is
why I love Spring in the first place, it's basically batteries included but
everything remains modular so I can pick and choose what I want). .Net Core is
a great stepping stone, but between deployment headaches (I can just run yum
install java-1.8.0-openjdk to get a JVM and run a spring-boot app, .Net Core
forces me to bundle the runtime right now) and the lack of a cohesive
integrated suite of components keeps my heart with Spring (even if I'm forced
to use .Net at work more often than not).

------
ksec
Does anyone know if Truffle and Graal will ship with JDK 9 ?

~~~
ivanche
While I can't say with 100% confidence, I listened Graal presentation at
Voxxed Days Belgrade one month ago and the presenter (IIRC, Martin Tonchev)
said it won't be ready for JDK9 and that they aim at JDK10.

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

~~~
Tharkun
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.

------
sytringy05
I cant wait for that REPL.. I've almost always got the intellij debugger
running with the Evaluate Expression window open

------
Bjartr
Just in time for GWT to get support for Java 8

------
Scarbutt
Will the "modular source code" feature help handle the "jar hell" problem?

~~~
geodel
It might help you migrate to module hell.

~~~
CSDude
Well we have a fat jar of 100 MB to deploy on Flink, so I guess it will be
much larger if all modules have submodules.

------
puppetmaster3
This is posted a year early. Please post this in a year.

I see no JSON, I have to use a 3rd party lib. And ... no word on fixing
logging divergence.

~~~
benjiweber
You can map JSON onto java interface types with the built in Nashorn.

[http://paste.debian.net/883460/](http://paste.debian.net/883460/)

( May be incredibly unsafe, only just thought of it now. )

