Modular, Lightweight JRE: Not a Rumor

Home

News: Modular, Lightweight JRE: Not a Rumor

  1. Modular, Lightweight JRE: Not a Rumor (9 messages)

    Ethan Nicholas says that a lightweight, Consumer JRE is not a rumor. Sun is working on it and it will be available in the first half of 2008. Most people were so busy speculating about what JavaFX means (or doesn't) that they missed the actual announcement. The promise of JavaFX is likely tied to the Consumer JRE. Ethan says:
    The Consumer JRE is a release of Java 6 targeted at making the end-user experience better, meaning smaller downloads, faster installs, better graphics performance, smoother installation, faster startup, better reliability, and a bunch of other nice enhancements.
    The Consumer JRE will allow execution of a typical Swing applications with a JVM installation of 3 to 4 MB as downloaded, and additional libraries and JVM elements will be installed on-demand, and in-place, when needed and without creating a myriad of JRE versions on the end-user's hard disk. Is the Consumer JRE a good idea? Do you think it stands a fighting chance against Adobe's Flash or Microsoft's .Net? How does this environment stack up against proven, portable technologies like Qt that ISVs prefer for portable desktop applications? See "Rumor: Java 6 update 2 will be 2-4MB?" for more on this.
  2. The on-demand aspect-- is this something the app needs to specify up front in the meta-inf or do we run the possibility that the JRE will start downloading dependent classes while the user is using the app. The impression given at one of the J1 talks was that it would download while the user is using the app.
  3. Good idea, definitely. My only concern is whether 1st half 2008 is too late... we're leaving Flex/Apollo and Silverlight one year advantage. Hopefully not.
  4. I think the assumption that jre size (13MB) is somehow a problem is false. That is not the issue. The real issue is keeping it up to date and making the whole process seamless. In recent years this has improved much. The current problem is that between major releases, no new major functionality can be pushed to users. This is caused by the fact that everything needs to be part of the base platform as defined and frozen with major releases every two or three years. This causes important stuff to be not included (for various reasons) and delays the moment other stuff can be used on wide scale unnecessarily. There's an opportunity to do more in between and also to broaden the scope of what can be installed this way. E.g. swt and other commonly used libraries could be distributed this way. This has the advantage that it reduces download size of applications. I don't see how modularity relates to performance though. Breaking a jar file in two doesn't magically make either half any faster and of course Java class loader only loads stuff it actually needs inside the jar(s).
  5. Jilles wrote:
    I think the assumption that jre size (13MB) is somehow a problem is false. That is not the issue.
    The JRE size is an issue for consumer-oriented software. I've worked for two major companies whose main development thrust is in Java but who had to use native Microsoft languages and libraries to reach their biggest demographic because of download issues. Joe Smith as a user won't have the patience to sit through a larger download than 4 MB in order to use some software player or application. We experienced the same problem with both Java and .Net given that a large number of machines in the wild still lack .Net support (only newer systems come with .Net pre-installed, and the business requirements specified support back to Windows 2000 in one of those cases). Having a modular JRE, especially if it's updated "on demand", would be a huge win for companies who have a need like the one I described. It will also help Java compete better with Apollo, Silverlight, and .Net itself. I just wish that Sun's timeline wasn't so tight. Cheers, Eugene Register here for TheServerSide Java Symposium Barcelona My presentations: BOF: From specs to mission-critical app - choosing an ESB Enterprise Application Mashup: Architecting the Future - encore presentation after TSSJS Las Vegas
  6. WHAT ?!!!! first half of 2008[ Go to top ]

    oh ,what a stupid timeframe, it seems that those at sun does not know any thing about the market they competing in,the flex SDK and runtime and tools is available NOW, the silverlight SDK and runtime and tools is available NOW ,and sun is comming to say "we r competing with them (after one year from now we will provide ur users with the runtime)", and iguess the first tool will be available in 2 years and the first really usable tool in 4 years(yes it takes about 3 years in sun to provide something usefull(remember netbeans and studio creator)) SO the JavaFX is around several years behind the competitors instead to be the trunk in this market(it is 12 years old now) SUN: please u can provide us qwith something usable(runtime) in about 3 monthes (u have the JDK and several micro VMs from mobile companies etc..) and pump some money in the tools development team to provide us soon with some usefull tool (you must't provide this as a free tool if this degrade the budget) i hope all wise men at sun satisfy the market requirements to give us competitive advantage in this area joe
  7. This is brilliant, so i can start Swing/Applet type stuffs again! perhaps with JavaFX :) without fighting on JavaScript or browser side scripting i can again keep my smile with Applet type stuff.. :) that’s really smell good.
  8. Size Matters[ Go to top ]

    You bet JRE size makes a difference. Most of the world's people, the ones who have access to computers, have 1) non-broadband internet; 2) Pentium 2 or Pentium 3 class machines; and 3) memory below 256MB. For these people the current ~15MB JRE is too big. It's so big they don't want it on their machine. If they are very patient and it gets onto their machine, it starts slowly and then grinds everything to a halt with it's massive memory footprint. It's amazing how many Java people don't get it that the small, fast, and efficient Flash runtime killed Java applets. Because of this, Java programmers have no viable Java platform for Rich Internet Applications (RIA). Instead, we must learn Flash/Flex or Javascript/AJAX. It's a shame because Applets practically invented RIA and held so much promise. Next up, watch Flash Lite kill J2ME on mobile phones.
  9. Re: Size Matters[ Go to top ]

    You bet JRE size makes a difference. Most of the world's people, the ones who have access to computers, have 1) non-broadband internet; 2) Pentium 2 or Pentium 3 class machines; and 3) memory below 256MB. For these people the current ~15MB JRE is too big. It's so big they don't want it on their machine. If they are very patient and it gets onto their machine, it starts slowly and then grinds everything to a halt with it's massive memory footprint.

    It's amazing how many Java people don't get it that the small, fast, and efficient Flash runtime killed Java applets. Because of this, Java programmers have no viable Java platform for Rich Internet Applications (RIA). Instead, we must learn Flash/Flex or Javascript/AJAX. It's a shame because Applets practically invented RIA and held so much promise.

    Next up, watch Flash Lite kill J2ME on mobile phones.
    Well, if I would have to make the choice between server-side java as the enterprise platform it is today, and java the client side flash killer, with total domination in the "I cant afford a new computer" segment, then I know which route I prefer. There are few enterprises rolling out business applications using flash, and quite frankly I dont think that this is likely to change. 1996 - lots of people where bitten by the client-server bugs, and html generated on the server-side looked very promising. To bad usability suffered a bit, but then again, the people paying the bills saw other benefits.
  10. Applets kill Flash already[ Go to top ]

    You wouldnt notice it but on any decent net connection java applets are downloading and starting up as fast or faster than Flash. Only one problem, there ARENT many Applets anymore. And thats not because of download times. Im prompted to download a new version of QuickTime, Flash, Firefox whatever every other day as long as a JRE or applet download. Its that Java Swing is NOT (and never was intended to be) an animation suite. Flash was intended to show highly graphical animation. For any programming language animation is well, a sideshow. Now once you get beyond that fact you have to imagine where DOES Java fit on the client? And applets well, are stuck with Swing. Which SUN hasnt made enough effort to make pretty and usable on any platform. And maybe SUN wont be able to make it that cool ever again and they lost their opportunity. But on the other hand if THEY DID...You could say goodbye to about every other thing besides the flash player and Mozilla XUL because the technology capability is there unlike flex and so and so and yada yada. So I dont think it matters that much, I have been working on an Applet for the past month unlike probably well 99 percent of other Java devs out there and Im pretty happy with the results and download times and speed are not a problem and Im doing some moderate to heavy lifting. If SUN makes it better great. But the red headed step child is not so red headed anymore and you might find out your more closely related than you thought.