17 ms·

JDK 7 Features

61 points by puredanger 16y ago

mey 16y ago
There are a lot of great steps forward for the Java language in 7. My only question is when is Oracle going to release it so it can start being adopted?
10ren 16y ago
TLS 1.2 = Transport Layer Security: http://tools.ietf.org/html/rfc5246 http://tools.ietf.org/html/rfc5246
c00p3r 16y ago
Java is everywhere. Berkeley CS162 course uses Java language to teach OS Design and Internals - they wrote a pseudo-code examples in Java, a-la SaveRegisters(). It is a madness, Isn't it? ^_^
- points 16y ago
  Why madness? It has a clear, logical, consistent and easy to understand syntax.
  - c00p3r 16y ago
    Really? Easier than C syntax, which is a more appropriate in this context, and on which Java's syntax is based upon?
    - sid0 16y ago
      > Really? Easier than C syntax Significantly easier. Think about all those pointers that simply aren't there now. > which is a more appropriate in this context This is a value judgement. The generally nicer semantics (automatic memory management! proper strings!) are also worth a lot.
    - points 16y ago
      Way easier than C syntax. Even though I have long mastered various assembly languages and higher level languages, C pointers and their arithmetic still confuses me. There's nothing worse than something like bar = *[&foo + 88] or whatever it is.
- sid0 16y ago
  I'm a TA for an OS course that is closely following the Berkeley CS162 course, down to using Java for assignments. We've had much less trouble than with the C++ we used to use.
  - c00p3r 16y ago
    Why not a plain C which is an obvious choice? I think I know the answer - "because of a buzz". ^_^ And of course, using a VM-hosted language to describe things which are on two levels of abstraction lower is a little bit funny.
    - sid0 16y ago
      > Why not a plain C which is an obvious choice? Because manual memory management is a PITA. > And of course, using a VM-hosted language to describe things which are on two levels of abstraction lower is a little bit funny. Why? As long as you're clear that it's a pedagogical tool, it's perfectly fine. And there are incubation OSes (e.g. Singularity) that are almost entirely managed.
      - c00p3r 16y ago
        We're talking about simplicity and clarity of language's syntax? Why memory management? btw, to whom memory management is a PITA?
        sid0 16y ago
        > We're talking about simplicity and clarity of language's syntax? Why memory management? Both the syntax and the semantics are nicer. > btw, to whom memory management is a PITA? To anyone who tries to do it. That automatic memory management is easier to program with than manual memory management is self-evident.
jollojou 16y ago
This means that Oracle chose Mark Reinhold's plan B (http://blogs.sun.com/mr/entry/rethinking_jdk7 http://blogs.sun.com/mr/entry/rethinking_jdk7). From the point of view of a web application developer, JDK 7 is not very interesting. JDK 7 will contain a few language updates like switch-cases based on strings. No major changes or features that would radically change a web app developer's coding routines. What do you think?
- mey 16y ago
  As a web application developer, on Java, I think there is a lot to look forward too. Mostly in JSR 292. I see a point where I'm running the best of ruby/python/groovy as core parts of a Java deployment environment. Edit: Not that you can't now, but now this will bring very good reasons to run a hybrid environment combining the best of both systems.
  - bad_user 16y ago
    Unfortunately JSR 292 will not deliver as you'd thing. Some people don't have such a good impression of it, e.g. Rich Hickey (Clojure): http://clojure-log.n01se.net/date/2010-06-01.html http://clojure-log.n01se.net/date/2010-06-01.html method handles are just going to be an entirely new thing hotspot et al are going to have to be taught to optimize. They are already awesome at optimizing ordinary class method dispatch bobo_: invokedynamic is not needed for removing reflection .... it is just a different way of doing call site caches, which you can already do today with classes and methods What JSR 292 does is to simplify the work a compiler architect needs to do, since implementing call-site caches is hard work, not to mention memory management since interpreters like JRuby are generating lots of classes that are entering PermGen ... so stuff like java.dyn.AnonymousClassLoader may provide some relief. But on the other hand, compilers will still need to support Java pre-7, since adoption in the enterprise is really slow (many companies are still on version 1.4) There is a backport for invokedynamic though, but it remains to be seen if it's any good: http://code.google.com/p/jvm-language-runtime/ http://code.google.com/p/jvm-language-runtime/ Notably missing features with a lot more bang than InvokeDynamic: tail-call optimization fixnums coroutines All in all, Java 7 is a monumental failure and Oracle is waisting resources on merging JRockit with Sun's JVM, instead of saving it. Say what you want about .NET, but their releases have been coherent with each one adding value. If only Microsoft's management would see this as an opportunity and open up .NET a bit, probably not.
jshharlow 16y ago
No closures :-(
- ShardPhoenix 16y ago
  They're still coming, but have been put off until JDK 8, which is scheduled for late 2012 (about 6 months later than the original JDK 7 scheduled date). By the fast-moving standards of the software world this does make them a long way off, though...
  - pilif 16y ago
    Especially when you are writing Java code to run on client machines. There it's not even safe to rely on 1.4 features yet. So I guess I'll be able to use closures the moment I can stop trying to make my web pages work in IE 6: in the yeat 2040
    - dataguy 16y ago
      That's maybe the one most important problem arising with Java if you are using it in an environment you do not know or not know well (as it is, on client machines - especially using Java on the web). As of it, using Java 7 features in Web pages - no way, maybe no way ever if you do not want to exclude a big mass of people out there on the market.
      - joegaudet 16y ago
        People still write client side Java? shudder I love Java, but good god would I never write an Applet again.
        kaffiene 16y ago
        You do realise that 'client side' includes people's own machines, right? You don't need to do applets for those. Besides, applets are way way better now than they used to be.
  - 16y ago
bsdemon 16y ago
Keep using Scala ;-)
- nickik 16y ago
  Your write Java the Langauge should just die! The should work on the VM/GC and JIT. Programmers should work with Clojure or Scala.
fauigerzigerk 16y ago
I wonder what's going on in that Java group at Oracle. How can it possibly take three more years or so to implement something like list and map literals or a data picker UI component? The one and only change to the VM that I would like to see is not even planned: structured value types. This single issue is responsible for Java's massive memory usage. Half of that memory is used for completely unnecessary pointers and it will lead to C or C++ grabbing the title of 100 year language.
- points 16y ago
  Memory usage is fairly moot, and will just become more and more moot. When you're watching a 3d projected HD video with 5.1 audio on your smartphone, what's using the memory... A few pointers? Or the actual media? And in any event, we'll likely have a few TB of memory even on phones to play with in a few years.
  - viraptor 16y ago
    You chose an interesting example. The movie can be played and processed quickly exactly because it has an explicit and probably hardware mapped in some places memory layout. It's processed with as few indirect operations as possible. And this was exactly the complaint in the parent post - this is not possible to do with Java. If you have a list of Integers, you have a list of Integers. (please correct me if I'm mistaken here: ) so every integer needs an explicit pointer in the list itself + the overhead of boxing. It's not the pointer to the list that matters - it's the fact, that your list takes ~4 times as much memory (pointer, lock, tag, value) - or maybe more - I don't remember the object implementation details for JVM. For scenarios where you operate on big tables of data, it matters, because it kills cache performance and uses up many times the amount of memory that you'd normally use.
    - points 16y ago
      int[] is fairly tight. If you're going for performance or optimum memory usage, using lists and boxing isn't going to be a good plan. I once wrote an x86 emulator in java and later an ARM emulator (long story). It ran fast enough :)
BonoboBoner 16y ago
The main motivation for adding closures was not having to include a big pile of boilerplate interfaces coming from the jsr 166 fork/join framework. Now fork/join is in JDK7, but closures wont make it till JDK8, which means we'll be stuck with the crappier API forever. In my opinion, JDK7 wont have enough incentive for corporations to upgrade Remember how long it took for JDK6 to be adopted? So why release a JDK version if the majority of people wont use it? Why not spend a year or more on building new cohesively designed APIs with closures in mind?
- puredanger 16y ago
  Actually, that's not accurate. The motivation for adding closures was to avoid adding those additional interfaces for the ParallelArray abstraction that goes over fork/join. Fork/join has always been planned to go in for JDK 7. AFAIK, ParallelArray will not go into the new JDK 7 plan so the API stuff you mention is not an issue.
  - BonoboBoner 16y ago
    Oh, thanks for clarifying that, I thought ParallelArray was part of it.
ollysb 16y ago
As a java developer who's moved over to ruby the JDK 7 feature list was starting to make me think it wouldn't be such a painful language to work with. Just 3 features would have made me think about working with java again. Type inference, closures and collection literals. Anything else they're working on for the java language is wasted time. They've never been great at writing APIs, they should stick to improving the language and letting the open source community drive the APIs forward.
stephen 16y ago
I like Scala, but I'm still surprised a simpler "better Java" alternative hasn't taken off like: http://code.google.com/p/stab-language/ http://code.google.com/p/stab-language/ (C# syntax compiled directly to the JVM) http://boo.codehaus.org/ http://boo.codehaus.org/ (Python syntax, normally for .NET, but there is a pure JVM fork in there somewhere) The barrier to adoption these days is a robust Eclipse IDE--if either of these projects had one, I think they'd see a lot of adoption.
- therockhead 16y ago
  I think Fan might be the simpler better Java - but like you say I dont think it taken off. http://fantom.org/ http://fantom.org/
joegaudet 16y ago
It might be just sybtactical sugar, but I would really like to see some sort of annotation for auto generating setters and getters at compile. Eclipse makes it pretty easy to make these, but it sure would clean up class clutter.
- kaffiene 16y ago
  Why bother? All Java IDEs do that with a keystroke.

61 points by puredanger 16y ago

mey 16y ago

There are a lot of great steps forward for the Java language in 7. My only question is when is Oracle going to release it so it can start being adopted?

10ren 16y ago

TLS 1.2 = Transport Layer Security: http://tools.ietf.org/html/rfc5246 http://tools.ietf.org/html/rfc5246

c00p3r 16y ago

Java is everywhere. Berkeley CS162 course uses Java language to teach OS Design and Internals - they wrote a pseudo-code examples in Java, a-la SaveRegisters(). It is a madness, Isn't it? ^_^

points 16y ago
Why madness? It has a clear, logical, consistent and easy to understand syntax.
- c00p3r 16y ago
  Really? Easier than C syntax, which is a more appropriate in this context, and on which Java's syntax is based upon?
  - sid0 16y ago
    > Really? Easier than C syntax Significantly easier. Think about all those pointers that simply aren't there now. > which is a more appropriate in this context This is a value judgement. The generally nicer semantics (automatic memory management! proper strings!) are also worth a lot.
  - points 16y ago
    Way easier than C syntax. Even though I have long mastered various assembly languages and higher level languages, C pointers and their arithmetic still confuses me. There's nothing worse than something like bar = *[&foo + 88] or whatever it is.
sid0 16y ago
I'm a TA for an OS course that is closely following the Berkeley CS162 course, down to using Java for assignments. We've had much less trouble than with the C++ we used to use.
- c00p3r 16y ago
  Why not a plain C which is an obvious choice? I think I know the answer - "because of a buzz". ^_^ And of course, using a VM-hosted language to describe things which are on two levels of abstraction lower is a little bit funny.
  - sid0 16y ago
    > Why not a plain C which is an obvious choice? Because manual memory management is a PITA. > And of course, using a VM-hosted language to describe things which are on two levels of abstraction lower is a little bit funny. Why? As long as you're clear that it's a pedagogical tool, it's perfectly fine. And there are incubation OSes (e.g. Singularity) that are almost entirely managed.
    - c00p3r 16y ago
      We're talking about simplicity and clarity of language's syntax? Why memory management? btw, to whom memory management is a PITA?
      - sid0 16y ago
        > We're talking about simplicity and clarity of language's syntax? Why memory management? Both the syntax and the semantics are nicer. > btw, to whom memory management is a PITA? To anyone who tries to do it. That automatic memory management is easier to program with than manual memory management is self-evident.

jollojou 16y ago

This means that Oracle chose Mark Reinhold's plan B (http://blogs.sun.com/mr/entry/rethinking_jdk7 http://blogs.sun.com/mr/entry/rethinking_jdk7). From the point of view of a web application developer, JDK 7 is not very interesting. JDK 7 will contain a few language updates like switch-cases based on strings. No major changes or features that would radically change a web app developer's coding routines. What do you think?

mey 16y ago
As a web application developer, on Java, I think there is a lot to look forward too. Mostly in JSR 292. I see a point where I'm running the best of ruby/python/groovy as core parts of a Java deployment environment. Edit: Not that you can't now, but now this will bring very good reasons to run a hybrid environment combining the best of both systems.
- bad_user 16y ago
  Unfortunately JSR 292 will not deliver as you'd thing. Some people don't have such a good impression of it, e.g. Rich Hickey (Clojure): http://clojure-log.n01se.net/date/2010-06-01.html http://clojure-log.n01se.net/date/2010-06-01.html method handles are just going to be an entirely new thing hotspot et al are going to have to be taught to optimize. They are already awesome at optimizing ordinary class method dispatch bobo_: invokedynamic is not needed for removing reflection .... it is just a different way of doing call site caches, which you can already do today with classes and methods What JSR 292 does is to simplify the work a compiler architect needs to do, since implementing call-site caches is hard work, not to mention memory management since interpreters like JRuby are generating lots of classes that are entering PermGen ... so stuff like java.dyn.AnonymousClassLoader may provide some relief. But on the other hand, compilers will still need to support Java pre-7, since adoption in the enterprise is really slow (many companies are still on version 1.4) There is a backport for invokedynamic though, but it remains to be seen if it's any good: http://code.google.com/p/jvm-language-runtime/ http://code.google.com/p/jvm-language-runtime/ Notably missing features with a lot more bang than InvokeDynamic: tail-call optimization fixnums coroutines All in all, Java 7 is a monumental failure and Oracle is waisting resources on merging JRockit with Sun's JVM, instead of saving it. Say what you want about .NET, but their releases have been coherent with each one adding value. If only Microsoft's management would see this as an opportunity and open up .NET a bit, probably not.

jshharlow 16y ago

No closures :-(

ShardPhoenix 16y ago
They're still coming, but have been put off until JDK 8, which is scheduled for late 2012 (about 6 months later than the original JDK 7 scheduled date). By the fast-moving standards of the software world this does make them a long way off, though...
- pilif 16y ago
  Especially when you are writing Java code to run on client machines. There it's not even safe to rely on 1.4 features yet. So I guess I'll be able to use closures the moment I can stop trying to make my web pages work in IE 6: in the yeat 2040
  - dataguy 16y ago
    That's maybe the one most important problem arising with Java if you are using it in an environment you do not know or not know well (as it is, on client machines - especially using Java on the web). As of it, using Java 7 features in Web pages - no way, maybe no way ever if you do not want to exclude a big mass of people out there on the market.
    - joegaudet 16y ago
      People still write client side Java? shudder I love Java, but good god would I never write an Applet again.
      - kaffiene 16y ago
        You do realise that 'client side' includes people's own machines, right? You don't need to do applets for those. Besides, applets are way way better now than they used to be.
- 16y ago

bsdemon 16y ago

Keep using Scala ;-)

nickik 16y ago
Your write Java the Langauge should just die! The should work on the VM/GC and JIT. Programmers should work with Clojure or Scala.

fauigerzigerk 16y ago

I wonder what's going on in that Java group at Oracle. How can it possibly take three more years or so to implement something like list and map literals or a data picker UI component? The one and only change to the VM that I would like to see is not even planned: structured value types. This single issue is responsible for Java's massive memory usage. Half of that memory is used for completely unnecessary pointers and it will lead to C or C++ grabbing the title of 100 year language.

points 16y ago
Memory usage is fairly moot, and will just become more and more moot. When you're watching a 3d projected HD video with 5.1 audio on your smartphone, what's using the memory... A few pointers? Or the actual media? And in any event, we'll likely have a few TB of memory even on phones to play with in a few years.
- viraptor 16y ago
  You chose an interesting example. The movie can be played and processed quickly exactly because it has an explicit and probably hardware mapped in some places memory layout. It's processed with as few indirect operations as possible. And this was exactly the complaint in the parent post - this is not possible to do with Java. If you have a list of Integers, you have a list of Integers. (please correct me if I'm mistaken here: ) so every integer needs an explicit pointer in the list itself + the overhead of boxing. It's not the pointer to the list that matters - it's the fact, that your list takes ~4 times as much memory (pointer, lock, tag, value) - or maybe more - I don't remember the object implementation details for JVM. For scenarios where you operate on big tables of data, it matters, because it kills cache performance and uses up many times the amount of memory that you'd normally use.
  - points 16y ago
    int[] is fairly tight. If you're going for performance or optimum memory usage, using lists and boxing isn't going to be a good plan. I once wrote an x86 emulator in java and later an ARM emulator (long story). It ran fast enough :)

BonoboBoner 16y ago

The main motivation for adding closures was not having to include a big pile of boilerplate interfaces coming from the jsr 166 fork/join framework. Now fork/join is in JDK7, but closures wont make it till JDK8, which means we'll be stuck with the crappier API forever. In my opinion, JDK7 wont have enough incentive for corporations to upgrade Remember how long it took for JDK6 to be adopted? So why release a JDK version if the majority of people wont use it? Why not spend a year or more on building new cohesively designed APIs with closures in mind?

puredanger 16y ago
Actually, that's not accurate. The motivation for adding closures was to avoid adding those additional interfaces for the ParallelArray abstraction that goes over fork/join. Fork/join has always been planned to go in for JDK 7. AFAIK, ParallelArray will not go into the new JDK 7 plan so the API stuff you mention is not an issue.
- BonoboBoner 16y ago
  Oh, thanks for clarifying that, I thought ParallelArray was part of it.

ollysb 16y ago

As a java developer who's moved over to ruby the JDK 7 feature list was starting to make me think it wouldn't be such a painful language to work with. Just 3 features would have made me think about working with java again. Type inference, closures and collection literals. Anything else they're working on for the java language is wasted time. They've never been great at writing APIs, they should stick to improving the language and letting the open source community drive the APIs forward.

stephen 16y ago

I like Scala, but I'm still surprised a simpler "better Java" alternative hasn't taken off like: http://code.google.com/p/stab-language/ http://code.google.com/p/stab-language/ (C# syntax compiled directly to the JVM) http://boo.codehaus.org/ http://boo.codehaus.org/ (Python syntax, normally for .NET, but there is a pure JVM fork in there somewhere) The barrier to adoption these days is a robust Eclipse IDE--if either of these projects had one, I think they'd see a lot of adoption.

therockhead 16y ago
I think Fan might be the simpler better Java - but like you say I dont think it taken off. http://fantom.org/ http://fantom.org/

joegaudet 16y ago

It might be just sybtactical sugar, but I would really like to see some sort of annotation for auto generating setters and getters at compile. Eclipse makes it pretty easy to make these, but it sure would clean up class clutter.

kaffiene 16y ago
Why bother? All Java IDEs do that with a keystroke.