Skip to main content

Bigger is worse for Java 6+

58 replies [Last post]
netsql
Offline
Joined: 2004-03-07
Points: 0

I hold it to be self evident.
As per thread on http://www.theserverside.com/news/thread.tss?thread_id=34981 on "Whale".
The perception is that Java JRE SEis big to install. 15 megs default.
Compare it to Flash Runtime:
http://www.macromedia.com/shockwave/download/download.cgi?P1_Prod_Versio...
Less than a meg.

More users have Flash already, so Flash developers (http://www.macromedia.com/software/flash/productinfo/features/static_tou... ) have an advantage. It's a big disadvantage to have a large download for our applications.
The goal should be to remove what is not needed out of default JRE and to reduce the size back down to less than 4-5 megs as default.

Furthermore, Longhorn include CLR C# v2. And it's "Internet Explorer" has security sandbox that will make it even harder to install Java w/o Admin privileges. No Java, no Java Applications, no Java developers.

For example, Rhino could be in SDK, we know how to include it in our apps if we need it.
CORBA should be in SDK.
JDBC should in in J2EE. It needs a driver in any case to work. We know how to include it.
Remove the deprecated stuff.
Deprecate even more, move to optional jars (that don't get installed at default)
Remove the binary things that are not needed by default.
etc.
There are other ways documented by Stanley Ho as to how to reduce the JRE SE size. That should be a default.

This reminds me of a story, when 3Com used to dominate LAN OS, w/ EtherShare.
Then they decided to do EtherShare plus, it was much larger run time then EtherShare, and users/developers switched to Novell, since it was still light.
Moral of the story: We are not going to C#, but are forced there by Sun because it's too large to deploy w/ default needs.

When we write webstart applications, they will have to go Flash (used by all baner advertisers) and ClickOnce (imo it's very good), we likely have to upgrade the Java on the box. (w/ WebStart, we reduce the # of JRE's on users machines)

So, Java is moving in opposite directions of where the developers want it. We want better/faster/lighter Java. Heavy is not the way, remove the bloat even if not everyone middle manager at Sun gets all their features in.
Lets fix it please.

.V

ps: more on deployment? JDIC does not support Mac(we have to use SWT for the browser component. Even in windows it has a border bugs). WebStart does not support windows 64 bit, nor deployment in corporate, where there are no admin privileges. Give us break guys

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jwenting
Offline
Joined: 2003-12-02
Points: 0

> At work we have been updating our workstations to
> Dell GX280s, all of them have come with Java 1.4.2
> preloaded.

so half a year after Tiger hits the streets hardware vendors are still shipping 1.4 with their machines.
In fact I'm pleasantly surprised by that, as 1.3 was still the current JVM in most companies in 2003 (when 1.4 had been around for over a year), but it's still worrying for all those shipping 1.5/5.0 based applications with the instruction to install a JVM if there's none installed and will be getting support calls about their Java apps not working and crashing with "incompatible classfile format" errors.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

FYI: Please see the "incremental update" feature mentioned here: http://weblogs.java.net/blog/stanleyh/archive/2005/05/deployment_unde_1....

Once some JRE is already installed, installing any new JRE with the online installer is very cheap (or so it says) ;)

The problem is getting the first JRE installed. I guess this means that so long as the OS comes pre-bundled with a recent JRE, updating it for your specific application should be cheap.

Finally note this does not help when upgrading users across major version numbers (i.e. 1.3 to 1.4). This implies that if we get a major JRE release every two years and OSs seem to take on the same release schedule (except Windows which is up to five years now, right?) this might actually work well.

Gili

netsql
Offline
Joined: 2004-03-07
Points: 0

> A few months ago, there was a discussion on Josh
> Marinucci's Swing blog about why people didn't ship
> Swing desktop apps. Unlike on this thread, almost
> everyone agreed that JRE size and distribution were
> major problems.

+1

Here is a sample app now at roomity.com I wrote.
Will it need a bigger JRE in the future w/ mustang?
WIll "Ana Nikole Smith" be able to install it?

My audience is not geeks, it's people.

.V

netsql
Offline
Joined: 2004-03-07
Points: 0

> I read many other developers
> telling me that they heard the same things from
> people *they* talked to. I'm simply putting one and
> one together: a lot of users complain to us about the
> JRE size.

and as thread header says:
I hold it to be self evident.
As per thread on http://www.theserverside.com/news/thread.tss?thread_id=34981 on "Whale".
The perception is that Java JRE SE is big to install.

(No one is rainsing the issue od SDK/JDK or J2EE.... we are talking about user's JRE size)

.V

jwenting
Offline
Joined: 2003-12-02
Points: 0

> If the JVM has already preinstall to the OS, every
> user will happy to use Java with no complain on
> downloading the JVM.
>
> However, if it is not. Following scenario would
> happened.
>
And even if it were there's a new version of the JVM next year.
Or do we all want to go back to the days of having to code using 1.0 because that was the only things the majority of users had and our customers/employers didn't want to force their visitors/users to download and install a newer JVM?

> User found a 500K application on web that has exact
> features he/she want. However, he/she is first needed
> an 7Mb JVM to download. ( 10-30minutes to download
> depending on connection). If I were the user, I
> would try to find other application with similiar
> features without any extra stuff to download.
>
Worse, that 7MB (which will grow a lot in Mustang) will expand upon installation to over 50MB (which is the installed size of the JRE).
That 500K application needing that 7MB download will now be a 50.5MB application once installed.

If I were an end user I'd not want that either.
Luckily I do most stuff serverside where we don't have that problem (we deliver the servers preinstalled :) ).

mthornton
Offline
Joined: 2003-06-10
Points: 0

> > If the JVM has already preinstall to the OS, every
> > user will happy to use Java with no complain on
> > downloading the JVM.
> >
> > However, if it is not. Following scenario would
> > happened.
> >
> And even if it were there's a new version of the JVM
> next year.

Even with all the new features we expect, surely an update from an existing version should be a substantially smaller download than a fresh install?

jwenting
Offline
Joined: 2003-12-02
Points: 0

> > > If the JVM has already preinstall to the OS,
> every
> > > user will happy to use Java with no complain on
> > > downloading the JVM.
> > >
> > > However, if it is not. Following scenario would
> > > happened.
> > >
> > And even if it were there's a new version of the
> JVM
> > next year.
>
> Even with all the new features we expect, surely an
> update from an existing version should be a
> substantially smaller download than a fresh install?

Maybe, but so far Sun has never released an upgrade for a JVM, instead forcing users to always install an entirely new one side by side with their existing JVMs.
After a few years of this you have many installed JVMs on your machine (and the average user won't even know, he'll just notice his harddisk space getting smaller and smaller).

Of course Sun COULD provide an upgrade option, but that's another story for another day :)

sjasja
Offline
Joined: 2004-08-15
Points: 0

> After a few years of this you have many installed JVMs on
> your machine (and the average user won't even know, he'll
> just notice his harddisk space getting smaller and smaller).

An upgrade option would be good IMHO. I just removed a couple of old JREs/JDKs (not too laborous in Windows: open "add/modify programs", click "delete". But you need to know to do that.) Maybe the installer could offer to remove the previous version.

On the disk filling with JDKs: do you know of a person who has a real problem with this? The [i]smallest[/i] hard disk that my local computer shop sells is 80 GB. That will store a thousand years' worth of JDK versions (or a mere 250 years if you get and keep every dot-dot-dot update.)

jwenting
Offline
Joined: 2003-12-02
Points: 0

> On the disk filling with JDKs: do you know of a
> person who has a real problem with this? The
> [i]smallest[/i] hard disk that my local computer shop
> sells is 80 GB. That will store a thousand years'
> worth of JDK versions (or a mere 250 years if you get
> and keep every dot-dot-dot update.)

Except of course their OS takes 2GB by now, then there's 50GB of MP3s and a few movies downloaded from Kazaa or another Pirate2Pirate network, a few games (which now average several GB each), and suddenly you're looking at an almost full harddisk.

And of course many people are still using older hardware.
I'm one of them :)
My computer at work has a 30GB harddrive, my main computer at home has a total of about a hundred but that's divided over 4 drives (2 of which are old 5GB drives).
My laptop has 4GB total, over half of that taken by its OS.
My parents have a 10GB harddisk (though they don't know it).

Neither of those machines is looking at replacement any time soon. I might replace one of the smaller harddisks at home with a larger one at some point, but that's a year off at least.
I might also get at some point a new laptop, but the old one will remain in service as a small server or something for the foreseeable future.

sjasja
Offline
Joined: 2004-08-15
Points: 0

> Except of course their OS takes 2GB by now, then
> there's 50GB of MP3s and a few movies downloaded
> from Kazaa or another Pirate2Pirate network, a
> few games (which now average several GB each),
> and suddenly you're looking at an almost full harddisk.

I would suggest that in this scenario the problem would not be JRE size but rather the collection of mp3s.

Have the user burn half of those on CDs and he'll be golden until JRE version 500.0 comes out around the year 2500. At which point he hopefully will have had time to discover the "delete" button in the "add/remove programs" window.

The installed JRE is about one album's worth of mp3s. Or less than 10% of a movie. Just delete one of your NKOTB albums, you don't listen to them that often any more anyway :[i][/i]-)

jwenting
Offline
Joined: 2003-12-02
Points: 0

We should never have to dictate what users do with their machines in order to install our software.

If they have 10MB diskspace free and our application is 500K it should fit, not fail to install because the JRE requires another 50MB (and that's the current version, Mustang will be 60, Dolphin may be 100 if things continue as they are going).

sjasja
Offline
Joined: 2004-08-15
Points: 0

> If they have 10MB diskspace free and our application
> is 500K it should fit, not fail to install because
> the JRE requires another 50MB

I'm not sure that is an attainable goal. Most languages require a runtime of some sort. C/C++ needs .dll's or .ld.so's, Perl needs those, the interepreter and .pm's, etc. If you have a 500K Perl program, 500K of space, and haven't downloaded Perl yet...

Perhaps statically linked C would accomplish that requirement? Although that makes every program bigger since each one contains copies of the same libraries.

Even if rt.jar were zero bytes, the JDK would be more than 10 MB. So splitting up rt.jar doesn't fix this problem. Perhaps a micro Java would be better for your requirements. Though even then if the user has 501 kB of space and the application is 500 kB there won't be space to get the runtime.

> (and that's the current version, Mustang will be 60,
> Dolphin may be 100 if things continue as they are going).

Do you have a reference to how you get these figures? The whole "split up rt.jar" thing seems to be so much based on guessing and sky-is-falling fears that some real facts on the severity of the problem would be a refreshing change.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

linuxhippy, unbundling components from J2SE core does not break backwards compatibility. It introduces an extra (albeit automated) deployment step, but no functionality is actually removed.

dblair, I guess the expectations nowadays is that games are justified in being bloated because they pack a lot of video animation. If I was downloading a 30MB Java game, I wouldn't mind downloading a 7MB alongside it. I think this discussion is more isolated to people complaining about downloading a 7MB JRE for a 100k desktop applications. This is usually hard to justify for dial-up users who would just as rather skip your app because it is too cumbersome to install then try it.

I personally love the idea of making deprecated classes an optional component so if your application does not use any deprecated classes, they are never downloaded. I fear, however, that debundling deprecated methods is another story (it is probably too fine-grained to implement easily or efficiently). But yeah, the idea itself is great.

Another thought I just had: regardless of whether we modularize the J2SE or not, we want this sort of install-on-demand anyway. As far as I know, currently in Webstart if two applications depend on a 3rd party library of the same version, two distinct copies of it are installed. Ideally we want J2SE to be much more deployment-aware and only install one copy of this library. Webstart deployment tricks should be tightly incorporated into J2SE such that *all* applications benefits from it, even if they weren't explicitly coded JNLP in mind. At least, that's the ideal :)

For example, Webstart applications now automatically detect proxy configuration from your default browser (under Windows at least). Why don't non-Webstart applications have this feature? As far as I know, normal applications have to manually query the user for his/her settings.

alexlamsl
Offline
Joined: 2004-09-02
Points: 0

I think I'd have refrained from even trying out Java back years ago if it weren't for its handy libraries - I liked Perl for its elegance in the language but having to look for the right library files to download, setup, make... it was a bit over the top for me ^^"

In fact this even refrains me from using Perl script packages that others have written - I'm sure most of them are good in functionalities - just because of all the confusions with those "optional" libraries (that could be conveniently, apparently, be downloaded from CPAN).

I still love Perl (& many many languages - even direct machine "assembly" codes are cool for their total control + expressiveness over the system that, face it, bought and hence belongs to me!) - but as far as serious, large-scale in terms of man-power, conceptual complexity, maintainence etc. I just stick to Java for its absolute ease of development, esp with its literally zero-trouble setup + deploy on modern systems.

I still haven't come across a project that would need the whole of J2SE - in fact, I'd quite like to explore through the JavaDocs to try out some of the libraries some day. It's the fact that they are here on my system - not in CPAN - that enable me to learn & utilise all the benefits delivered by the standards.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

> The majority think just that, or would if they
> thought about it.
> They don't use 20% of what's in there, and usually
> it's the same 20%.
> But our voices are snowed under by the constant
> battering of a few people who scream to make their
> DEMANDS for MORE MORE MORE heard over all the other
> shouting by the others of their group.
Where do you know that from? Leaving classes away from SE would just break backward compatibility - from the 7.5mb build just about 3mb are classes which are compressed in a very efficient manner.
The problem is that every program uses a different part of java, I don't use swing for example but AWT or javax.print and other seldom used apis.

> These features should be optional packages, like they
> were in the past.
And for what? Broken compatibility and 1.5mb smaller download. Wow.

> Linux is run by a group of religious fanatics who
> won't touch anything that doesn't meet their
> standards of "free".
> MacOS is too marginal to be of consequence.
Well of course, since you use Windows (maybe you're too mentally limited to use anything else??) anybody else is just marginal or religious fanatic. Of course - how could it be different ;-)

lg Clemens

dblair
Offline
Joined: 2004-08-12
Points: 0

Awesome Linux Hippy! Put him in his place!

> But our voices are snowed under by the constant
> battering of a few people who scream to make their
> DEMANDS for MORE MORE MORE heard over all the other
> shouting by the others of their group.
If I look at the post counts, the constant battering of a few people is coming from YOU jwenting and cowwoc...except cowwoc makes sense when he posts...you just sound angry and put everybody down.

As for dialup and downloads, me and my dialup friends play this game, World of Warcraft...the patch on Tuesday was 30 meg...the one a month back was 50 meg. We were willing to wait.

I have nothing against a bloated JRE...actually 7 meg is really nothing to be able to run most java apps.

I like the idea of having another install on demand version of the JRE available...would it be possible to make all things deprecated a seperate package? Then if you had legacy code your stuff would still work, you'd just have to wait for that package to download...

DB

jwenting
Offline
Joined: 2003-12-02
Points: 0

> Firstly - I don't think the majority of developers &
> users think Java is too big to download / deploy /
> install. And in fact it is quite the reverse - Java
> is really compact and logical in design compare with
> other major programming languages nowadays.
>
The majority think just that, or would if they thought about it.
They don't use 20% of what's in there, and usually it's the same 20%.
But our voices are snowed under by the constant battering of a few people who scream to make their DEMANDS for MORE MORE MORE heard over all the other shouting by the others of their group.

> Secondly - and I think I will need to say this - when
> we mean developers & users we mean a huge group of
> people with suck wide variety that some people
> seriously need, for instance, JDBC but never ever
> CORBA (I'd have never imagined myself using the
> latter for years to come). So if the only argument
> you make for / against certain features is whether
> YOU use it or not, that's far from convincing from
> anyone's point of view.
>
These features should be optional packages, like they were in the past.

> I reckon getting (latest stable release) Java
> pre-installed on the popular OSes would be a good
> move; it's not about the size primarily - it's about
> the fact that sometimes it's just impossible to
> obtain a copy of the software in an offline
> environment.

That will never happen again. Microsoft has too much interest in .NET to provide a competitor out of the box anymore (especially given Sun's history with them).
Linux is run by a group of religious fanatics who won't touch anything that doesn't meet their standards of "free".
MacOS is too marginal to be of consequence.

prunge
Offline
Joined: 2004-05-06
Points: 0

Is 15 MB really that much? Yes, there are still many dial-up users now. But the Java 6 release is still some time away. The trend is that more people are moving to broadband, so download size is less of an issue. Unless the size of Java is increasing faster than the rate of the average user's bandwidth, I don't think it would be worth putting significant effort into splitting up the JRE. And how long would this be necessary? Dolphin is years away, and by that time even more people will have broadband.

What about this scenario? A user runs an applet that only downloads a few modules of the JRE. Then that user downloads a Java application from my website, and disconnects from the Internet (since they are using a modem). Later they try to run the application, only to be displayed with a dialog saying that extra modules (e.g. Swing, XML) need to be downloaded. How likely would it be that the user will just press cancel and delete the Java application since none of their other apps require additional downloads to run?

Perhaps Sun should instead put resources into finding better alternatives to JAR files. There are better archive formats with better compression nowadays, like BZIP2 or 7-zip. Combining a better compressed archive format with pack200 would make ALL downloads smaller.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

I keep on repeating this and people don't seem to be listening: the JRE is 7MB, not 15MB! Please spread the word so people get the picture.

People have been "moving to broadband" for over five years now and we're still at 50% of US customers on dial-up and worldwide, over 75%. I wouldn't expect these figures to change much within the next five years. Mustang is due a year from now. Besides, this is more than just a complaint about the size of the JRE download. We are just fundamentally opposed to having the JRE include so much stuff that is irrelevant to most applications. It would be easier to master core JRE if it were smaller and its optional components could be open-sourced on java.net and developed independantly at a different rate than the core. This extra flexibility is important to us.

In your second paragraph you complain about an issue I have already addressed. Webstart allows users to eagerly retrieve all dependencies on application installation so users wouldn't run the application later to find they need extra downloads. This is a simple configuration issue.

Gili

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Look... I gave this some more thought and maybe the problem isn't about who's right and who's wrong but rather it's a matter of priorities and concerns.

Recently, I've focused hard-code on releasing Java desktop software. Six months ago, when I was doing purely server-side development, I couldn't care less about JRE development, Windows L&F, etc but this has all changed.

If you are not targetting desktop users then I honestly don't think there is anything I can so or do to convince you of my points because for *you* they make absolutely no sense (and if I were in your position, I'd think exactly the same way).

So maybe the first questions we should be asking everyone who joins this discussion is:

Who is your target audience?
What are your top concerns in that domain?

There is no sense argueing with one another if we're targetting different domains.

Just my 2 cents,
Gili

sjasja
Offline
Joined: 2004-08-15
Points: 0

> The users of my application are aborting
> using the application as it needs a JRE download.

So is JRE size relevant? Would they download 5MB? Have you surveyed them?

> W/o java users, no java apps, no java developers.

Are you assuming all Java is applets?

> When I write an application in C#, users
> have to download 0.

Huh? I have two Windows machines. One of them has no C# support, I would need to download it. The other one came with both Java and .NET (an old version) pre-installed. My third computer is not Windows, so no amount of downloading will make C# run on it.

Have you somehow determined that a significant number of users refuse to download 15 MB but would gladly download 5 MB? Is the size of rt.jar a show stopper for many people?

starlord
Offline
Joined: 2003-06-10
Points: 0

> I do most of my Java work in enterprise server side
> programming, so splitting up rt.jar into separate
> pieces would help me exactly none at all.

but having java in smaller pieces doesnt any bad to you either? or does it?

but making java into smaller pieces because of dial up user isnt good thing either... if the app or whatever uses all or most of the java components, user still needs to download "full" java. so no gain there, actually causes more trouble...
but for those with small or medium featured programs it might help a little but not worth of the hassle.

but development wise this might be good.
sun devs can push new updates(fixes,new features,...) to java more quickly...

jwenting
Offline
Joined: 2003-12-02
Points: 0

> but making java into smaller pieces because of dial
> up user isnt good thing either... if the app or
> whatever uses all or most of the java components,
> user still needs to download "full" java. so no gain
> there, actually causes more trouble...
> but for those with small or medium featured programs
> it might help a little but not worth of the hassle.
>
It's actually a massive gain.
The problem is psychological. Customers expect applications to be large so having optional libraries ship as part of the application is no problem for them.
They DON'T expect to have to install large supporting infrastructure, especially if that support infrastructure is several times larger than the application itself.

And don't tell me that doesn't matter as they only have to do that once.
Most customers won't use more than one Java application and even if they do it still remains a problem to sell them that first one that's 500K but requires another 15MB download for the JRE (which then installs to twice that).
You might say it's "only" 7 now, but with all the crap lined up and screamed for it'll get to 15 by the time it's done (and if not Mustang then the next version) unless we stop the feature glud here and now.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

starlord,

I'd love to see a single Java application that actually used over 50% of the Java API. I suspect even large IDEs like Netbeans or Eclipse don't even do that.

I think you'd see gains across the board, but mostly layman desktop applications would gain.

Another issue is that Sun is becoming more and more reluctant to make modifications to the API or add new code because of fear its size will grow and/or the inability to add new features in between major JRE releases. By stripping away the optional JRE components they can have an independant release schedule from JRE core and we'd be free to add new features on a more regular basis.

Gili

jwenting
Offline
Joined: 2003-12-02
Points: 0

> > [i]So, Java is moving in opposite directions
> of[/i]
> > [i]where the developers want it. We want[/i]
> > [i]better/faster/lighter Java.[/i]
>
> By "the developers", do you mean "applet developers
> who use Java as a replacement for vector graphics
> displayer"?
>
No, also web developers who have no need for Swing, CORBA, HTTP servers in the JDK, etc. etc. etc.

> Please do not pretend to be speaking for all
> developers.
>
Everyone else seems to, but if you don't agree with them they're not supposed to?

> I do most of my Java work in enterprise server side
> programming, so splitting up rt.jar into separate
> pieces would help me exactly none at all.
>
It's not just about download size, it's about making Java a viable platform again that beginners can learn to use.
It's gotten so large that even for the standard API (not counting the J2EE) you now have a lot of people specialising in tiny sections of it because it's gotten too large to know it all well and a lot of what's in there is so obscure almost noone has any need to use it at all.

> Even with my applets I have never heard a customer
> say "I won't download 15 MB, but I would download 5
> MB". What percentage of your users really say that?
>
That's what a lot of people do say.
They don't understand why they have to install a 15MB download for the JVM (which expands to 50 or so) to run an application made up of a few hundred KB of classfiles and associated resources.

> Don't most operating systems come with preinstalled
> Java nowadays?

Sure. 1.1 JVMs. And the next versions won't.

jeremylowrey
Offline
Joined: 2007-05-22
Points: 0

We deploy remote systems that do not have internet access. When a user connects to our device, it has a local web page which allows the user to download the JRE and our application. There is limited space and we've used the packed gz trick plus optimized greatly to make our application smaller. The JRE is a size we cannot shrink, and JRE 6 is now too big to fit on our device. We are stuck with JRE 5 unless we tell our customers that they need to install JRE 6 without using our equipment. Providing a CD is an option, but there are actual logistic problems with it.

We would love to pack our own JRE or have JRE "lite" to continue with our previous customer solution.

kevinpmarkwell
Offline
Joined: 2006-10-13
Points: 0

If anyone is still reading this forum, I'd like to know where people are talking/persuading Sun about this. Their site is looking more "distancing" all the time. Customisable would be good. My parents started off with default settings so they couldn't even see my Java projects, this goes for most users. The JRE is still tricky to install, and some people would not go to an unheard of company (I know Sun Microsystems are huge, but only us geeks know that) to download weird acronyms with version control problems. To compete, Sun ought to "Flashify" the distribution, i.e. make it easy to include & update it with the OS.

tlund_
Offline
Joined: 2005-04-21
Points: 0

Isn't the .NET framework over 100MB? And if i remember correctly it isn't preinstalled on XP prior to sp1/2?
and i distincly remember having to install a 10MB servicepack for .net v1.1.
(correct me if i'm wrong).

come on guys, 50MB isn't that much with todays standards. You can't always keep supporting those with <5GB harddrives. There are even people out there using windows 95.. Even though you have chosen java (platform independent), you can't expect having every PC user out there as a potential customer. Would it be better if you used C#, and thus limiting your potential customers to Windows only? having to install a 50MB java version every 1-2 years isn't that big a deal to me.

> If they have 10MB diskspace free and our application
> is 500K it should fit, not fail to install because
> the JRE requires another 50MB
Seriously, if they have only 10MB of free space they'd be lucky to be able to run ANYTHING on Windows. Virtual memory, temp dir for install files, temporary internet files, etc, eats up 10MB in no time. If i have less than 200MB of free space, then windows starts complaining. If you had a customer with 10MB free space downloading and installing your 500K C++ app, then you'd be extremely lucky. If he'd chosen to install a few more small apps first, then your's wouldn't fit.

"How am i going to support my potential customers having Win 3.11 and 20MB HD?" come on!

Our customers have never complained when having to download 7-15 MB (online/offline install). That's probably because we tell them in advance that they have to install java. A little note or installguide on your website will suffice.

I don't have much problem with the java install being 7MB. Of course it would be better if it was preinstalled on every system out there, or if it was 1-2MB, but i think the changes that are planned for Mustang are far more important to java desktop deployment than having to download a few more MB's. If i had the choice, i'd chosen the new mustang features anytime.

Another ting to remember is that Java has never been big on desktop stuff. Who knows, maybe it never will. But still it remains one of the most popular languages (top 3: http://www.developer.com/lang/article.php/3390001). People who say that Java is going away, obviously doesn't know what they are talking about.

I think all the largest OEM's delivering Windows preinstalled (like DELL), are now, and have been for some time, shipping with latest version of java preinstalled also.

If C# is the holy grail, why not switch? (rhetorical question)

sjasja
Offline
Joined: 2004-08-15
Points: 0

> I think all the largest OEM's delivering Windows
> preinstalled (like DELL), are now, and have been for
> some time, shipping with latest version of java
> preinstalled also.

Googling for [i]HP Dell Java[/i] shows that HP and Dell started preinstalling Java two years ago. Last year I bought an Acer laptop that had Java preinstalled.

Are PC manufacturers still doing that today? Has anyone here bought a Dell or a HP Windows PC this year? Did it have Java preinstalled or on CD?

aidan_walsh
Offline
Joined: 2005-04-22
Points: 0

> > I think all the largest OEM's delivering Windows
> > preinstalled (like DELL), are now, and have been
> for
> > some time, shipping with latest version of java
> > preinstalled also.
>
> Googling for [i]HP Dell Java[/i] shows that HP and
> Dell started preinstalling Java two years ago. Last
> year I bought an Acer laptop that had Java
> preinstalled.
>
> Are PC manufacturers still doing that today? Has
> anyone here bought a Dell or a HP Windows PC this
> year? Did it have Java preinstalled or on CD?

At work we have been updating our workstations to Dell GX280s, all of them have come with Java 1.4.2 preloaded.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Personally I don't feel the expanded JRE size is a problem. 50MB is fine with me.

I think Java being preinstalled on machines is great, but only to a certain extent. If I'm deploying my application on a system with JRE 1.4.x and my application requires JRE 1.5.x, the user still has to download the entire JRE (7MB). I wish we could have incremental upgrades even across major version numbers.

Gili

ssinai
Offline
Joined: 2005-04-06
Points: 0

A few months ago, there was a discussion on Josh Marinucci's Swing blog about why people didn't ship Swing desktop apps. Unlike on this thread, almost everyone agreed that JRE size and distribution were major problems. The desktop app I am working on is less than 1 MB in byte-code, and about 4-5 MB in machine code. It's pathetic to have to include a 15 MB JRE along with the application. (I almost can't believe that the minimum JRE size for Mustang is purported to be 50 MB.) The issue of sending the user to the JRE download site to get a 7 MB JRE came up, but was quickly shot down, for good reason. For a desktop app, you want to download everything in one shot. You don't want your users to have to go to multiple websites to download an app, when people are used to downloading Microsoft apps in one self-contained install file, and then just running a simple install program. Sun is really limiting it's user-base, and doing a disservice to Java developers, by assuming that all of it's potential customers have computer science degrees and are comfortable with technical complexity.

If you want to download a desktop application, you have to include the JRE you developed with. The belief that the latest JRE will run all Java programs written with earlier versions of the SDK is simply wrong. You absolutely must download the JRE that you developed you app with! If you want several Swing apps written by different companies on your machine, you have to download a self-contained JRE with each of those, and after a few apps, it starts eating up a fair amount of disk space. Imagine having to download Adobe Reader every time you wanted to download a new Adobe Document. Yet this is akin to what Sun makes us do with Swing desktop apps.

At least when it comes to stand-alone desktop apps, Sun needs to stop pretending that the latest and greatest JRE can run all Java programs, and therefore you only need one JRE per machine. It was a nice idea, but it didn't work. Sun needs to come up with a way to let each application ship a minimal JRE that contains only the code the application needs to run. Why do I have to include a JRE with JDBC code if my program doesn't do anything with databases? Why do I need to include code for creating and managing a sorted hashmap if I don't use one?

cowwoc
Offline
Joined: 2003-08-24
Points: 0

ssinai,

I think you make a very point about many applications bundling the 15MB offline installer instead of resorting to the online one because it is more dependable.

Although, I must admit, I wrote up a NSIS installer script that automatically detects if the user has the correct JRE installed on his machine and if not downloads the JRE online installer and runs it automatically. It doesn't address the issue of "I want a specific JRE version" (it looks for a minimum version but assumes newer versions are fine) but it does go a long way toward ease of deployment.

I will gladly donate this script so others may use it if there is interest...

The downside is that it is hard to detect whether the JRE installation succeeds or fails. The only way I got this to work is by using the silent installer. So now I get a success/failure indication but from the end-user's point of view they have no ability to cancel the JRE installation (no interactive GUI is available in silent installs) nor can they configure what gets installed and where.

Anyway... for my application this was "good enough" and definately way better than asking users to download the JRE themselves or bundling 15MB as part of my package.

Gili

hpychan
Offline
Joined: 2004-09-13
Points: 0

If the JVM has already preinstall to the OS, every user will happy to use Java with no complain on downloading the JVM.

However, if it is not. Following scenario would happened.

User found a 500K application on web that has exact features he/she want. However, he/she is first needed an 7Mb JVM to download. ( 10-30minutes to download depending on connection). If I were the user, I would try to find other application with similiar features without any extra stuff to download.

While putting different package as optional is a good idea. I think the most want feature is to have a JVM Updater as the similiar feature as Windows Update. It automatically download the installation file of the JVM to my machine, and prompt me to install when it finished downloading. This will have the same effect as preinstall JVM for me. Then we just need to make the JVM updater to be small.

I think that's the statgrey used by Microsoft to make user upgrades to the latest software. Including upgrade the machine with .NET framework( C#, VB.NET )

cowwoc
Offline
Joined: 2003-08-24
Points: 0

sjasja,

You're not going to get desktop application developers coming to you with data showing that a certain percentage of potential-customers are lost due to the JVM size. Many desktop app developers do open-source stuff and so far as I know there are only a handful of desktop apps that "make it big" and have the funding to run the sort of study you are asking for. For the rest of all, this is simply outside of our league...

All I know is, the vast majority of people I talk to tell me JRE size is a big concern that keeps them away from Java stuff. I read many other developers telling me that they heard the same things from people *they* talked to. I'm simply putting one and one together: a lot of users complain to us about the JRE size. Now, maybe they're complaining about something that doesn't *really* prevent them from downloading the JRE and maybe there is some other ulterior motive here, but this is what I hear...

I think, at the very least, we can all agree the vast majority of desktop users complain about the deployment aspect of Java applications. Whether we're talking about deploying the JRE or the application, there is definately a problem that must be addressed. I think Mustang goes a long way toward addressing application deployment (Webstart is looking much better) but it does nothing for JRE deployment issues.

hpychan,

It sounds to me like you're asking for the online installer to have an option to minimize itself to the system tray while downloading the files. This sounds like it could be *very* easy to implement. I'm unsure whether I am for or against this idea, but at the very least I think it is nice to know that should we wish to go in this direction it is easy to do.

Gili

sjasja
Offline
Joined: 2004-08-15
Points: 0

> I think, at the very least, we can all agree the vast
> majority of desktop users complain about the deployment
> aspect of Java applications.

Perhaps the ones who mention the issue are the ones who have a problem downloading the JDK. So you never hear about the ones who don't have a problem. Which gives the illusion that everyone has a problem...

I have deployed a couple of applets - real applications for paying customers. Number of JDK size complainers so far: zero. So I don't buy into the "vast majority" theory without some evidence.

I wouldn't break up rt.jar without first verifying that doing so really makes Java more available to people. So far we don't seem to have any evidence of that, only guesswork.

We are talking about a download the size of two mp3 songs here. Or less than what Windows Update tells me to download several times a year.

netsql
Offline
Joined: 2004-03-07
Points: 0

2 things are interesting:

1. Sun is ADDING Rhino to JDK 6 - Mustang and making it bigger JRE for USERS to deploy.

2. This thread is now on java.net home page, but Sun's angle is how silly it is of Java developers to give it feedback. I will just reder you to the part in the orginal post in how Novell got marketshare (the part where EtherShare Plus was bloatware). Basiclay so far Sun has shown us the middle finger, saying this is "Profesional FUD" meaning that somone here gets paid to say bad things about Sun? Whatever.

Of course there is a difference btwn J2EE for things like Tomcat, that can be bigger, and SDK which could include extras.
What ever can be done to reduce the size help's use the Java developers. Take a look at what an example Java application is at roomity.com.

* Please make JRE smaller so that we can deploy more Java Applications. *

.V

sjasja
Offline
Joined: 2004-08-15
Points: 0

> ...how silly it is of Java developers to give it feedback...
> ...shown us the middle finger...
> ...Profesional FUD...

Chill, dude. Even if someone disagrees with you it isn't about "giving you the finger" or refusing to listen to feedback. It is possible for people just to disagree.

Do you have some data about how many of your users/customers currently refuse to download the JRE and would download it if it were, say, 25% smaller?

> * Please make JRE smaller so that we can
> deploy more Java Applications. *

Which applications are you unable to deploy that you could deploy if the JRE were X% / Y MB smaller? Have you asked your potential users/customers where their threshold of pain is?

Come on! Show that the problem truly exists in the real world. Show how bad it is. Show that there is a problem that can be solved by splitting up rt.jar. Surely if this is a genuine problem someone has masses of customer complaints.

rivasdiaz
Offline
Joined: 2003-06-11
Points: 0

OK, that's what I think:

PROBLEM:

Even if a client has broadband connection, he/she won't wait for an applet if the applet want to download 7 MBs to work. If the client/visitor have a fast internet connection, he/she will expect fast and responsive web pages, and fast and responsive downloadable applications. So even if the client/visitor have a broadband connection, he/she won't wait 2 minutes for an application to start, he/she will simply go other site/company. If you want your clients to see your super functional web page, to see your pretty applet, to check your perfect Java Web Startable application, you need something fast, FAST AND RESPONSIBLE!.

If the client is not using broadband, which is majority of Internet users, the situation is worst, because it will take much much more time. First world have a lot of dialup users, third world have much much much more. Maybe we can do much more with Java than any other web/app technology, but the client/visitor will never know it, because he/she will never see our fantastic applet/application. He/She will go away and play/enjoy/buy/... other maybe lower quality product, because the other company will have a more responsible/working demo/application.

POSSIBLE SOLUTION?:

Some diferent Java scenarios:

1. Server applications (App Server, Mail Server) => usually big applications, compared in size to java se, usually use a big part of java, user wanting to install and wait => would require full java se, no benefit on small java + extensions

SOLVED NOW, the client will have a CD or download what ever is required.

2. famous client applications (JEdit, Azureus, NetBeans, Eclipse) => usually small/medium applications, smaller in size to java se, usually use half or less of java, probably the user want to install and wait => small benefit on small java + extensions

PROBABLY SOLVED, the client will download everything required, because he/she wants this application. A small bad taste could remain (because of so much to download for a small/medium app).

3. small/unknown client applications/applets => usually very small applications, very smaller in size to java se, usually use a small portion of java api (in applets it's a very very small portion), clients expecting quick launch and dont want to download/wait => big benefit on small java se + extensions.

Java SE can't be split and converted to core + extensions because of compatibility reasons. we need something similar to j2me + extensions, I think it's better to have a new Java client edition or java reduced edition which is 100% compatible with java se but not as complete as java, for example:

Java CE = Client Edition = ALL DEPLOYMENT FUNCTIONALITY (this is very important) + small core api (ex. java.lang + java.io + java.util)
The rest of the API should be divided in modules/plugins/extensions

Java SE 6 = Java CE 6 + Java AWT 6 + Java SWING 6 + Java RMI 6 + Java CORBA 6 + Java PRINT 6 + ........... (current java) + Java SCRIPTING 6 (new in mustang) + Java DESKTOP 6 (JDIC new in mustang) + ........ (new in java 6)

Java SE 5 = Java CE 6 + Java AWT 5/6 + Java SWING 5/6 + Java RMI 5/6 + Java CORBA 5/6 + Java PRINT 5/6 + ........... (current java)

It means, probably Java CE 6 is compatible with Java AWT 5, but maybe no, maybe it's too expensive to check for compatibility between all modules, so If you want to use AWT with Java CE 6 you need Java AWT 6 even if you only expect Java SE 5 functionality.

It also means that you don't need the new modules that adds new functionality to Java SE 6 for Java SE 5 compatibility. Now to have a Java SE 1.4 compatible VM but upgraded to 5, you need the whole Java SE 5.

It's very important that all deployment functionality is included in java ce core because that core can run all java aplications probably downloading new modules.

If you try to run a Java Web Start application and it says:

- that you need J2SE 1.4+ to run, JWS should check if you have all required functionality of Java CE 6 + Extensions that cover all J2SE 1.4 functionality.

- that you need Java SE 5+ to run, JWS should check if you have all required functionality of Java CE 6 + Extensions that cover all Java SE 5 functionality.

- that you need Java SE 6+ to run, JWS should check if you have all required functionality of Java SE 6 to run, it means, Java CE 6 + all BASIC extensions.

- that you need Java CE 6+, Java AWT 6+, Java PRINT 6+ to run, JWS should check if you jave this specific modules.

Java Web Start should download required modules the same way now it downloads diferent versions of Java Se if required by application.

For desktop applications something have to be done. Current MANIFEST.MF do not say which version of Java SE is required. That's a big problem. MANIFEST.MF should specify explicity what is needed to run the application. If the MANIFEST.MF don't have a Main-Class attribute the jar is not expected to be run. But also if it doesn't declare a minimum Java required, it should be assumed that only Java SE 5 is required. New applications should specify which Java VM and which modules are required. Java SE 6 should be interpreted as Java CE 6 + BASIC extensions (for simplicity), but should be better to say the Java CE required version plus required modules. Desktop installed java SHOULD have the same functionality as JWS. If the jar requires a new module, Java Destop should say what is required and offer to download it. Probably CUI/GUI applications should be marked as that, so UNIX console applications could have a different interface for notifying required modules different from GUI applications. By default GUI should be assumed at least in Windows for compatibility reasons. Maybe an install configuration would be the best for UNIX/Linux.

This gives you 100% compatibility to current java applications, and allows new development to exploit smaller/faster downloads.

WARNING: The download of modules have one problem, the modules required should be downloaded from a position configured by the installed Java Core. If I install a Java VM for PowerPC from IBM, modules should be downloaded from some place at IBM, not from Sun nor java.com, because this platform is not supported by Sun. Ideally everyting should be downloaded from java.com authomatically, but that's almost imposible.

Clients should still have the chance to download/update the whole Java SE 5 to Java SE 6, but could have the chance to update modules by modules, dividing the downloads between more days and gaining inmediate improvements.

Clients would not need to update to the whole new Java SE 6 having to download big files. Similar to Windows Update or Linux YUM/APT/URPMI/YaST repositories, users could choose to update only small modules, even having separation between critical updates and new functionality updates. Clients that never run an application that requires CORBA or PRINT or SWING or XML or JDBC application won't have to update this modules ever.

Sun could also benefit from this division, solving small bugs in modules and updating them in diferent dates, then from time to time updating the whole Java SE (JRE/JDK).

All current functionality in Java SE 5 should be available in BASIC modules (the ones belonging to "SE" versions) for compatibility reasons, but new functionality should be aded as EXTRA or OPTIONAL or EXTENSION modules. Only carefully selected new modules should be added as BASIC modules. A lot of packages in Java EE are added to the following Java SE version (for ex. XML, JNDI, JDBC extended, JAAS), this modules could be added as EXTRA modules to Java SE as soon as they are released in Java EE and more applications could use those modules. Even more modules that will probably never go into Java SE could be added as EXTRA modules, like Java Communications API, Java Activation Framework, Java Mail, Java Bluetooth, Java Media Framework, Java 3D. Not everything should be added as EXTRA modules because some libraries wont be used for much time, and adding as EXTRA should imply a commitment to support over the time and implemented in all platforms.

DEVELOPERS:

Java Software Development Kit should include the whole Java SE, not only Java CE. Java Docs should be distributed including the whole Java SE, not small shunks documenting core or modules. This is needed so developers by default could use anything in Java SE, they could try everyting in Java SE. If SDK is divided, developers will find a bit harder to use/download modules and won't use them.

Lazy programmers will mark their applications as require Java SE, but smarter ones will try to find only required dependencies. A JDK tool should be included to automatically check for module dependencies. Java IDEs should add support for finding dependencies and for running using only some modules. -X/-XX flags should be added to Java VM launcher to restrict used modules for testing/debugging reasons. A big warning should be added on Class.forName() and ClassLoader in documentation for possible problems.

This defaults will simplify average developers life, but empower smart developers.

CONCLUSION:

It will add some complexity to the Java platform, but Java could be in better position to fight against current or emergent web technologies like flash, .NET, even DHTML. Also java could be used in an increased user base.

More developers could use java to develop applets because the user experience would be better.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

> he/she will simply go other site/company. If you want
> your clients to see your super functional web page,
> to see your pretty applet, to check your perfect Java
> Web Startable application, you need something fast,
> FAST AND RESPONSIBLE!.
Well, the 7mb need to be downloaded ONCE - much less than an IE6 update needs for example and just a bit more than FireFox' or opera's download size are.
I don't know what fast and responsible has to do with the ide of removing classes out of the standard-j2se distribution.
In fact NOTHING, since the jre only loades really use classes.

Furthermore the idea of unbundling classes from j2se would leave 2 ways open:
* Ship the optional packages with your application/applet -> This would especially kill speed of applets and would lead to a lot of code which is in each application in different versions.
* Download components on demand: Well, I am in doubt you user wants to be online every time he launches another java program just because java needs to re-assemble itself.

> More developers could use java to develop applets
> because the user experience would be better.
These developers can use Java already for applets and webstart applications and this is really done, since starting with more complex applications flash/dhtml can't compete at all with java - dhtml does still not provide something compareable to Applets or webstart.
For computers with 1ghz cpu's java already starts quite fast - its up and running in 5-10s.

lg Clemens

cowwoc
Offline
Joined: 2003-08-24
Points: 0

One should *never* bundle optional components with an application as part of some native installer. This is equivilent to having a private JRE and results in multiple instances of the same components getting installed over and over again. This is the very thing we're trying to get away from.

When I state developers can choose to bundle optional components with their applications, I mean the following:

1) For physical shipments (CDs) it makes sense for you to ship a JRE + optional components with your application.

2) For online installs, it never makes sense to do this. At worse, you configure your application (see JNLP files) to eagerly fetch its dependencies. This will immediately download any dependencies when your application is first installed. If a library is already installed it will not be downloaded a second time.

As for ending up with different versions of the same libraries on your machine: this is up to end-developers. To me it makes sense for applications to state: "I am compatible with library A versions 1.1.x ... you can keep on updating it until it goes up to 1.2+". So yeah, you'd end up with a whole slew of different applications depending upon different versions but again this is up to the developer. Some libraries guarantee backwards compatibility forever (such as the Java API) so you wouldn't have to place a version-limitation on your application. In other cases, the library owner guarantees backward compatibility only across minor version numbers. You'd act accordingly.

I think this is more to do with ensuring backwards compatibility than it does to do with download-on-demand. If anything, this would be an improvement of how Webstart already works -- but issue is somewhat off-topic of the current discussion.

Also note that the opposite is true: wouldn't it be cool if my application relies on dom4j and I know that they never break backwards compatibility and Java will ensure that my code always runs off the latest dom4j release? It would be very neat to have my code automatically update itself whenever possible.

Finally on the point of applets: if a user is willing to sit around for an applet to start up, he is obviously determined to see it. The majority of users I've talked to do not bother waiting. There is absolutely no point talking about how much more applets can do (relative to Flash) if no one bothers using them. This is the same reason OS/2 lost to Windows: usability should always come before technological "gee weez!" features.

I personally consider applets a lost cause. Flash starts up in less than one second. Applets take 5-10 seconds to load like you mentioned. And this isn't even the worst part. The big thing for me is that the majority of applets I hit online are broken (throw some exception) and Flash ones never are. I am not kidding here... over 80% of applets I've found online were broken. This is the prime reason for applets getting a bad name -- not their download time. One has to ask themselves: how come Flash is never broken (how do they ensure this)? And how can we do the same for applets? Also, it did not help that they used to hijack the keyboard focus. Do they still do that?

Gili

mthornton
Offline
Joined: 2003-06-10
Points: 0

The "Tour de France" web site uses a Flash application to show the gaps between riders. The view of this embedded in the "live" page keeps having to be kicked to get the data shown updated. Merely refresshing the page doesn't work. Instead you have to show the "Gap" information in a separate Window, and then some time later the embedded copy will update.
By contrast the Java applet used to show scores of matches in progress at Wimbledon worked flawlessly.

So, two high profile events and it is the Flash one which is broken.

mthornton
Offline
Joined: 2003-06-10
Points: 0

The broken bit on the TdF site has now disappeared. Perhaps someone has read my comment! :-)

jseltzer
Offline
Joined: 2003-06-12
Points: 0

Just so I understand. You see a problem with download size. 5 mb is okay but 15 mb is not. JSE 6 is not due out until Fall of '06 and later versions even further in the future. Do you really think we should be worrying about a download the size of 15 mb. In 2008 15 mb will download in the blink of an eye (well that's an exaggeration but you get the idea) if not faster for a majority of people connected to the internet. I hate comparisons to Flash. Flash is a one dimensional product. Java does so much more. At least add Flex, Macromedias rich client, when comparing java and Macromedia downloads.

Message was edited by: jseltzer

cowwoc
Offline
Joined: 2003-08-24
Points: 0

It is not true that by 2008 the majority of the people will be connected by broadband. Maybe in the US (even then, I think a lot of dial-up users will remain) but definately not in the rest of the world. As I stated before, over 75% of the world uses dial-up and there is no indication of this changing anytime soon in Europe, etc. Dial-up is here to stay for a long long time.

I am not saying 5MB is ok and 15MB is not. I'm saying 2-3MB is fine, 7MB is not (there is no 15MB). As a long-term broadband user you just don't get that the download time for 7MB is almost 40 minutes -- and that's not even including the application. That's insane! And yeah, 2-3MB is much better, because that's a 10-17 minute download.

As a user, I'd personally like to clock any download under 10 minutes but even 20 minutes is far more reasonable than an hour for the JRE + application.

When you're distributing freeware desktop software that runs on top of Java, there really is no possibility of distributing the JRE by CD or expecting users to have broadband. Most of your users tend to be poor.

The point here is that we're targeting home users, not companies with a big spending budget.

jseltzer
Offline
Joined: 2003-06-12
Points: 0

You're right. There are still a lot of dialup users around the world. I'm just not sure you'll get a lot of people to agree on what should be removed from the jre. It's been said that deprecated api's should be removed. If that's done then they'll be an uproar from developers with old code. They'll complain about having to rewrite it. Features you think are useless are counted on by others and they'll resent you forcing their users to download the pieces of the jre you're proposing to remove.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> Features you think are useless are counted on by others and they'll resent you forcing their users to download the pieces of the jre you're proposing to remove.

Operating systems and shipped CDs would contain the monolythic JRE so users we're not forcing users to download pieces of the JRE.

The only thing that changes is if a user doesn't already have a JRE he now has the option for download a minimal JRE which downloads-on-demand. It's his choice. You can still opt to download the minimal JRE + optional components bundled in one big package (equivilent to today's JRE) but this should be a choice, not manditory.

The all-in-one JRE makes a lot of sense for server-side applications or shipped CDs while the minimal JRE makes a lot of sense for desktop users downloading the JRE for the first time (especially for dial-up connections).

One usage does not proclude the other.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

I would also recommend to keep an eye on size, its really critical if your buissnes relies on downloaded software.

I would be much more happy to see more improvements of existing APIs (Swing, OpenGL and Direct3D java2d pipeline imrpovements, FASTER applet/jre startup time, less bugs, more bugs fixed, 2-phase compilation, JIT cache) the new apis withought any end.
What the hell is rhino integration good for and beanshell is planned. Thats 100% pure java software people could easily ship with their products!?

However Mustang looks promising, good work till now.

lg Clemens

sjasja
Offline
Joined: 2004-08-15
Points: 0

> I would be much more happy to see more improvements
> of existing APIs (Swing, OpenGL and Direct3D java2d
> pipeline imrpovements, FASTER applet/jre startup
> time, less bugs, more bugs fixed, 2-phase
> compilation, JIT cache) the new apis withought any
> end.

+1

Creating a reliable enough rt.jar-in-itsy-bitsy-downloads mechanism takes resources away from elsewhere. Which is why I for one would like to see some way of figuring out how much JRE size really matters in real life. Therefore my continued whining: "please, what are the numbers: for how many users is rt.jar size the show stopper".

For triage.

alexlamsl
Offline
Joined: 2004-09-02
Points: 0

Firstly - I don't think the majority of developers & users think Java is too big to download / deploy / install. And in fact it is quite the reverse - Java is really compact and logical in design compare with other major programming languages nowadays.

Secondly - and I think I will need to say this - when we mean developers & users we mean a huge group of people with suck wide variety that some people seriously need, for instance, JDBC but never ever CORBA (I'd have never imagined myself using the latter for years to come). So if the only argument you make for / against certain features is whether YOU use it or not, that's far from convincing from anyone's point of view.

An analogy would be a few people standing in an over-weighing lift and all of them claim each other as "worthless" hence should step out of the lift. That is just plainly selfish behaviour.

--------------------------------------

I reckon getting (latest stable release) Java pre-installed on the popular OSes would be a good move; it's not about the size primarily - it's about the fact that sometimes it's just impossible to obtain a copy of the software in an offline environment.