JDK 7 Features

http://openjdk.java.net/projects/jdk7/features/

by puredanger • 16 years ago

61 71 16 years ago

openjdk.java.net

10ren• 16 years ago

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

c00p3r4• 16 years 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? ^_^

points7• 16 years ago

Why madness? It has a clear, logical, consistent and easy to understand syntax.

c00p3r4• 16 years ago

Really? Easier than C syntax, which is a more appropriate in this context, and on which Java's syntax is based upon?

sid04• 16 years 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.

c00p3r4• 16 years 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.

jollojou• 16 years ago

This means that Oracle chose Mark Reinhold's plan B (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?

mey3• 16 years 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_user2• 16 years 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

     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/

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.

al3x• 16 years ago

Features like invokeDynamic don't impact Java developers much day-to-day, but they should make JVM languages like JRuby and Scala faster.

philf• 16 years ago

I'm not too familiar with Scala, but I guess you mean when you use structural types?

jshharlow• 16 years ago

No closures :-(

ShardPhoenix• 16 years 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• 16 years 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

zmmmmm• 16 years ago

Read carefully:

"Deferred to JDK 8 or later"

In the Java world, this is a good way of saying never ...

adamilardi• 16 years ago

Java has closures.... anonymous inner types

mey3• 16 years 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?

bsdemon• 16 years ago

Keep using Scala ;-)

nickik• 16 years 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.

fauigerzigerk11• 16 years 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.

points7• 16 years 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.

viraptor3• 16 years 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.

fauigerzigerk11• 16 years ago

Memory usage will never be moot as long as you have a very large cost difference between fast storage and slow mass storage. Absolute sizes don't tell you anything without comparing them to the amount of data that you want to process and index.

You have chosen an example where streaming is possible. But sequential access is not what you want in databases, search engines, many forms of data analysis.

BonoboBoner2• 16 years 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• 16 years 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.

BonoboBoner2• 16 years ago

Oh, thanks for clarifying that, I thought ParallelArray was part of it.

ollysb• 16 years 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.

joegaudet2• 16 years 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.

kaffiene2• 16 years ago

Why bother? All Java IDEs do that with a keystroke.

stephen• 16 years 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/ (C# syntax compiled directly to the JVM)

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• 16 years ago

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

JDK 7 Features

Related Stories