Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  What's not going to make it in JDK7  (Read 6000 times)
0 Members and 1 Guest are viewing this topic.
Online Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Posted 2010-09-21 02:13:04 »

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 Sad
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

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline zammbi

JGO Coder


Medals: 4



« Reply #1 - Posted 2010-09-21 02:37:10 »

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.

Current project - Rename and Sort
Offline ewjordan

Junior Member





« Reply #2 - Posted 2010-09-21 08:32:02 »

JSR TBD: Project Lambda Sad
Lambda expressions (informally, "closures") and defender methods for the Java programming language

<sigh>

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...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline OverKill

Junior Member




Java games rock!


« Reply #3 - Posted 2010-09-21 09:27:13 »

* 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
Offline cylab

JGO Ninja


Medals: 38



« Reply #4 - Posted 2010-09-21 09:29:41 »

So what's the point of JDK7 without all this stuff. This is more like an open source JDK6 Update X then... Sad

Mathias - I Know What [you] Did Last Summer!
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 74
Projects: 15


★★★★★


« Reply #5 - Posted 2010-09-21 10:39:56 »

So what's the point of JDK7 without all this stuff. This is more like an open source JDK6 Update X then... Sad

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.
Offline Spasi
« Reply #6 - Posted 2010-09-21 10:49:36 »

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

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #7 - Posted 2010-09-21 10:57:39 »

Quote
Strings in switch statements

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

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #8 - Posted 2010-09-21 16:07:59 »

[qoute]Strings in switch statements[/quote]

I've waiting so freaking long for this to happen  Smiley Finally!

Offline ShannonSmith
« Reply #9 - Posted 2010-09-21 18:39:14 »

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).
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #10 - Posted 2010-09-21 19:12:17 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline ewjordan

Junior Member





« Reply #11 - Posted 2010-09-21 22:32:08 »

I use anonymous inner classes very rarely and don't find them that horrible to use so it may just be my programming style.

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.).
Online Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #12 - Posted 2010-09-21 22:55:36 »

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':
1  
2  
3  
4  
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?

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline ShannonSmith
« Reply #13 - Posted 2010-09-21 23:08:26 »

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.
Online Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #14 - Posted 2010-09-21 23:14:11 »

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.

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #15 - Posted 2010-09-22 02:15:29 »

Writing multithreaded code is a pain in Java.

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

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline ewjordan

Junior Member





« Reply #16 - Posted 2010-09-22 07:01:23 »

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

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.

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.

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).
Online Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #17 - Posted 2010-09-22 13:55:40 »

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.

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

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2010-09-22 14:11:47 »

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 Smiley

Offline ewjordan

Junior Member





« Reply #19 - Posted 2010-09-22 18:19:58 »

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.

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.

Hm I never really seem to have a problem with inner classes much. Or threads. And I do seriously complex multithreaded code.

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.
Online Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #20 - Posted 2010-09-22 18:31:55 »

Basically lambda expressions are to inner classes what enhanced-for-loops are to looping over an iterator.

You can do without, but you'd rather not. And a few people just don't care.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline i30817

Junior Member





« Reply #21 - Posted 2010-10-10 18:23:54 »

What about tiered "compilation"?
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 74
Projects: 15


★★★★★


« Reply #22 - Posted 2010-10-10 18:25:30 »

What about tiered "compilation"?

yup it will be in there, but as yet its unclear if it'll be enabled by default.
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #23 - Posted 2010-10-12 15:13:34 »

Wow, that sure is a horribly gutted java 7..

Play Minecraft!
Offline JL235

JGO Coder


Medals: 10



« Reply #24 - Posted 2010-10-27 20:42:09 »

Closures aren't just useful for multi-threaded code. I've met tonnes of examples where it makes the code a lot neater to be able to wrap up a bit of code and pass it into a function.

In regards to Java itself, considering this has been 4 years in the making I can't help thinking the final list is a little thin. I hope they stay on track and get Java 8 out the door in 2 years as they claim.

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2010-10-28 23:36:29 »

You know, I couldn't care whether it got a single new feature in it if they just released it with the performance enhancements it's already got in it Smiley Edging closer and closer to C++ performance.

Cas Smiley

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (37 views)
2014-07-24 01:59:36

Riven (38 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (50 views)
2014-07-17 23:47:54

danieldean (42 views)
2014-07-17 23:41:23

MustardPeter (44 views)
2014-07-16 23:30:00

Cero (60 views)
2014-07-16 00:42:17

Riven (57 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!