-
Rumor: Java 6 update 2 will be 2-4MB? (24 messages)
- Posted by: Joseph Ottinger
- Posted on: May 11 2007 12:56 EDT
At a post-JavaOne dinner with some very bright people, a rumor about update 2 of the Java 6 JRE was mentioned. The rumor is that update 2 will indeed be a slimmed-down version of the JRE - stripped down to around 2-4 megabytes. Details were fleeting, but if it's true, this might be the kick that Java in the browser has needed for a long time. We'll try to chase this down at JavaOne on Friday, but Fridays tend to be a bit spare... and it may be that people from Sun aren't talking much about it. The rumor said that it was an update "floating around inside Sun" so it may be unofficial - and it may not work at all. This is still a great idea, if true - and might go a long way toward dispelling some of the doubtful opinions about JavaFX. Addendum: a TSS reader pointed out this interview with Bob Brewin that effectively confirms the rumor, although specifics aren't given.Threaded Messages (24)
- Re: Rumor: Java 6 update 2 will be 2-4MB? by John Shuster on May 11 2007 14:58 EDT
- Re: Rumor: Java 6 update 2 will be 2-4MB? by Undisclosed Undisclosed on May 11 2007 16:02 EDT
- Re: Rumor: Java 6 update 2 will be 2-4MB? by Osvaldo Doederlein on May 14 2007 12:39 EDT
- Rumor: Java 6 update 2 will be 2-4MB? by Irakli Nadareishvili on May 14 2007 08:40 EDT
- Re: Rumor: Java 6 update 2 will be 2-4MB? by Undisclosed Undisclosed on May 11 2007 16:02 EDT
- Re: Rumor: Java 6 update 2 will be 2-4MB? by Jess Holle on May 12 2007 02:47 EDT
- Re: Rumor: Java 6 update 2 will be 2-4MB? by Jess Holle on May 12 2007 02:49 EDT
- wrong by ahmet a on May 13 2007 05:25 EDT
- Re: wrong by Henrique Steckelberg on May 13 2007 08:21 EDT
- Re: wrong by Mark N on May 13 2007 09:54 EDT
-
Re: wrong by Jess Holle on May 15 2007 09:10 EDT
- Do we really need to prepoluate the disk cache? by Jin Chun on May 16 2007 07:52 EDT
- depends where you live! by m pantla on May 14 2007 03:33 EDT
- Re: wrong by Jon Strayer on May 14 2007 13:49 EDT
- Re: wrong by Henrique Steckelberg on May 13 2007 08:21 EDT
- too little too late by Casual Visitor on May 13 2007 06:47 EDT
- Re: too little too late by Mark N on May 13 2007 09:57 EDT
-
Too late? Always late! by Jack Surrender on May 13 2007 02:20 EDT
- Re: Too late? Always late! by ahmet a on May 13 2007 04:08 EDT
- Time to market by Frank Bank on May 13 2007 06:16 EDT
- Re: Too late? Always late! by George Coller on May 14 2007 10:16 EDT
-
Too late? Always late! by Jack Surrender on May 13 2007 02:20 EDT
- Re: too little too late by Mark N on May 13 2007 09:57 EDT
- Re: Rumor: Java 6 update 2 will be 2-4MB? by Richard Burton on May 13 2007 22:01 EDT
- Re: Rumor: Java 6 update 2 will be 2-4MB? by Jin Chun on May 14 2007 08:18 EDT
- Re: Rumor: Java 6 update 2 will be 2-4MB? by James Watson on May 14 2007 09:12 EDT
- Thank you Sun! by Gili _ on May 17 2007 13:40 EDT
- Somebody missed the deployment technical session by Augusto Sellhorn on May 17 2007 16:11 EDT
-
Re: Rumor: Java 6 update 2 will be 2-4MB?[ Go to top ]
- Posted by: John Shuster
- Posted on: May 11 2007 14:58 EDT
- in response to Joseph Ottinger
They must be removing the CORBA packages -
Re: Rumor: Java 6 update 2 will be 2-4MB?[ Go to top ]
- Posted by: Undisclosed Undisclosed
- Posted on: May 11 2007 16:02 EDT
- in response to John Shuster
If it is really going to be divided, the question is how modular is it going to be? The core + the rest is not good enough. But, if we will have something more granular like core + awt + swing + net + rmi + sql + logging + corba + ..., that would be something. The important thing there would be how independent those parts can be, and versioning. Or, would it be possible to use core-6u2 + swing-6u3 + loggind-7u1? -
Re: Rumor: Java 6 update 2 will be 2-4MB?[ Go to top ]
- Posted by: Osvaldo Doederlein
- Posted on: May 14 2007 12:39 EDT
- in response to Undisclosed Undisclosed
If it is really going to be divided, the question is how modular is it going to be?
The core + the rest is not good enough. But, if we will have something more granular like core + awt + swing + net + rmi + sql + logging + corba + ..., that would be something.They can make it as modular as the runtime's internal dependencies allow. For example, it's useless splitting the logging API into a separate download, if several other APIs invoke it, so as soon as an application tries to load a class from SWT, CORBA or whatever, the classloader will hit a reference to some logging class and trigger the downloading of that package. This would botch the whole modularized JRE idea - some app developer carefully writes a JAWS program that depends only on core+AWT+Java2D, excepting a maximum JRE download of (say) 2.3Mb, promises that to its clients, and when clients who don't have the JRE try the app, it loads 5Mb of JRE due to internal dependencies.
See for example IBM JDK, it's already modularized in a way, its jre/lib directory splits the core into no less than 21 jar files (v5.0). For example, there's a xml.jar (6Mb), a graphics.jar (6.4Mb - with AWT, 2D, Swing, ImageIO, Sound etc), and a ton of ibm*.jar with CORBA and security APIs. But the way they broke it seems tuned mostly toward WAS and also to separate Sun's code from IBM's code, e.g. the CORBA and security stuff is all cleanroom-made by IBM and there's even a BD.jar of 40Kb just for BigDecimal, which implementation was made by IBM (but adopted by Sun years ago).
Having said that, proper modularization tuned for downloading shouldn't be that hard, at least for coarse-grained pieces like Swing. Sun hackers should be all busy now, running JDepend on their code and refactoring bogus dependencies. ;-) And it's not only the rt.jar, the JRE contains a good chunk of native code: for 6.0u1/Win32, 54 DLLs with 6,6Mb + HotSpot Client's 2,2Mb in a single DLL. Most native code appears to be already very well modularized (unless internal dependencies cause most DLLs to be loaded all the time). But HotSpot isn't, and it's pretty honking big, even for the Client VM. It compresses down to 765Kb, still a huge part of a goal of 2Mb for the full JRE. But I bet the VM can be broken down into some additional pieces. For example, HotSpot offers several options of Garbage Collectors, but most client-side don't use fancy GC tuning anyway so all code supporting this, and any other non-default stuff of significant size, could be moved to a separate DLL(s) that's downloaded on demand.
There are also resources of significant size, like TTF fonts, i18n data (charsets, timezones etc), CMM and audio soundbank. I hope the new runtime can split these bits too. Many apps never use these things, for example who needs Java's fonts when the first rule of decent native LAF is using the "system" fonts bundled with each OS? Apps tuned for fast downloading in the componentized VM could also take care to not depend on such resources.
-
Rumor: Java 6 update 2 will be 2-4MB?[ Go to top ]
- Posted by: Irakli Nadareishvili
- Posted on: May 14 2007 08:40 EDT
- in response to John Shuster
And I had a beer with some very bright people and they confirmed that Schwartz has six fingers on his left foot. More shocking news from JavaOne on the way... Stay tuned... -
Re: Rumor: Java 6 update 2 will be 2-4MB?[ Go to top ]
- Posted by: Jess Holle
- Posted on: May 12 2007 02:47 EDT
- in response to Joseph Ottinger
For being at JavaOne you guys seem to have quite carefully missed all of these details considering I saw them in presentations multiple times throughout the week. The JRE will be modularized to given something like a 2MB hello world distribution, a 4MB distribution for limewire, etc -- with lazy loading grabbing additional things in chunks as needed. While pieces (e.g. the more usable installer GUI) will start showing up in Update 2, I never heard anyone promis the kernel installer feature for Update 2. -
Re: Rumor: Java 6 update 2 will be 2-4MB?[ Go to top ]
- Posted by: Jess Holle
- Posted on: May 12 2007 02:49 EDT
- in response to Jess Holle
The JRE will be modularized to given something like a 2MB hello world distribution, a 4MB distribution for limewire, etc -- with lazy loading grabbing additional things in chunks as needed.
Note this was 2 and 4MB of JRE distribution -- not application code. -
wrong[ Go to top ]
- Posted by: ahmet a
- Posted on: May 13 2007 05:25 EDT
- in response to Joseph Ottinger
i dont think JRE size or CORBA packages is the problem today. Today most people has a broadband connection. 10Megs JRE takes 3 minutes to download. And updates are not so frequent, so it is not a big problem for dial up users either. Problem is the incremental updates and managing the different versions. download should be automatic and done with a single click. for linux it is difficult because all has a different central package management how will this Java kernel fit there? -
Re: wrong[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: May 13 2007 08:21 EDT
- in response to ahmet a
The size reduction will solve just part of the problem, because start up time will continue to be too long, as I've read somewhere. Both problems (plus the update issues) need to be solved for users to finally have a really good desktop java app impression. -
Re: wrong[ Go to top ]
- Posted by: Mark N
- Posted on: May 13 2007 09:54 EDT
- in response to Henrique Steckelberg
The size reduction will solve just part of the problem, because start up time will continue to be too long, as I've read somewhere. Both problems (plus the update issues) need to be solved for users to finally have a really good desktop java app impression.
I thought this was to solve the "java don't act like flash on startup for things that you might use flash for" issue. For desktop apps, which Flash is [currently] not for, Java 1.6 is pretty good. -
Re: wrong[ Go to top ]
- Posted by: Jess Holle
- Posted on: May 15 2007 09:10 EDT
- in response to Henrique Steckelberg
The size reduction will solve just part of the problem, because start up time will continue to be too long, as I've read somewhere. Both problems (plus the update issues) need to be solved for users to finally have a really good desktop java app impression.
Startup time is being addressed by pre-populating the disk cache in the background. -
Do we really need to prepoluate the disk cache?[ Go to top ]
- Posted by: Jin Chun
- Posted on: May 16 2007 07:52 EDT
- in response to Jess Holle
I've asked this before, and maybe I am dead wrong, but can't we have all of the runtime files for say Windows distributed in the form of an OCX or dll? I'm sure that if the Flash VM had a big chunk of its core runtime in the form of a jar, with or without disk caching, startup problems would be similar to what we have now. Can't we just load and pin? -
depends where you live![ Go to top ]
- Posted by: m pantla
- Posted on: May 14 2007 03:33 EDT
- in response to ahmet a
in the states, europe and asia you have lots and lots of cheap broadband... i'm in south africa - and we pay for broadband! there was a piece in a local paper saying it would be cheaper to fly to hong kong and download from there that to sign up for broadband here. -
Re: wrong[ Go to top ]
- Posted by: Jon Strayer
- Posted on: May 14 2007 13:49 EDT
- in response to ahmet a
i dont think JRE size or CORBA packages is the problem today. Today most people has a broadband connection.
While that might be true, it's not true enough. You can't afford to make almost half (or even a third) of your potential customers wait half an hour to access your site.10Megs JRE takes 3 minutes to download.
Vs. how many seconds for a flash plugin? The total of all of my Firefox plugins is a third of that 10megs. -
too little too late[ Go to top ]
- Posted by: Casual Visitor
- Posted on: May 13 2007 06:47 EDT
- in response to Joseph Ottinger
Who cares any more? -
Re: too little too late[ Go to top ]
- Posted by: Mark N
- Posted on: May 13 2007 09:57 EDT
- in response to Casual Visitor
Who cares any more?
Obviously a lot of people. -
Too late? Always late![ Go to top ]
- Posted by: Jack Surrender
- Posted on: May 13 2007 14:20 EDT
- in response to Mark N
Sun is always building hopes just to crush them with long awaiting. Sun has either lack of vision, ability to execute or not enough resources. If you don't want to feel like a jilted lover, just stay away - don't put your hopes in Sun fulfilling stated or inferred promisses. A slick IDE for JavaFX? It will be late and shortcoming. Look for Eclipse or IDEA plugins. Expect handcode in either. Small JRE? Maybe. Flawless updates? No way. They will cave in to interests API. There's not way Sun will be the true provider for enthusiastic coders. They don't believe in you. -
Re: Too late? Always late![ Go to top ]
- Posted by: ahmet a
- Posted on: May 13 2007 16:08 EDT
- in response to Jack Surrender
They don't believe in you.
Talk for yourself. -
Time to market[ Go to top ]
- Posted by: Frank Bank
- Posted on: May 13 2007 18:16 EDT
- in response to Jack Surrender
Sun is always building hopes just to crush them with long awaiting. Sun has either lack of vision, ability to execute or not enough resources. If you don't want to feel like a jilted lover, just stay away - don't put your hopes in Sun fulfilling stated or inferred promisses.
How often do things in the software world make a comeback? Rarely. Does Sun have a tendency to be reactionary instead of proactive? Yes. Think of Sun's attitude towards alternative languages on the JVM until now. Think of Sun's attitude towards Linux until not too long ago. What is the average view of applets? Not good. To be fair to Sun, they don't have the nearly infinite resources that a company like Microsoft has, so Sun chased the serverside for a long time, which is understandable. But that doesn't really change perceptions. Java is open source now. For those that do care, it's time for them to take control into their own hands.
A slick IDE for JavaFX? It will be late and shortcoming. Look for Eclipse or IDEA plugins. Expect handcode in either. Small JRE? Maybe. Flawless updates? No way. They will cave in to interests API. There's not way Sun will be the true provider for enthusiastic coders.
They don't believe in you. -
Re: Too late? Always late![ Go to top ]
- Posted by: George Coller
- Posted on: May 14 2007 10:16 EDT
- in response to Jack Surrender
Sun is always building hopes just to crush them with long awaiting. Sun has either lack of vision, ability to execute or not enough resources. If you don't want to feel like a jilted lover, just stay away - don't put your hopes in Sun fulfilling stated or inferred promisses.
I don't think it is healthy to be this emotionally attached to technology issues. Paging Dr. Phil...
A slick IDE for JavaFX? It will be late and shortcoming. Look for Eclipse or IDEA plugins. Expect handcode in either. Small JRE? Maybe. Flawless updates? No way. They will cave in to interests API. There's not way Sun will be the true provider for enthusiastic coders.
They don't believe in you. -
Re: Rumor: Java 6 update 2 will be 2-4MB?[ Go to top ]
- Posted by: Richard Burton
- Posted on: May 13 2007 22:01 EDT
- in response to Joseph Ottinger
What's 2 to 4 MBs between JDK's? It's already very large and it'll only get bigger. They need to find a way to trim the fat honestly. Why is it so huge anyhow? Best Regards, Richard L. Burton III -
Re: Rumor: Java 6 update 2 will be 2-4MB?[ Go to top ]
- Posted by: Jin Chun
- Posted on: May 14 2007 08:18 EDT
- in response to Richard Burton
good question. delete rt.jar and you can't run anything. Even with the shared archive, I think we've taken things to the extreme to silly. If I download the JRE onto my system, I know its Window's based, which version of Windows it is (or the installer knows) and then everything can be installed as a couple of exe's and a bunch of dll's that get mapped as soon as I load them. What the target system is, that information is already available. Make it cross platform at the bytecode level for user code, but make the targeted runtimes as lean and mean as possible. -
Re: Rumor: Java 6 update 2 will be 2-4MB?[ Go to top ]
- Posted by: James Watson
- Posted on: May 14 2007 09:12 EDT
- in response to Richard Burton
What's 2 to 4 MBs between JDK's? It's already very large and it'll only get bigger. They need to find a way to trim the fat honestly.
Maybe I'm missing something. I thought the point was that the JRE would be 2-4 MB total. I'm I wrong?
Why is it so huge anyhow?
Best Regards,
Richard L. Burton III -
Thank you Sun![ Go to top ]
- Posted by: Gili _
- Posted on: May 17 2007 13:40 EDT
- in response to Joseph Ottinger
In my view, this is a huge step in the right direction. It doesn't solve all problems for Desktop Java but it certainly tackles the biggest one: deployment issues. -
Somebody missed the deployment technical session[ Go to top ]
- Posted by: Augusto Sellhorn
- Posted on: May 17 2007 16:11 EDT
- in response to Joseph Ottinger
There was also a deployment BOF I think (I missed it), plus this "Consumer JRE" was mentioned at the keynote. Joseph you need to pay more attention next time! :-) Here are my notes for the "Easy deployment is finally here" talk; http://sellmic.com/blog/2007/05/16/easy-deployment-is-finally-here-session-my-notes/