What's not going to make it in JDK7

Miscellaneous Topics
#1

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

Deferred to JDK 8 or later

JSR 294: Language and VM support for modular programming
Enhancements to the Java language and virtual-machine specifications to support modular programming, at both compile time and run time

JSR 308: Annotations on Java types
An extension to the Java annotation syntax to permit annotations on any occurrence of a type

JSR TBD: Language support for collections [NEW]
Literal expressions for immutable lists, sets, and maps, and indexing-access syntax for lists and maps

JSR TBD: Project Lambda :frowning:
Lambda expressions (informally, “closures”) and defender methods for the Java programming language

Modularization (Project Jigsaw)
A simple, low-level module system focused upon the goal of modularizing the JDK, and the application of that system to the JDK itself

JSR 296: Swing application framework
An API to define the basic structure of a typical Swing application, thereby eliminating lots of boilerplate code and providing a much-improved initial developer experience

Swing JDatePicker component
Add the SwingLabs JXDatePicker component to the platform

#2

Well I would rather them releasing something then taking another 2 years. But its a shame things got so delayed. Hopefully will not happen with Java 8.

#3

I mean, everyone following lambda-dev saw this coming, the thing is just so far away from being ready, but I can’t even express how disappointed I am. Here’s hoping that this doesn’t get cut from 8 as well…
* ewjordan pops open another tab to go download the latest versions of the Scala plugins for all my IDEs yet again to see if they’re finally ready for some real use…

#4

* OverKill points to topic about Oracle & Java
told ya so!

And I honestly doubt they will come in 8 as well.

@Lambda:
Yay! Can this be berried along JavaFX Script? :wink:

#5

So what’s the point of JDK7 without all this stuff. This is more like an open source JDK6 Update X then… :frowning:

#6

oh, I welcome the JDK7 without so much major api breakage, changes and new features. There are now so many super cool optimisations in JDK7 that the speed boost alone will be worth the update.

#7

The InvokeDynamic stuff alone is enough to justify a new JDK version, imho.

#8

[quote]Strings in switch statements
[/quote]
Nice. Simple but very useful.

On the other hand, “Automatic resource management” sounds like an attempt to copy C#'s ‘using’ blocks but without the elegance. :frowning:

#9

[qoute]Strings in switch statements
[/quote]
I’ve waiting so freaking long for this to happen :slight_smile: Finally!

#10

Can someone point me at a good use case for Lamda expressions, I still don’t really understand how they could be useful. I use anonymous inner classes very rarely and don’t find them that horrible to use so it may just be my programming style. It seems this feature doesn’t fit very nicely with the rest of Java’s programming paradigms but I may just not understand them well enough.

Personally as someone who has to maintain other peoples code I would prefer features that have very limited valid use cases (eg operator overloading) and massive potential for abuse left out of the language or only allowed to be defined for core VM classes (eg String).

#11

Lamba expressions were solely added for the fork/join framework, which has a zillion interfaces for just about every primitive combination, for every usecase.

Writing multithreaded code (lots of futures, callbacks, runnables) is a pain in Java.

#12

[quote=“ShannonSmith,post:10,topic:35690”]
That’s why you’re not seeing the point; in my work, I end up with anonymous inner classes all over the place, and it’s really an eyesore, it makes reading the code vastly more difficult.

Riven is dead on - multi-threaded code is the primary use case (and it’s definitely why the addition is being considered, though it’s by no means the only reasonable use, see pretty much any Lisp, Ruby, Haskell, or Scala program for examples of why it’s effective). A lot of this is focused at making multi-threaded collection manipulations easier; say I want to massively parallelize work that I’m doing over a billion element data set, and I want to abstract away that parallelization. Further, say that there are dozens of different operations that I want to do to this data. It’s much easier to do this type of thing if I can write myCollection.map( x => x+1 ) instead of turning the simple operation x => x+1 into its own anonymous class, which will take up several lines of space (or at least add a lot of line noise).

And yes, a lot of this is really just a matter of allowing shorter syntax, and given that you don’t program using these ideas much it might seem like a meaningless detail; however, it’s proven to be extremely effective (I’d say even crucial) in every other language that has it, and enables much more powerful programs to be specified in much less space, especially since generating higher order functions becomes rather pleasant. The tricky thing is that Java has some peculiarities that make it much more difficult to get right (different scopes for methods vs. fields, checked exceptions, etc.).

#13

I think the most dangerous idea behind Lambda expressions is in Java was sharing local variables in the ‘outer scope’. Maybe it’s me, but first the compiler has to convert all your local variables into AtomicIntegers, AtomicReferences (‘atomic autoboxing’), etc, under the hood, and then you find yourself in the situation where local variables can be modified by any thread, at any time.

The following code would be ‘unsafe’:


int score = 55;
pool.executeThisSometimeInTheFutureForAFewTimesMaybe( ... => ... );
while(true)
   System.out.println(score);

I’m sure this was part of the lambda proposal: write access to non-final (doh…) local variables.

Could anybody point out what I misunderstood?

#14

Whenever I look up closures I get a queasy feeling that treating blocks of code like objects is not a good idea and is going to lead to some very esoteric bugs. Also I’m not quite sure how you would go about debugging them, what happens to a break point in a closure? It’s probably because I never properly learned a language that supports closures so I can’t fully appreciate how wonderful they are.

#15

It’s just syntactic sugar. There will not be closures in Java, Lambda expressions were called closures but they are not! The compiler just turns them into your average anonymous inner classes. You can already do it today, and yes, it makes debugging hard as you don’t have the stacktraces that describe all the traces in the caller threads. Nobody said concurrent programming was easy, but Lambda expressions were just about the syntax, and will do nothing about the inherent problems of debugging a piece of code that jumps through a bunch of threads. Unfortunately.

I was really looking forward to Lambda expressions… I hate overdesigning my code, but things get messy really fast. When you’re doing a lot of (interactive) networking in a GUI you have callbacks, countdownlatches, futures, barriers and those pesky runnables. Everyt time you need to sync with the GUI you need invokeLater(Runnable) or invokeAndWait(Runnable). Another anonymous inner class… When about 50% of the sourcecode is innerclass declaration overhead it gets annoying. You start refactoring it, but that only adds to the overhead. In JavaScript (yes I said it) this stuff is just trivial. I’d love first class functions in Java, but we’ll never get them.

#16

Speaking as someone who writes most of his multi-threaded code in C++, multithreading in Java is a breeze. Given the already rich set of multithreading tools available in Java, I’m not entirely convinced that the new (and probably very subtle) bugs you can introduce with the fancy lambda stuff are worth the gain. Atomic auto boxing in particular sounds horrendous (and a performance sink too).

#17

You know, I actually forget whether or not that’s planned to be allowed…people that want legit closures obviously want that (it’s pretty much what “closure” means), but if I recall there was a lot of back and forth as to whether it would be done or not, and it may have been left out. I remember some discussion about “auto-finalizing” variables whenever possible so that they could be referred to within a lambda, which implies that they came down against it, but I can’t find a good reference right now…

Personally, I don’t feel like it’s that horrible, since if you’re messing around with locals inside a closure, you’re asking for what you get - typically you would never do this unless you actually wanted to pull some state within the thing, and sometimes that’s useful to do.

I mean, is there really any difference between passing a closure that closes over a local variable to a multi-threaded operation and passing a single object reference to a bunch of different threads? Closures are often used for exactly the same kind of encapsulation that we usually do with classes in OO-land, so…

YMMV, of course.

In my experience, it’s far less bug prone than you might think, because there really aren’t that many gotchas - the one Riven noted can bite you once in a while, but if you’re futzing with multithreaded code you’re screwed anyways. The only other trouble area is control flow funny business, like continue, break, return, and exception handling; getting all that right comes down to writing a good spec, and is one of the main reasons that this has been delayed. They’re taking that very seriously, so I’d expect the end result to be pretty clear and easy to digest.

FWIW, I just checked some of my code, and in the project I’m hacking on at the moment (a wrapper around some numerical optimization code that uses reflection to let you just point at an object and say “Optimize the fields in this object relative to this utility function”, and presto!, the optimal values appear, like magic - I’m planning to lean on optimization and genetic algorithms very hard for some upcoming work, so it’s crucial to have a very simple syntax for both of them, and you can’t get much simpler than optimize(myObject, “fitnessFunctionName”), at least without first class functions. I’d estimate that this would have taken about a quarter of the time if closures were available…), almost every method has at least one anonymous inner class, and some of them go several levels deep. It’s when you start to need functions that return functions that return functions that the syntax restrictions of Java get truly obnoxious.

Perhaps that’s peculiar to my style of coding, or to my areas of interest, but I can tell you this, at least: any bugs that I’m running into are not coming from areas where I would be heavily using closures and am currently using anonymous inner classes, they’re coming from places where the logic is actually difficult. My experiences in Scala have been similar, closures are almost always a way to make your code easier to manage, even if some of the other features can get really confusing (implicit type conversions can be a real bitch, sometimes).

#18

[quote=“ewjordan,post:17,topic:35690”]
I wonder how that could possibly be done… those lambda expressions can be executed at any time, by any (set of) thread for any number of times. How would your possibly handle the ‘break’ / ‘continue’ keyword if they are from another thread, and the loop may already have been left. Same for ‘return’, but the method has already been left, or the method is manipulating some local variables, and be ‘interrupted’ by the other thread calling ‘return’ on it. Last but not least catching exceptions thrown by other threads, maybe hours after you left that method.

The compiler cannot determine what will be done with the anonymous inner class instance at runtime.

I think that for this ‘break/continue/return/catch’ support, lambda expressions would be so restricted (must stay within the same thread) that they would be barely useful.

Again, I’m sure I missed something…

#19

Hm I never really seem to have a problem with inner classes much. Or threads. And I do seriously complex multithreaded code.
Something like continuations would be nice though.

Cas :slight_smile:

#20

Actually, I’m pretty sure you’re right, non-local control transfer has been taken off the table; you’re definitely correct that it’s tough to imagine any spec that would make them work intuitively.

FWIW, the main reason I keep getting confused about what’s in and out is that Gafter has been very vocal in this whole process, and his preferred version of closures (http://www.javac.info/closures-v05.html) is quite a bit more complex than the one they’re ultimately going to go with, though they did draw a lot from it. In his version, there was a construct that allowed for certain transfers of control, but it wasn’t completely general.

Neither do I, really - don’t get me wrong, I use them all the time, and they’re not terrible to code, even if they’re a little hard on the eyes.

But when a language is optimized so that these constructs are short and sweet, we can really lean on them, and that’s what I’d look forward to. Theoretically we could write (at least some subset of) the kind of code that you’d see in functional languages by using a lot of inline anonymous Callables all over the place, but you almost never see stuff like that because it turns out that stateful towers of for-loops with the logic in the middle take fewer characters to write than the equivalent fold/map/reduce/etc would. We end up going for the path of least resistance, rightly.

Shift that balance, and I think we’ll start to see a lot of really pleasant library APIs coming out for Java, which would be nice - a lot of other languages are doing much better at solving the “elegance” problem, Java could use a breath of life in that regard.