|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 24
Messages: 24
Messages: 24
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Rumor: Java 6 update 2 will be 2-4MB?
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.
|
|
|
Message #232650
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Rumor: Java 6 update 2 will be 2-4MB?
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?
|
|
|
Message #232670
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Rumor: Java 6 update 2 will be 2-4MB?
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.
|
|
|
Message #232671
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Rumor: Java 6 update 2 will be 2-4MB?
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.
|
|
|
Message #232688
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
wrong
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?
|
|
|
Message #232691
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: wrong
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.
|
|
|
Message #232693
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: wrong
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.
|
|
|
Message #232696
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Too late? Always late!
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.
|
|
|
Message #232702
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Time to market
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.
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.
|
|
|
Message #232703
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Rumor: Java 6 update 2 will be 2-4MB?
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
|
|
|
Message #232709
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
depends where you live!
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.
|
|
|
Message #232719
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Rumor: Java 6 update 2 will be 2-4MB?
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.
|
|
|
Message #232720
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rumor: Java 6 update 2 will be 2-4MB?
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...
|
|
|
Message #232722
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Rumor: Java 6 update 2 will be 2-4MB?
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
Maybe I'm missing something. I thought the point was that the JRE would be 2-4 MB total. I'm I wrong?
|
|
|
Message #232727
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Too late? Always late!
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.
I don't think it is healthy to be this emotionally attached to technology issues. Paging Dr. Phil...
|
|
|
Message #232736
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Rumor: Java 6 update 2 will be 2-4MB?
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.
<p>
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.
<p>
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).
<p>
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.
<p>
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.
|
|
|
Message #232739
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: wrong
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.
|
|
|
Message #232769
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: wrong
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.
|
|
|
Message #232856
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Do we really need to prepoluate the disk cache?
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?
|
|
|
Message #232926
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thank you Sun!
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.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
