7 ms·

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 you

by jwn 10y ago

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?

hyperpape 10y ago
Everyone has their own priorities, but ValueTypes are huge. Also, I don't think this falls under Valhalla (and I'm not sure if it's been committed yet), but the possibility of reasonable type inference in Java 10 would make me rather happy.
- papercrane 10y ago
  I'm pretty excited about that one, it's JEP-286, http://openjdk.java.net/jeps/286 http://openjdk.java.net/jeps/286. Valhalla is pretty big. Goetz described it as pulling on a very long string. It's going to touch everything in the JVM, including reifing generics, although as I understand it, erasure of Objects may be here to stay for the language.
  - whateveracct 10y ago
    Erased generics will surely stay and are a good thing. If they were removed, Scala would be in trouble (or rather, scalac would have to perform erasure itself, which in turn would mean that interop from Java wouldn't be good anymore). What's broken in the JVM isn't erased generics but instead runtime reflection that is a lie due to erasure. Type erasure though is definitely an example of Java getting something very right for the wrong reasons.
    - jdmichal 10y ago
      Are you attempting to separate the concepts of specialization vs reified generics? Java does neither right now, and both effects are due to type erasure -- the runtime simply doesn't have the necessary information. I'm not quite sure where you're trying to draw the line. Furthermore, runtime specialization (as opposed to compile-time) would seem to require reified types. So that further confuses things. But you can definitely have reified types without specialization, which I think is the point that you are trying to convey.
    - int_19h 10y ago
      Aside from backwards compatibility, what's good about type erasure for generics?
      - jsmith0295 10y ago
        Doing it a better way is hard
        int_19h 10y ago
        Is it, though? The most basic implementation, where things are still erased at runtime by the JIT, should be fairly simple, although it will not give the expected perf gains, of course. Either way, CLR and C# did it a long time ago, and in the same time period when Java acquired its type-erased generics.
        jsmith0295 10y ago
        They care too much about backwards compatibility I think. .NET had done generics this way from the beginning.
      - dragonwriter 10y ago
        It permits languages on the platform with substantially-richer compile-time type systems than the primary language on the platform with good interior stories (this was, IIRC, a substantial problem with Scala.NET.)
merb 10y ago
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.
- jwn 10y ago
  Good answer, thanks =) My question earlier was an honest question, asked out of curiosity...
- smoyer 10y ago
  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 10y ago
    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 10y ago
      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() { ... }
theandrewbailey 10y ago
JDK 10 will have TLS Fallback SCSV and native ChaCha20 support, though I wish they were in JDK 9.
- samch 10y ago
  Not sure why you have to wait. I use ChaCha in production in JDK 8: https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/bouncycastle/crypto/engines/ChaChaEngine.java https://github.com/bcgit/bc-java/blob/master/core/src/main/j... Why would native be any better? I would think that as long as the implementation matches the reference it wouldn't matter.
  - theandrewbailey 10y ago
    Last weekend, I added Bouncy Castle as the security provider in my dev environment, but my server did not show ChaCha20 in the list of available TLS ciphers. I was not convinced that my server was even using BC. Knowing that if you don't know what you're doing and mess around with crypto too much that you can get burned, I gave up. ECDHE RSA AES GCM for now.
    - samch 10y ago
      I think I see where you're coming on that. For most of my applications, I terminate TLS connections with nginx. I do use ChaCha for high-speed encryption in other areas, though. The BC libraries have always worked great for me.
imtringued 10y ago
Value types combined with generic specialisation results in less memory usage, higher data locality, less gc pressure. Basically a big increase in performance on top of the already very good JIT.

by jwn 10y ago

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?

hyperpape 10y ago

Everyone has their own priorities, but ValueTypes are huge. Also, I don't think this falls under Valhalla (and I'm not sure if it's been committed yet), but the possibility of reasonable type inference in Java 10 would make me rather happy.

papercrane 10y ago
I'm pretty excited about that one, it's JEP-286, http://openjdk.java.net/jeps/286 http://openjdk.java.net/jeps/286. Valhalla is pretty big. Goetz described it as pulling on a very long string. It's going to touch everything in the JVM, including reifing generics, although as I understand it, erasure of Objects may be here to stay for the language.
- whateveracct 10y ago
  Erased generics will surely stay and are a good thing. If they were removed, Scala would be in trouble (or rather, scalac would have to perform erasure itself, which in turn would mean that interop from Java wouldn't be good anymore). What's broken in the JVM isn't erased generics but instead runtime reflection that is a lie due to erasure. Type erasure though is definitely an example of Java getting something very right for the wrong reasons.
  - jdmichal 10y ago
    Are you attempting to separate the concepts of specialization vs reified generics? Java does neither right now, and both effects are due to type erasure -- the runtime simply doesn't have the necessary information. I'm not quite sure where you're trying to draw the line. Furthermore, runtime specialization (as opposed to compile-time) would seem to require reified types. So that further confuses things. But you can definitely have reified types without specialization, which I think is the point that you are trying to convey.
  - int_19h 10y ago
    Aside from backwards compatibility, what's good about type erasure for generics?
    - jsmith0295 10y ago
      Doing it a better way is hard
      - int_19h 10y ago
        Is it, though? The most basic implementation, where things are still erased at runtime by the JIT, should be fairly simple, although it will not give the expected perf gains, of course. Either way, CLR and C# did it a long time ago, and in the same time period when Java acquired its type-erased generics.
        jsmith0295 10y ago
        They care too much about backwards compatibility I think. .NET had done generics this way from the beginning.
    - dragonwriter 10y ago
      It permits languages on the platform with substantially-richer compile-time type systems than the primary language on the platform with good interior stories (this was, IIRC, a substantial problem with Scala.NET.)

merb 10y ago

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.

jwn 10y ago
Good answer, thanks =) My question earlier was an honest question, asked out of curiosity...
smoyer 10y ago
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 10y ago
  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 10y ago
    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() { ... }

theandrewbailey 10y ago

JDK 10 will have TLS Fallback SCSV and native ChaCha20 support, though I wish they were in JDK 9.

samch 10y ago
Not sure why you have to wait. I use ChaCha in production in JDK 8: https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/bouncycastle/crypto/engines/ChaChaEngine.java https://github.com/bcgit/bc-java/blob/master/core/src/main/j... Why would native be any better? I would think that as long as the implementation matches the reference it wouldn't matter.
- theandrewbailey 10y ago
  Last weekend, I added Bouncy Castle as the security provider in my dev environment, but my server did not show ChaCha20 in the list of available TLS ciphers. I was not convinced that my server was even using BC. Knowing that if you don't know what you're doing and mess around with crypto too much that you can get burned, I gave up. ECDHE RSA AES GCM for now.
  - samch 10y ago
    I think I see where you're coming on that. For most of my applications, I terminate TLS connections with nginx. I do use ChaCha for high-speed encryption in other areas, though. The BC libraries have always worked great for me.

imtringued 10y ago

Value types combined with generic specialisation results in less memory usage, higher data locality, less gc pressure. Basically a big increase in performance on top of the already very good JIT.