13 ms·

Proposed schedule change for JDK 9

112 points by jcytong 10y ago

ddon 10y ago
In short, Mark proposes a four-month extension of the JDK 9 schedule, moving the General Availability (GA) milestone to July 2017, and the reason is because number of open bugs that are new in JDK 9 is quite a bit larger than it was at this point in JDK 8.
- riffraff 10y ago
  ..and they still need to iron out some details of project jigsaw (the new module system, which was originally planned for Java 7)
  - needusername 10y ago
    The work currently being done on Jigsaw is not details at all.
nomercy400 10y ago
So, one of the complexer part of Java isn't completely finished, and they want to postpone the release instead of releasing something buggy. I'm fine with that. Everybody survived with Java6 for half a decade as well. And three years with Java7.
- pjmlp 10y ago
  Me too, specially on Android where we still need to survive with Java 6 and cherry picked pieces from Java 7 and Java 8. Most likely it will never see 100% support for Java 8, or anything else that comes afterwards.
  - cageface 10y ago
    If you can get away with using it Kotlin fixes almost everything I dislike about Java and works for Android development today.
    - pjmlp 10y ago
      Actually I spend most of my time on C++ side, which also has its own share of issues regarding Android tooling. Still checking in how Kotlin support evolves, my experience using languages like Turbo Pascal, Delphi and Oberon made me weary of using using languages that aren't directly supported by platform owners for production code.
      - rallycarre 10y ago
        Kotlin is amazing. It takes the best parts of Scala while keeping the simplicity of Java. It may not be supported by Google but it was created by Jetbrains, the developer of Ideaide which is what Android Studio is based on, so it's support is top notch. The best part of Kotlin is there is near zero cost to using it. You can learn it in a day and is fully interoperable with Java. :)
        premium-concern 10y ago
        That's kind of nonsense. Kotlin adds some syntax sugar to Java, but it's not related to Scala in any reasonable way.
- needusername 10y ago
  What bothers me is that there are tons of improvements in the VM area that we'll have to wait for longer. All of this only because Oracle stubbornly merged Jigsaw into trunk before it was even close the ready. All the issues surfacing now people have been telling Oracle for the past five years. Or Oracle simply could have looked at the experience gained with OSGi over the past decade, especially the OSGi enterprise specification.
deleted 10y ago
[deleted]
wocram 10y ago
Is anyone eagerly awaiting JDK9?
- akerro 10y ago
  My company is starting a few new bigger projects and we're building it on java8 right now keeping in mind that we will make architectural changes once java9 is released and rewrite some parts to use jigsaw. Classpath mechanism will be finally deprecated.
- pjmlp 10y ago
  Not really, getting to deploy Java 8 projects is still a big issue. Most enterprise deployments are limited by what the IT guys know and are willing to accept on their servers.
  - needusername 10y ago
    Uhm, Java 7 is EOL unless you have an Oracle support contract. Oracle support contract and virtualisation don't mix. EOL software and compliance don't mix.
    - pjmlp 10y ago
      Last year I was working at a customer still doing 1.4 deployments. As you know from Windows XP, not everyone cares about EOL notices.
- ivan_gammel 10y ago
  I'd like to see it in my cloud deployments. Modularity means smaller size of server jdk and thus smaller size of images. Faster deployments and builds, less traffic and storage in build farms...
  - axelfontaine 10y ago
    So are we! Currently at Boxfuse (https://boxfuse.com/ https://boxfuse.com/) we create VMs around 40 MB in size for Java 8 and we very much look forward to Java 9 to reduce this even further!
eDameXxX 10y ago
OFF-TOPIC: I am the only one who is not that happy that Java is so popular? I don't even know where that feeling come from.
- pjmlp 10y ago
  I am happy that Java is popular. I know it since Sun introduced it and it was a saner experience than C++ back in the day, when each compiler implemented their own vision of the ongoing working standard. There are only three things I don't like about Java, proper AOT compilation is only available in commercial JDKs and lack of value types, and use of @Overrides annotation instead of adding a proper keyword. The first two will hopefully get addressed in Java 10, assuming Oracle doesn't change their minds about the language.
  - adimitrov 10y ago
    I agree with your points, but would like to add another one: runtime generic type erasure needs to go. Whether it is through reification or some other means, I don't care, but it feels like every single time I sit down to write some solid core-of-the-program basic code, I run up against erasure. It's probably not every time, but you get the point. That said, I think that Java 8 is in a good state, and I really liked its improvements. For Java 9, the new modularization system seems interesting, and I'll be happy to ditch classpaths!
    - pjmlp 10y ago
      > runtime generic type erasure needs to go. Is is part of the value type related changes. http://www.oracle.com/technetwork/java/javase/community/jlssessions-2016-3114175.html http://www.oracle.com/technetwork/java/javase/community/jlss... How it will actually look like is still WIP.
      - aardvark179 10y ago
        I think you should be very careful with statements like that. The Valhalla work adds a mechanism by which generic types can be reified, but reference types in Java are not proposed to be reified as that would cause big interoperability problems with existing code. However the mechanism introduced for reifying value generics could be used by other JVM languages to provide reified reference generic types. So HashMap<MyRefClass> will always remain the same class as HashMap<Object> when created in Java code, but might not be the same in another JVM language, and HashMap<MyValueType> will never be the same class as HashMap<Object>.

112 points by jcytong 10y ago

ddon 10y ago

In short, Mark proposes a four-month extension of the JDK 9 schedule, moving the General Availability (GA) milestone to July 2017, and the reason is because number of open bugs that are new in JDK 9 is quite a bit larger than it was at this point in JDK 8.

riffraff 10y ago
..and they still need to iron out some details of project jigsaw (the new module system, which was originally planned for Java 7)
- needusername 10y ago
  The work currently being done on Jigsaw is not details at all.

nomercy400 10y ago

So, one of the complexer part of Java isn't completely finished, and they want to postpone the release instead of releasing something buggy. I'm fine with that. Everybody survived with Java6 for half a decade as well. And three years with Java7.

pjmlp 10y ago
Me too, specially on Android where we still need to survive with Java 6 and cherry picked pieces from Java 7 and Java 8. Most likely it will never see 100% support for Java 8, or anything else that comes afterwards.
- cageface 10y ago
  If you can get away with using it Kotlin fixes almost everything I dislike about Java and works for Android development today.
  - pjmlp 10y ago
    Actually I spend most of my time on C++ side, which also has its own share of issues regarding Android tooling. Still checking in how Kotlin support evolves, my experience using languages like Turbo Pascal, Delphi and Oberon made me weary of using using languages that aren't directly supported by platform owners for production code.
    - rallycarre 10y ago
      Kotlin is amazing. It takes the best parts of Scala while keeping the simplicity of Java. It may not be supported by Google but it was created by Jetbrains, the developer of Ideaide which is what Android Studio is based on, so it's support is top notch. The best part of Kotlin is there is near zero cost to using it. You can learn it in a day and is fully interoperable with Java. :)
      - premium-concern 10y ago
        That's kind of nonsense. Kotlin adds some syntax sugar to Java, but it's not related to Scala in any reasonable way.
needusername 10y ago
What bothers me is that there are tons of improvements in the VM area that we'll have to wait for longer. All of this only because Oracle stubbornly merged Jigsaw into trunk before it was even close the ready. All the issues surfacing now people have been telling Oracle for the past five years. Or Oracle simply could have looked at the experience gained with OSGi over the past decade, especially the OSGi enterprise specification.

deleted 10y ago

[deleted]

wocram 10y ago

Is anyone eagerly awaiting JDK9?

akerro 10y ago
My company is starting a few new bigger projects and we're building it on java8 right now keeping in mind that we will make architectural changes once java9 is released and rewrite some parts to use jigsaw. Classpath mechanism will be finally deprecated.
pjmlp 10y ago
Not really, getting to deploy Java 8 projects is still a big issue. Most enterprise deployments are limited by what the IT guys know and are willing to accept on their servers.
- needusername 10y ago
  Uhm, Java 7 is EOL unless you have an Oracle support contract. Oracle support contract and virtualisation don't mix. EOL software and compliance don't mix.
  - pjmlp 10y ago
    Last year I was working at a customer still doing 1.4 deployments. As you know from Windows XP, not everyone cares about EOL notices.
ivan_gammel 10y ago
I'd like to see it in my cloud deployments. Modularity means smaller size of server jdk and thus smaller size of images. Faster deployments and builds, less traffic and storage in build farms...
- axelfontaine 10y ago
  So are we! Currently at Boxfuse (https://boxfuse.com/ https://boxfuse.com/) we create VMs around 40 MB in size for Java 8 and we very much look forward to Java 9 to reduce this even further!

eDameXxX 10y ago

OFF-TOPIC: I am the only one who is not that happy that Java is so popular? I don't even know where that feeling come from.

pjmlp 10y ago
I am happy that Java is popular. I know it since Sun introduced it and it was a saner experience than C++ back in the day, when each compiler implemented their own vision of the ongoing working standard. There are only three things I don't like about Java, proper AOT compilation is only available in commercial JDKs and lack of value types, and use of @Overrides annotation instead of adding a proper keyword. The first two will hopefully get addressed in Java 10, assuming Oracle doesn't change their minds about the language.
- adimitrov 10y ago
  I agree with your points, but would like to add another one: runtime generic type erasure needs to go. Whether it is through reification or some other means, I don't care, but it feels like every single time I sit down to write some solid core-of-the-program basic code, I run up against erasure. It's probably not every time, but you get the point. That said, I think that Java 8 is in a good state, and I really liked its improvements. For Java 9, the new modularization system seems interesting, and I'll be happy to ditch classpaths!
  - pjmlp 10y ago
    > runtime generic type erasure needs to go. Is is part of the value type related changes. http://www.oracle.com/technetwork/java/javase/community/jlssessions-2016-3114175.html http://www.oracle.com/technetwork/java/javase/community/jlss... How it will actually look like is still WIP.
    - aardvark179 10y ago
      I think you should be very careful with statements like that. The Valhalla work adds a mechanism by which generic types can be reified, but reference types in Java are not proposed to be reified as that would cause big interoperability problems with existing code. However the mechanism introduced for reifying value generics could be used by other JVM languages to provide reified reference generic types. So HashMap<MyRefClass> will always remain the same class as HashMap<Object> when created in Java code, but might not be the same in another JVM language, and HashMap<MyValueType> will never be the same class as HashMap<Object>.