Whither JDK 7?
in [Java Programming]
|
From: John B. Matthews on 26 May 2010 10:50 In article <hti99p$bv7$3(a)news.eternal-september.org>, ClassCastException <zjkg3d9gj56(a)gmail.invalid> wrote: > On Tue, 25 May 2010 19:36:47 -0400, Arne Vajhøj wrote: > > > On 25-05-2010 18:57, ClassCastException wrote: > >> Is JDK 7 really on the way, or is it just another Duke Nukem > >> Forever or Half-Life 3 -- that is to say, vaporware? > >> > >> Because I swear it's been like *years* since I first heard mention > >> of it and JDK 6 still seems to be current. > > > > It has been a long time underway. > > > > But people are working on it. > > > > And eventually it will come out. > > > > Lot of people are unhappy with the speed, but ... > > > > Anyway - Java is so mature so there are very few must haves missing > > and for each nice to have there are 7 different opinions on how to > > implement. > > Oh, lovely, so it will be another six months to six years in coming > and, when (if) it finally does show up, it will have "designed by > committee" written all over it? > > Maybe it's best to just stick with JDK 6 then. :) There is some evidence that the Java tutorial is being updated, _pari_passu_: <http://groups.google.com/group/comp.lang.java.advocacy/browse_frm/thread/7820aeedbd3ed37d> And the milestones cited there have been updated since: <http://openjdk.java.net/projects/jdk7/milestones/> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Arne Vajhøj on 26 May 2010 19:32 On 26-05-2010 00:50, ClassCastException wrote: > On Tue, 25 May 2010 19:36:47 -0400, Arne Vajhøj wrote: >> On 25-05-2010 18:57, ClassCastException wrote: >>> Is JDK 7 really on the way, or is it just another Duke Nukem Forever or >>> Half-Life 3 -- that is to say, vaporware? >>> >>> Because I swear it's been like *years* since I first heard mention of >>> it and JDK 6 still seems to be current. >> >> It has been a long time underway. >> >> But people are working on it. >> >> And eventually it will come out. >> >> Lot of people are unhappy with the speed, but ... >> >> Anyway - Java is so mature so there are very few must haves missing and >> for each nice to have there are 7 different opinions on how to >> implement. > > Oh, lovely, so it will be another six months to six years in coming and, > when (if) it finally does show up, it will have "designed by committee" > written all over it? I would expect 6-12 months. An JCP is a committee. > Maybe it's best to just stick with JDK 6 then. :) Unless you like beta, then you have to. Arne
From: Roedy Green on 27 May 2010 06:23 On Tue, 25 May 2010 22:57:41 +0000 (UTC), ClassCastException <zjkg3d9gj56(a)gmail.invalid> wrote, quoted or indirectly quoted someone who said : >Because I swear it's been like *years* since I first heard mention of it >and JDK 6 still seems to be current. two things have happened that would cause delay. 1. recession and drying up of Sun's cash. 2. buying by Oracle that is much more focused on making immediate money. -- Roedy Green Canadian Mind Products http://mindprod.com Beauty is our business. ~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72) Referring to computer science.
From: ClassCastException on 27 May 2010 21:33 On Wed, 26 May 2010 09:35:13 +0000, Arved Sandstrom wrote: > ClassCastException wrote: >> Oh, lovely, so it will be another six months to six years in coming >> and, when (if) it finally does show up, it will have "designed by >> committee" written all over it? >> >> Maybe it's best to just stick with JDK 6 then. :) > > Even better, continue working with JDK 6, and if you're a > dyed-in-the-wool JVM person, expand your programming horizons with Scala > or Clojure. (defn drop-bombshell [] (.println System/out "I already know Clojure, actually.")) Yeah, I was a scout once, and still stick to that whole "be prepared" thing. :) Clojure comes in handy when you don't need seriously blazing speed and the problem lends itself to a functional style. Actually what Java really needs for speed these days is an API that lets you do arbitrary SIMD math on the machine's GPU. That seems to be where all the really sneaky optimizations are in rendering/number crunching these days, ones that JIT won't get you, and pretty much everything else you want to do is I/O bound. Actually, the other thing we really need is OS/JVM integration so the JVM heap plays nicer with paging and multitasking. I foresee a day when there's a small kernel written in C that bootstraps and provides the main API services for a JVM or similar VM, and all user-mode applications run in the VM. If the VM is stable enough, they can't crash it, just catch unhandled exceptions. The JVM's security features make it almost ideal for something like this, combined with its maturity and JIT. It seems bad for multiuser systems because one common heap would impede the ability to set per-user quotas and the like, BUT this is easily solved by having separate VM instances per user, with appropriate heap size limits and appropriate limits on CPU hogging enforced by a minimalist scheduler in the C kernel. But it'll probably be a while before we see this style of OS; and a major competing possibility is for the OS to merge with the browser instead and browser-based apps to take over. But then the browser becomes a kind of VM, doesn't it...
From: ClassCastException on 27 May 2010 21:33
On Wed, 26 May 2010 09:35:13 +0000, Arved Sandstrom wrote: > ClassCastException wrote: >> Oh, lovely, so it will be another six months to six years in coming >> and, when (if) it finally does show up, it will have "designed by >> committee" written all over it? >> >> Maybe it's best to just stick with JDK 6 then. :) > > Even better, continue working with JDK 6, and if you're a > dyed-in-the-wool JVM person, expand your programming horizons with Scala > or Clojure. (defn drop-bombshell [] (.println System/out "I already know Clojure, actually.")) Yeah, I was a scout once, and still stick to that whole "be prepared" thing. :) Clojure comes in handy when you don't need seriously blazing speed and the problem lends itself to a functional style. Actually what Java really needs for speed these days is an API that lets you do arbitrary SIMD math on the machine's GPU. That seems to be where all the really sneaky optimizations are in rendering/number crunching these days, ones that JIT won't get you, and pretty much everything else you want to do is I/O bound. Actually, the other thing we really need is OS/JVM integration so the JVM heap plays nicer with paging and multitasking. I foresee a day when there's a small kernel written in C that bootstraps and provides the main API services for a JVM or similar VM, and all user-mode applications run in the VM. If the VM is stable enough, they can't crash it, just catch unhandled exceptions. The JVM's security features make it almost ideal for something like this, combined with its maturity and JIT. It seems bad for multiuser systems because one common heap would impede the ability to set per-user quotas and the like, BUT this is easily solved by having separate VM instances per user, with appropriate heap size limits and appropriate limits on CPU hogging enforced by a minimalist scheduler in the C kernel. But it'll probably be a while before we see this style of OS; and a major competing possibility is for the OS to merge with the browser instead and browser-based apps to take over. But then the browser becomes a kind of VM, doesn't it... |