
JDK 7 Features - puredanger
http://openjdk.java.net/projects/jdk7/features/
======
fauigerzigerk
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
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
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.

~~~
fauigerzigerk
That's exactly what I meant. In the case of int you can work around it using
int[] but if you need more structure, like with a complex number type, or
tuples, pairs, etc, the workarounds get really tedious. Basically what you can
do is stuff it all into a large byte[] and deserialise on access. That's slow
and kills productivity.

~~~
points
It's hardly a 'work around' :/

    
    
      int[][]
    

or

    
    
      reals int[]
      imaginaries int[]

~~~
wtallis
Java's multidimensional arrays aren't stored contiguously in memory because
rows can be different lengths. If you have an int[][] a, then a[1] is simply a
pointer to an int[]. You can't escape the excess of pointers.

If you try something like having an array for each component as a substitute
for an array of structs, then that places fairly strict upper bounds on the
length of the arrays before which you are guaranteed to have killed cache
locality.

------
jollojou
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?

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

~~~
mey
Everyone could implement their own solution to call-site caching (and they
do), but to push it down into the JVM for a single clear defined way of doing
it, grants much more to optimization efforts. What benefits one system, should
benefit them all.

There will be a schism between libraries that move to Java 7 only, and support
their own call-cache mechanism, but I doubt any of the established projects
would ditch their existing solutions, it would most likely only effect new
libraries.

If an enterprise is busy being tied up in Java 1.4, and missing out on the
drastic speed and memory improvements in hotspot 1.6 line, then I doubt that
adding dynamic languages is a priority. JRuby for example requires 1.6 (from
the literature I've seen and personal experience, but they don't explicitly
say so on their site)

I also disagree generally about how Oracle is dealing with Java 7, but I am
willing to see what the end result is.

Microsoft has been heavily involved in the IronPython/IronRuby and Mono
efforts. They do see the power in .Net cross system.

~~~
bad_user
> _Microsoft has been heavily involved in the IronPython/IronRuby and Mono
> efforts. They do see the power in .Net cross system._

Mono is kind of behind ... I have high hopes for version 2.8/3.0 with the new
garbage-collector, but the prelease crashed with a segfault which kind of
turned me off for now, I'll retry it when the final version is released.

What bothers me about it is that currently memory-management sucks, some bugs
remain unfixed (tail calls don't work properly, hence F# is unusable, and
AFAIK fixing that bug requires some major changes), and there are not many
Linux-specific APIs for server-side stuff ... like the async I/O apis are
there only for compatibility, but don't work properly.

I also kind of expected Mono to be more than a .NET clone, and yet there is no
alternative to the ASP.NET, which is heavy and is made with .NET's constraints
in mind. On Mono it leaks memory for instance.

They could do more for Mono than they already did ... like have 1 or 2
experienced engineers help them with the garbage-collector / or grant them the
IP to learn from / use the garbage collector from .NET.

Also, the C# ECMA standard is 2 versions behind, what's up with that?

------
BonoboBoner
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
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
Oh, thanks for clarifying that, I thought ParallelArray was part of it.

------
stephen
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
I think Fan might be the simpler better Java - but like you say I dont think
it taken off. <http://fantom.org/>

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

------
jshharlow
No closures :-(

~~~
ShardPhoenix
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
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
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
People still write client side Java? _shudder_ I love Java, but good god would
I never write an Applet again.

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

------
bsdemon
Keep using Scala ;-)

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

------
joegaudet
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
Why bother? All Java IDEs do that with a keystroke.

------
mey
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
TLS 1.2 = Transport Layer Security: <http://tools.ietf.org/html/rfc5246>

------
c00p3r
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
Why madness? It has a clear, logical, consistent and easy to understand
syntax.

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

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

