Submitted On 22-JUL-2001
walpj
Still a problem as of JRE 1.4. We really need a mechanism
for incremental updates of the client-side JRE.
Submitted On 24-JUL-2001
jezuch
Thet's an excellent idea. When I saw that 1.4 will be ANOTHER few MB's larger than 1.3 I thought that there
are definitely too many "goodies" in it. Is there anybody who uses more than 25% of SDK's classes? I would
rather see SDK as a collection of core classes necessary to run any program - which could be extended by
lots of optional packages just plugged in it - like copying into jre/lib/ext folder.
Submitted On 24-JUL-2001
walpj
Today, developers code and test for a specific JRE
version. The custom installer (or incremental update
method) must not break that testing scheme. In other
words, we're not talking about mixing JREs.
There is a pressing need for better support of the Java 2
platform for bandwidth-constrained users. Both Netscape
Navigator 4.x and Internet Explorer 5.5- came with a
bundled VM that supported JRE 1.1 (with mixed success).
And both of those browsers supported Java 2 using Sun's
plug-in. However, both Netscape 6 and Internet Explorer
for Windows XP rely solely on Sun's Plug-in for Java applet
support. While (last time I checked) the latest plug-in is
bundled with the "complete installation" of Netscape 6,
Microsoft has declined to include [i]any[/i] VM with the
Windows XP release of Internet Explorer.
Personally, I'm glad to see a compelling reason for users
to migrate to the Java 2 plug-in, which includes Swing, 2D,
Drag-and-drop, etc.
But the only way for a dialup user to get JRE 1.3 would be
to use a utility like Netscape's SmartDownload. Otherwise,
the 5+ megabyte download could easily become an exercise in
frustration.
That's why O'Reilly publishing is calling for OEMs to pre-
install the JRE.
http://www.oreilly.com/news/jvm_0701.html
But this doesn't address upgrading. An end user shouldn't
have to download the entire JRE to upgrade from 1.3 to 1.4.
Note that there are two options. A custom installer (as
envisioned in this RFE) or a method for incremental
upgrades to the JRE (as I advocate).
A custom installer (as envisioned by this RFE) would result
in a partial JRE being installed on the client and requires
some bookkeeping to keep track of the currently installed
components---similar to the way browsers handle
signed "language packs" for downloadable foreign language
support. It also requires a perpetually available
repository of platform components. And it raises the
question of how an [i]offline[/i] JRE would respond when it
doesn't have all of the required components.
Whereas I propose including with each JRE release
a "service pack" for the previous JRE that would include
all changes and [i]hopefully[/i] be considerably smaller.
Submitted On 24-JUL-2001
walpj
The custom installer functionality could perhaps be
provided by starting with the Web Start codebase. Minimal
Web Start jar management functionality could be bundled
with a minimal set of classes and the HotSpot VM. All
other classes in the platform could be housed in a set of
jars (similar to Windows cab files) and hosted by Sun.
Those jars would then be managed by Web Start in much the
same way that it manages regular application jars.
Basically, you'd be using a variant of Web Start to
bootstrap the install and to manage various partial JRE
installations.
This is just a flight of fancy. Sun has gone to great
lengths to maintain consistency in the platform resources
available to an app. That strategy even hurt them in the
embedded market due the platform initially requiring too
large of a memory footprint. But perhaps they're more
flexible today.
Also, this would be a lot to ask from Sun when its Java
development personnel are rightly focusing most effort on
server-side and development tool improvements.
Submitted On 24-JUL-2001
jezuch
Again me - of course the same thing is about JRE, not only SDK :)
Submitted On 25-JUL-2001
wangi
The whole JRE/Plugin installation issue needs further
thought... Currently Applets are tied to a specific JRE
version, and if a new version has been released they do not
get redirected onto downloading it. In some situations this
would be desirable. See
http://developer.java.sun.com/developer/bugParade/bugs/44798
73.html for more thoughts.
Submitted On 25-JUL-2001
traxone
Java WebStart rules ! so why not extend this to the JDK !
Submitted On 26-JUL-2001
walpj
Java developers in Usenet newsgroups have raised the issue
of platform bloat due to the necessity of "growing"
multiple JREs on the client. While that seems necessary in
order to avoid instabilities, I've heard that there's some
work being done in the area of class versioning to support
dynamic class loading for development tools. While JAR-
resolution versioning is good enough for applets and Web
Start (JWS) apps, the storage footprint of the platform
might be reduced considerably by class-resolution
versioning. Does anyone have more info?
Users of JWS have brough up several issues that would be
applicable if Sun incorporated JWS into the J2SE client
installation. Most importantly, a cache maintenance API
would be necessary so that multiple JNLP clients could use
the same cache---thereby eventually reducing the burdon on
Sun by opening the market to competing cache management
tools and JRE implementations. Details can be found in
Gerald Bauer's JWS 2.0 petition.
http://www.geocities.com/vamp201/king.html
Allow me to reiterate that there are at least two options
for improving support for bandwidth-constrained users.
Incorporating JWS technology into the J2SE installation
utility significantly changes the longterm strategy for how
Sun plans to maintain it's client-side JREs and introduces
daunting security issues.
However, a "service pack" that copies unchanged components
from a previous JRE installation and installs new
components would be a much less complicated short-term
solution. But it wouldn't decrease the download time for
the initial plug-in installation.
(-grin- But either solution might impact unpublished
agreements that Sun has with installation utility vendors.
Call me paranoid.)
Submitted On 26-JUL-2001
Blue27
We desperately need some sort of real life working device
to replace the Java in Internet Explorer under Windows XP.
Simple client deployment is cruicial, and no real world
solutions exists when Microsoft is backing from Java.
Where is Sun when we need them? Have you abandoned applet
developers? I am aware you have some alternatives, but I am
sorry to say they are not working in the real world, and
unfortunately they cannot replace the gaping void Microsoft
is creating by pulling out from Java.
Take a look here for more details:
http://forum.java.sun.com/thread.jsp?forum=32&thread=149700
Submitted On 27-JUL-2001
ssdanner
The most users want to do is 1) download a SMALL plugin or
2) have it already loaded onto their machine. That's it.
That's your choices. User's don't really care if the source
code is written in java, C#, or French; they are only
interested in the presentation.
Unless, one of the two above is accomplished, I predict
java's demise (yea, it will be around for years, but
popularity will decrease as XP installations increase).
Of course, if when XP comes out it stumbles along like a
town drunk, falling down every few steps, then it'll be a
longer; note that it won't die, it'll just take longer to
come around.
Keep in mind that most machines are not purchased for
development; they are purchased by users not developers...
AND users do not care. Users drive PC hardware/OS sales.
Almost all PC vendors fly the Microsoft flag. When XP comes
out, there will be a short lag, and (if the economy starts
doing a little turnaround by then) people will buy. Why?
Because most people are afraid of being left behind so they
will upgrade. People are always buying new machines, and
they'll most times take the OS that's the default install,
which will be XP. And even if it sucks, they'll just work
with it and complain (don't we all).
However, people will download what they need. Most people,
if there browser responds "you need to download xyx plugin
to view this page" will do it if the see the message on
enough sites.
The plugin is the computer.
(ok, you're right, that was probably stupid)
Submitted On 27-JUL-2001
mreha
Please support this feature!!! With Microsoft's recent behavior this is a must feature....now!
Submitted On 27-JUL-2001
sbockelman777
I don't know how critical to SUN's strategy applets on home
users PCs are. I know that applets are a nice tool in an
intranet environment and in that environment, it's the IT
Admin staff's issue. So, they can either preload the JRE
and/upgrade maintain the JRE as users need it. Also,
corporate users tend to have enough bandwidth and
connection speeds to download 5 MBs with ease.
Maybe a push for consumers to get better connectivity
and/or bandwidth would be a more worthwhile grassroots
effort. If home users had some compelling reason to get
better access, then...
So, what I am saying is, I doubt SUN will address this as a
serious issue anytime soon, but they should. In the
meantime, we, as developers, should do what we can to
create some other changes. Can we come up with something
so compelling that everyone will simply have to get DSL,
cable modems, ISDN, or even their own person T1???
Submitted On 28-JUL-2001
joecosby
I'm definitely in favor of a -transparent-, incremental
upgrade system.
Personally, I don't think the upgrade is too bad all
around. If you compare it to the upgrades for any other
client-side doohicky, realplayer upgrades or internet
explorer upgrades, it's not too bad. I've done it from the
client side, and it's just a question of one button click
and waiting through a 5 meg download.
I definitely think though that incremental upgrades should
be part of the system, and should be automatic.
Submitted On 01-AUG-2001
jaizone
Sun needs to enhance the Java Webstart technology so that
it ONLY downloads the necessary software/classes to be able
to recognize and download further required classes. The
initial install must be dial-up friend, i.e. < 2MB. As
long as a user is not required to go to special download
sites and re-boot or reset their browsers, they will deal
with using applets. But if the installation process is too
involved then they will avoid websites with applets. Give
us a smaller JRE and enhance the Webstart technology.
Submitted On 02-AUG-2001
6tr6tr
I believe the key lies in two technologies already existing:
1. Macromedia's Flash plug-in
This plug in is small and installs on demand. The
installation is quick, painless and user-friendly. For
about 1 minute of the users time, an entire run-time is
installed in the browser.
2. Java Web-Start.
Web Start offers two potential benefits. First, with the
increasing use of cable, broadband, DSL and T-1's,
downloading a runtime over the internet is increasingly
easy and common. Microsoft itself does this for all of its
updates to the OS now.
Secondly, Web-Start brings the idea of JIT/on-demand
install to the picture. Why not create an API for making
apps that come partially compiled, and only with the JRE
components it needs. Then when a feature in the app is used
for the first time, it will prompt the user to download the
few additional pieces needed (from web or CD or disk). this
is similar to the feature in Microsoft office products
where you can install only part of a program until you need
it.
Submitted On 03-AUG-2001
walpj
In the following topic, I elaborate on the consequences of
integrating Web Start technology into the client-side JRE.
http://forum.java.sun.com/thread.jsp?forum=25&thread=156163
Submitted On 08-AUG-2001
swhiteside
Please add this - if only to make the upcoming Windows XP situation easier.
Submitted On 21-AUG-2001
goask
I think Java Plugin should only contain a the core api and
any extensions that requires native code(java media, 3d,
etc). All other pure java extensions can be later downloaded
and installed as an extension(jre/lib/ext). That way the
size of download will be greatly reduced)
Submitted On 23-AUG-2001
haric
To reply BLUE's comment....
very lately...sun wanted to rise from west if not from East.
Check this...
http://news.cnet.com/news/0-1003-200-6932013.html
Life still remains same even if XP or IE 6 comes....
Submitted On 10-SEP-2001
jbjoness
This is excellent--one better is to produce exe's at will.
I know sun can do this. Why does nobody want to have the
humility to learn Microsoft's tricks? They're geeks, but
they're winning!!!!
1) Make it easy to deploy small Java apps on any OS
2) Allow developers to distribute JUST an exec with a few
DLL's, not all the bloat code you're so proud of.
2) Quit holding on to your fuzzy teddybear of a deployment
scheme and make it FLAT OUT EASY for any developer to
develop and deploy stuff written in your language. Doing
so, you'll rule the world. If you don't, MS will do to Sun
what they've done to everybody else--take your strengths
for themselves; use your pride and egotism to strangle you.
Submitted On 16-SEP-2001
javawindows
I definitively would like to see a solution to the
deployment problem.
Calling it a problem is in fact an understatement, the fact
is that the recent JREs are now completely useless to me
because of the huge size it adds to my program download.
We need a smart linker removing all classes and all DLLs
that are not necessary to the deployed program! Without
this Java is not an alternative on the client.
Submitted On 18-SEP-2001
bsheepw
i'm just 5 min away to GIVE UP java applet at all!!!!
Submitted On 25-SEP-2001
abies
Let's suppose that you have your magic linker. Supposing
that you don't have any dynamic code loaded (as it might
possibly call some pieces which are not present), for normal
swing application you _might_ be able to cut maybe half of
stuff. This means instead of downloading 8MB JRE and 2MB
application, user has to download 6MB combo app. Is it
really so big difference ? And the problem is that if he
EVER wants to use second java app, he will have to download
another 6MB instead of extra 2MB (or smaller). Not to
mention small applets - 5 10kb applets taking 5x
(0.1+4)MB=20MB instead of (0.1)x5 + 8M = 8.5M.
Only real point here is easy of deployment - which is
partially solved by webstart. Bundling cutted jre with your
applets/applications will not make downloads any smaller.
Submitted On 31-OCT-2001
cdbennett
Yes! This is a Good Thing.
Submitted On 06-NOV-2001
ccerberus
User "abies" (above) is right. Stop thinking of Java as
just a language. It is a PLATFORM. Microsoft doesn't let
applications install just the parts of the OS that they
need at the moment. You have to have a stable, known-to-
the-application set of facilities that you can GUARANTEE
are present if you expect Java to operate as a cross-
platform solution. This RFE should be Closed, or a
different type of solution should be found (such as making
the entire Java Platform web-based (streaming parts as they
are needed)).
Submitted On 12-NOV-2001
walpj
In response to ccerberus, I think that abies wasn't arguing
against the RFE. Rather, abies suggested that the linker
proposed by jbjoness and javawindows would not improve web-
based Java app deployment.
The RFE is about a creating a better way to deploy the
JRE. In comments above, I sketched a couple of proposals,
neither of which involves a new "smart linker". Also, in a
recent Java Live discussion [1], Sherman Dickman solicits
comments regarding supporting incremental installation for
the JRE.
[1]
Java Live: JavaTM 2, Standard Edition, v 1.4, Beta 2
http://developer.java.sun.com/developer/community/chat/JavaL
ive/2001/jl0925.html
Submitted On 02-DEC-2001
adamsdd
I think Web Start was a great idea for client side.
In a web browser things should be light, and the Java plugin
is a heavyweight approach to a lightweight problem.
A major problem with the plugin is start up time. While
Micro$oft's old plugin started quick, Sun's causes the
system freeze before an applet starts. The loading of
applets should be seamless with html.
Submitted On 23-DEC-2001
abies
walpj - you have understood me correctly. I think that nice
JRE/JDK installer with add/remove/update functionality with
medium glanularity would be very good. Updates would be
easier/faster and could be done incrementally. But I'm not
a big fan of bundling stripped down jre in a single package
with application.
Submitted On 31-JAN-2002
jessh
It would seem a fine-grained file-by-file binary diff based
patch update process is potentially required (with all the
diffs to be applied JAR'ed up into and wrapped with an
applicator program). That would basically minimize the
amount of downloaded data and effort to upgrade to a new
JRE about as much as possible.
Unless/until a corruption occurs this would seem fine and
ideal. It could be a "Upgrade..." button in the Java Plug-
In and/or Start Menu on Windows that would launch a
separate upgrade downloader/applicator app.
Submitted On 08-FEB-2002
paul_bailey
Why does this have no evaluation?
Submitted On 18-FEB-2002
walpj
In response to paul_bailey, unfortunately, this isn't a
forum through which you're likely to get a response to your
question. You could, perhaps, submit a bug stating that
this bug ought to be evaluated, but the Developer
Connection website recommends [1] e-mailing the appropriate
working group. I suggest submitting your request to
jre-comments@java.sun.com
and
java-plugin-feedback@sun.com
and maybe also the spec lead for tangentially related JSRs
such as the application installation JSR
http://www.jcp.org/jsr/detail/38.jsp
and the application isolation JSR
http://www.jcp.org/jsr/detail/121.jsp
.
[1]
http://java.sun.com/mail/index.html
Submitted On 20-FEB-2002
javajunior
ditto
Submitted On 21-FEB-2002
paul_bailey
did it.
Submitted On 25-FEB-2002
walpj
Here's one issue that applies to either incremental update
scheme. Say that a user chooses to upgrade from a
hypothetical JRE 1.4 to a hypothetical JRE 1.4.1 or to a
hypothetical JRE 1.5. Say that the user had installed an
optional package such as Java Media Framework (JMF) to
augment the 1.4 JRE. Will the update tranfer the JMF
optional package? Or will it prompt the user to search for
the latest JMF version . . . or to search for diffs of JMF
to update to the latest JMF version. . . ?
Submitted On 25-FEB-2002
walpj
An installer with add/remove/update capability would be an
impressive addition to the client-side JRE. But in the
event either that this enhancement is incompatible with
Sun's vision or that this enhancement is too complicated to
tackle at this time, here's some speculation about another
option.
In a recent Java Live interview [1], Hans Muller stated
that Sun is actively exploring various Internet
distribution schemes, with some emphasis on streaming the
JRE installation file. Above, ccerberus mentions streaming
the JRE as well. Perhaps the best solution would be to
stream compressed binary diffs (per the recent comment by
jessh) of platform files or to stream compressed binary
diffs of platform installation files. Undoubtedly, some
people would take issue with using diffs of installation
files, because that requires users to store previous
installation files. But in todays world of multi-gig
storage, that doesn't seem critical to me. Likewise,
applying diffs to multiple platform files could generate
more HD activity.
[1]
http://developer.java.sun.com/developer/community/chat/JavaL
ive/2001/jl1030.html
Submitted On 26-FEB-2002
jessh
The evaluation comments do not appear to address the pain
of upgrading from one JRE version to another. I still
don't see what's wrong with an archive of binary diff
patches in this regard...
Submitted On 26-FEB-2002
walpj
For historical purposes, I note that the first evaluation
was added today.
Submitted On 27-FEB-2002
walpj
I wonder whether Sun's JRE license would allow a third
party to develop /and charge/ for a diff-based incremental
upgrade solution for Sun's Win32 JREs.
If so, I wonder whether any corporate entity would pay for
this distribution solution. I suspect that the provider
would have to have supplemental revenue streams in order to
compete with CD distribution for . . . say . . . dial-up
corporate intranet application distribution.
If no one will pay for it, then perhaps Sun is wise to wait
for broadband ubiquity or a killer game or a killer
communication app to push JRE upgrades onto mainstream
PCs. Regardless, this response is very disappointing to
those of us who would like to take advantage of the latest
JRE features in a Web Start app without abandoning the huge
number of dial-up AOL, Bluelight, Mindspring, Netzero, etc.
users out there.
Submitted On 21-MAY-2002
JustAnotherProgramer
needs to be easier for people who have no knowledge of
programming at all!
Submitted On 20-JUN-2002
pepeio
what is that windows specific solution you are 'looking
into' ???
The solution i think about is to install a dependency tree
of the jre components on the client side, analyse the code
that has to be run, and install only needed classes if they
are not already present. The dependency tree can be prepared
with a class analysis tool, this is not rocket science.
The installed jre by default will only get the minimum
classes to do the runtime analysis job and download the
needed components. I expect only a small part of the overall
JRE to be used. That would make a jre install very light,
and would help all of us.
Submitted On 01-NOV-2002
jpersson1
Comment to pepeio.
I could write code that would do that dependency analysis on
my own, but the problem is that Sun's license prohibits me
from bundling such a shrinked JRE together with my code, or
am I missing something here?
Submitted On 19-DEC-2002
wwk_killer
Comment to jpersson1
"but the problem is that Sun's license prohibits me
from bundling such a shrinked JRE together with my code, or
am I missing something here?"
Yes, if this is your tool.
No, if this would be Sun's tool.
The reason for Sun license is that customer should not expect
any irritation because of lack of some Sun classes. So they
require to install the whole JRE.
Would this tool be correct, this will not be needed. However,
Class.forName() usage (for jdbc odbc bridge, for ex.) makes
this tool vulnerable.
The solution is packaging. If I am server-side Java developer,
why should I have AWT+Swing polluting my system???
Optional (never used) packages I currently have:
com.sun.accessibility; com.sun.corba; com.sun.media;
com.sun.rmi & java.rmi; javax.swing; javax.sound; javax.print;
javax.imageio.
Somebody will not need XML stuff, somebody -- network etc.
Submitted On 17-JUL-2003
walpj
The Java Update patch feature mentioned by Stanley Ho in a
recent Java Live session [1] and detailed in a recent
technical article [2] looks like a good solution. According to
the article, it updates the JRE incrementally to the next so-
called dot-dot release. According to the 1.4.2 release notes,
it's not included yet [3]. Maybe it'll be rolled out with
behemoth 1.5. As soon as it's rolled out, I'll remove my vote
from this RFE.
[1]
http://developer.java.sun.com/developer/community/chat/Jav
aLive/2003/jl0429.html
[2]
http://java.sun.com/j2se/5.5.5/docs/javaupdate-win-nt-me-
98.html
[3]
http://java.sun.com/j2se/1.4.2/relnotes.html#update
Submitted On 01-AUG-2003
antony_miguel
As a (quick?) fix, why not allow users to distribute a modified
rt.jar? The license could even prohibit doing anything but
removing class files?
Submitted On 21-APR-2004
cowwoc
Note to evaluators: the key here isn't that end-users should
be able to incrementally update their JVMs. That is all nice
and good, but most users don't even understand what a JVM is.
The key here is to enable app-developers to deploy their
applications on remote machines using a minimal JVM
(includes Java Webstart + minimal subset of classes) and
then have that JVM auto-download further JVM classes
on-demand as the app uses it.
Either make "embedded JVMs" smaller (by removing legal
restrictions for stripping classes out of rt.jar) or make
JWS smarter by having it download JVM classes on-demand for
its JWS-enabled-clients.
Submitted On 20-JUL-2004
cowwoc
Recommended approach: subdivide one package per JAR file. When Java Webstart runs and it is missing a core class, it requests the entire package JAR from Sun's servers and continues execution. This strikes a balance between download size and execution speed.
Submitted On 09-AUG-2004
princec
Unfortunately Java Web Start is a vast, sprawling application that drags in a ton of classes from all over the whole JRE. JWS will need to be reimplemented as a native application if this is going to work.
Cas :)
Submitted On 06-SEP-2004
cowwoc
If Java Webstart must be rewritten as a native component, so be it. Personally I suspect it is possible to keep JWS written in Java, strip away all the classes it does not use and ship a package in under 2MB. It is feasible; Sun just needs to test it on their end.
Feel free to contact me for more information on how this can be done.
Submitted On 11-JAN-2005
El_Karel
If SUN does not provide a quick solution to ease the installation of JRE will be a big lost in the market for them, at least in the Desktop field giving way to ActiveX and Flash solutions.
Submitted On 08-APR-2005
jay.johansen
I see some comments here that if an app was deployed with only those components of the JVM that it needed, that this would create problems if the user installed a second app that required different components. This assumes that all apps should share a JVM, which sounds like a very efficient and economical thing to do, but in practice causes major headaches: I'm seriously thinking of changing my organization's installs to each install their own JVM. We've now had several cases where we installed a JVM with one of our apps that turned out to be incompatible with another app the user was running that required an older JVM (no, Java is not 100% upward-compatible), and just a few weeks ago we got burned when users deployed Java 5 on top of our 1.4 and there was an incompatibility that blew our app away. Even if I have to install a full 30MB or whatever it is now JVM, in today's environment 30MB is worth what, about 3 cents? If that saves a user 5 minutes in problem resolution time it's well worth it. So sure, for a user with a hundred Java apps, a shared JVM is wonderful. But for the typical user who might have two Java apps on his machine, there should be a way to easily install only those components of the JVM that that an app requires. Our biggest deployment headache has been trying to instruct users how to install Java in addition to installing our app, and that's just loony. The whole thing should be seemless -- there's no reason why an end-user should have to even know what Java is. When I buy a car I don't have to buy the engine separately and install it myself.
Submitted On 27-APR-2005
wwk_killer
To jay.johansen: separate JRE for the app is just developer's / build manager's task. Many application currently ship with local JRE, it is known technics.
I was very impressed in negative way how new Java 5 ("very compatible", of course) immediately broken JBoss [WonderLand] 3.2.3 because of JMX 1.2 that cannot be easily detached. Final solution was to remove javax/management/* from rt.jar, not useful, or wait when I can switch to newest.
I see that many Sun Java Developers understand this fact -- separate 8Mb charsets.jar is EXCELLENT thing.
My proposal it to split 37Mb (12600 classes) of rt.jar into ~5 smaller: Core, Desktop (I NEVER used Font capabilities), Server (now com.sun.rowset is present on every machine of end user of Swing!), Advanced (sql, transaction, xml, security -- +whole javax?).
I understand that having default Desktop (+JWS, +Advanced) install (with single license screen) for end-users is a must. But there are other users -- having a customized installer with choices would be a respect to them!
Submitted On 27-APR-2005
wwk_killer
Or, let's call only "core Java" as "limited Java", and "advanced Java" as "Java".
Good overview of "areas" is image on
http://java.sun.com/j2se/1.5.0/docs/index.html
and text below mentioning Base Libraries / Integration Libraries / UI Libraries.
Submitted On 01-MAY-2005
pmuurray@bigpond.com
So perhaps we might think about a WebStartClassLoader ? You could have a distribution of the JRE where the system class path has a instance of WebStartClassLoader that points to a place where these other packages are located.
walpj - there's nothing stopping you from writing this yourself, you know.
as to princec's comment: writing a classloader that can talk JNLP is not the same thing as having to have the webstart application present.
Submitted On 27-MAY-2005
jay.johansen
to wwk_killer: Ah, I guess my post was unclear. I wasn't suggesting private JRE's with the thought that this was some radical new concept that I was claiming to have invented. Rather, what I intended to say was: Sun has been saying that they are reluctant to implement partial installs of the runtime library because if classes are omitted just because app #1 didn't need them, and the user then installs app #2 that does need them, app #2 will not work. (No doubt causing the user to ridicule Sun rather than the programmer who set up the partial install, and thus bringing unjust criticism on them.) My reply to this is that that is a plausible argument against installing a partial library as a "public JVM", but it does not apply to a private JVM, which by definition is not supposed to be used by any other app. If they want to include some feature that would tie such a private JVM to a specific app so that a user would at least be warned if he attempted to use it with another app, that might be a good idea. But I bet a JVM that included only those packages used by a particular app would typically be 25% or less of the full runtime library.
Submitted On 02-JUN-2005
lu.timdale
I think it goes even deeper than trying to have a couple of separate jars. .Net is very well organized and allows for multiple version of the same library to reside on the same machine.
Java should have a similar type of scheme. For example, all xml files should be included in one separate package. This would include packages from
org.xml.sax.*.*
org.w3c.dom.*.*
javax.xml.*.*
Chances are if you are using classes from one, you will use the others. The same thing applies to other categories.
Desktop APIs would include packages
javax.swing.*.*
java.applet
java.awt.*.*
In fact, I managed to make a comprehensive list of J2SE packages.... they are in the next post.
This organization would be beneficial due to:
- having more granularity for easier upgrades/downloads
- should allow multiple versions of the same library
- javadoc organized the same way would focus developer on appropriate section ... current situation with packages is not manageable
I hope this happens for the next release as the longer this is put off, the larger the problem will be.
Submitted On 02-JUN-2005
lu.timdale
Core -----
java.beans
.beancontext
java.lang
.annotation
.instrument
.management
.ref
.reflect
java.math
java.util
.logging
.prefs
Desktop -----
java.applet
java.awt
.color
.datatransfer
.dnd
.event
.font
.geom
.im
.im.spi
.image
.renderable
.print
javax.swing
.border
.colorchooser
.event
.filechooser
.plaf
.basic
.metal
.multi
.synth
.table
.tree
.undo
javax.accessibility
javax.print
.attribute
.standard
.event
Multimedia -----
javax.sound.midi
.spi
javax.sound.sampled
.spi
javax.imageio
.event
.metadata
.plugins.bmp
.plugins.jpeg
.spi
.stream
IO -----
java.io
java.nio
.channels
.spi
.charset
.spi
Network -----
java.net
javax.net
.ssl
Database -----
java.sql
javax.sql
.rowset
.serial
.spi
Security -----
java.security
.acl
.cert
.interfaces
.spec
javax.crypto
.interfaces
.spec
javax.security.auth
.callback
.kerberos
.login
.spi
.x500
javax.security.cert
javax.security.sasl
org.ietf.jgss
XML -----
javax.xml
.datatype
.namespace
.parsers
.transform
.transform.dom
.transform.sax
.transform.stream
.validation
.xpath
org.w3c.dom
.bootstrap
.events
.ls
org.xml.sax
.ext
.helpers
Threading -----
java.util.concurrent
.atomic
.locks
Compression -----
java.util.jar
java.util.zip
Text -----
java.text
java.util.regex
javax.swing.text
.html
.html.parser
.rtf
Remoting -----
java.rmi
.activation
.dgc
.registry
.server
javax.rmi
.CORBA
.ssl
org.omg.CORBA
.CORBA_2_3
.CORBA_2_3.portable
.CORBA.DynAnyPackage
.CORBA.ORBPackage
.CORBA.portable
.CORBA.TypeCodePackage
.CosNaming
.NamingContextExtPackage
.NamingContextPackage
.Dynamic
.DynamicAny
.DynAnyFactoryPackage
.DynAnyPackage
.IOP
.IOP.CodecFactoryPackage
.IOP.CodecPackage
.Messaging
.PortableInterceptor
.ORBInitInfoPackage
.PortableServer
.CurrentPackage
.POAManagerPackage
.POAPackage
.portable
.ServantLocatorPackage
.SendingContext
.stub.java.rmi
javax.activity
Transactions -----
javax.transaction
.xa
Naming & Directory -----
javax.naming
.directory
.event
.ldap
.spi
Management -----
javax.management
.loading
.modelmbean
.monitor
.openmbean
.relation
.remote
.remote.rmi
.timer
Submitted On 19-JUN-2005
sjasja
Let's pick a random hard disk. Hitachi Deskstar 80 GiB, retails at US $60. Hardly the best space/price ratio you can find either.
In JDK 1.5.0, rt.jar is about 35 MB. That's about 0.04% of the drive's capacity.
Which translates to 2.6 cents US in disk price.
You could split rt.jar into pieces, getting only the parts you absolutely need. But you'd be saving a couple of cents at most. You'll be unlikely to be earning even a hundredth of minimum wage for the work you put in it, and for any work caused by missing classes.
If you want to help modem users: at least here, starting a dialup connection costs money (connect fees) and takes time. Having to download rt.jar in bits and pieces would be expensive and time consuming.
Static analysis is not sufficient for finding class dependencies. The moment a program does Class.forName(
Submitted On 19-JUN-2005
sjasja
(...continued from previous...)
Static analysis is not sufficient for finding class dependencies. The moment a program does Class.forName("com.foo.SomeJdbcDriver") static analysis fails miserably.
A mix-and-match rt.jar would be a versioning nightmare. Hmm, does 6.44.23 of Vector work with 9.123.701 of HttpSession and 8.8.312-beta of XmlWhatever... Soon you'd be running a mix of classes that nobody else on this planet has, and nobody has ever tested that combination.
Splitting rt.jar has advantages. But there is a good chance the disadvantages would far outweigh the rather small advantages.
Submitted On 18-JUL-2005
lu.timdale
The whole point is that Java does not have a good dependence mechanism.... .Net does. What is being done to address this?
Obviously installing all of the latest relevant libraries will happen when you install the JRE.
There is a concept of API compatibility, but sun takes it too far, and so far has not broken it yet (even though it does actually break due to bug fixes)... this doesn't work long term. Actually, wasn't AWT rewritten in 1.1 to have a better event handling mechanism? Didn't this break all 1.0 apps?
Look at gnome, you have the libraries for each major revision and the latest sub versions which maintain API compatibility.
When you have an application that demands a specific version of a library, why would each of the applications that demands it have to have that library installed? Where is the concept of reuse?
Let's look at the current way to handle changes:
- old code: marking code as deprecated
- changed code: fixing bugs for the same API which oftentimes changes the way that API is expected to function
- new code: usually in a new package so as to not interfere with existing
This is very clumsy way to handle it. Why can't we have one runtime that supports all the latest bytecodes, but have multiple versions of core libraries?
What if all reused libraries were in a central location and could accomodate multiple versions of the same library? Isn't that the dream? Why should we putz around with classpaths.... I should just be able to say I want this version of this library.
"DLL Hell" applies to java apps too. The larger and older the JDK, the more of a problem it is.
Submitted On 28-OCT-2005
kensystem
rt.jar *clearly* does need to be broken into pieces. --Just to load a simple and run a simple main() class that only references a few java.lang classes, requires loading (reading rt.jar from disk) an entire slew of libs that are uneeded... Not just once, but repeatedly, even in the same VM instance (below).
You can see this rt.jar disk IO as being the majority of startup cost, by watching your disk activity the first time the JVM inits. And the second time a VM is started, where you *wont* see that disk activity *is only courtesy* of the OS's disk/memory cache. YET - if enough other memory intensive process are running on the native OS, the disk-cache of rt.jar eventually gets discarded or put into swap... so after a period of non-use of the VM, subsequent VM instantiations (or even just class loads from rt.jar by a running VM) will cause re-read of rt.jar from disk.
Put another way, an EXCELLENT analogy could be, to describe this current rt.jat monolith design, as java having to "boot up", because it *has to* preload(*) a bunch of libs whether or not they will be used, just as an OS does (largely in a strategic attempt to optimize preffered app's startup times (example, .NET, and even the Mac JVM ;-) ).
Compare this with post-boot loading of an app, where only the needed libraries (discrete files) are called (or already in memory) ---- much faster load times (obviously).
*technically the JVM isn't "preloading" them per-se - its relying the the OS disk cache to act in this fashion - this is reduced to an extent in the shared-data system that 5.0 uses, yet it still seems to 'open' rt.jar, slowing things down.
There are just too many things in rt.jar that will not be used in any given apps's runtime context (not to mention WAV files!, PNG images!, corba!, etc); they should be separated into dll/shared-oject style JARs and loaded in context sensitive fashion. Version and/or trust concerns can be handled by adding standard jar manifests and signing (both of which which 1.4x rt.jar did not have, the later not existing 5.0, perhaps due to a circular dependency?).
I also offer the thought that the java Desktop / tray icon tool / background-process on windows should periodocally "reload" the most likely used libs from rt.jar, etc... it does not appear to do this right now - the result is that if any of its memory (including effective OS disk cache) is swapped to disk (as does happen on a typical client machine), subsequent invoations of applets, etc, wind up taking a very substantial amount of time.
Submitted On 30-NOV-2005
vinayak.koli
I want rt.jar which is less than 2 MB size for jre1.4 release i have rt.jar of size 23MB which is too large
is there any option to download rt.jar as per demand
if yes please notify me...
vinayakk@rapideffect.com
Submitted On 12-DEC-2005
mikaelstaldal
> If you want to help modem users: at least here, starting a
> dialup connection costs money (connect fees) and takes
> time. Having to download rt.jar in bits and pieces would
> be expensive and time consuming.
Perhaps you want to help 512 kbit/s ADSL and Cable users? They (usually) have flatrate, but it takes time to download 35 MB. If they only need JRE in order to run a 200 KB applet or JavaWebStart-deployed application, they might not consider it worthwhile if they have to spend time to download 35 MB JRE first. They will just consider Java as something big and time consuming, and demand that the applet/application is rewritten in Flash or as a native Windows app instead.
Submitted On 08-APR-2006
Anything you could do to reduce the startup time of the JVM
would be great.
Submitted On 19-AUG-2006
jdevp2
If Sun cares about Java on desktop, this should have been done long time ago. Large jre and no code protection are the two major factors that prevent Java from playing major part on desktop applications. After many years programming in Java, I'm walking away from it and starting programming in C++.
Submitted On 29-NOV-2006
jbbugeau
IMHO, simply "breaking JAR" is of no use. What would be a better mind is to simply stick the core to the Java Module way !
Here you can have separated modules like core lang, swing, corba, xml, ...
Modules will be downloaded from repository only when needed the first time. And upgraded on demand by application's descriptors or other module requirements.
As a resume, what we need is simply that JDK libraries (bytecode or native) themselves adhere to the http://jcp.org/en/jsr/detail?id=277 !
Please do not reinvent the wheel, java module should be the only central mechanism to provide upgrade and incremental upgrade, even for the VM it self !
This will put a high presure on the repository security (certpath validation and declarative permission will be required).
Submitted On 03-AUG-2007
This is pathetic -- 8 years and still no progress.
Submitted On 20-NOV-2007
When was this closed?
Submitted On 25-JAN-2008
verdyp
Looks like there should exist a smarter way to install a JRE than realying on the installation of a FULL jar file.
May be, you could implement new JAR functionalities, so that the core JAR will be reduced to the minimum, providing just a directory of components that are missing in it, and implemening a local proxy for getting them when needed from a reliable (and signed) source, so that the JAR itself gets updated dynamically. This would require changes in the clientVM's class loader so that it will resolve the list of needed classes, will inspect the local directory of the JAR, and will retreive the missing components to update the JAR. May be it could requore a new JAR file format, and extension to some metafile describing its "virtual" content for classes that can be updated at any time, but only on demand.
No need to support versioning: the same JAR will be updated only with components from the same full version of the JAR.
Something however makes such move not necessary (or this need being mitigated): there's now the need to update versions too, and if possible automatically. That's needed because there are critical security updates that should be fixed early, even before users notice the problem when running their prefered Java app. That's why we have now the Java update scheduler: when it runs, it may download nd install full versions, and then propose to the user to change the default version. It should also be able to record a user preference for uninstalling a previous version at the same time, once the new version installs successfully (this would avoid keeping many versions).
Note also that version updates still don't do anything to fix the existing extra libraries so that they are usable in the new version: those libraries have to be manually duplicated by the user, and it is hard to find and perform correctly. I think that, for this reason, the extension folder in the JRE should be really deprecated, and that each application that need their libraries hsould have their own JVM launcher to extend or fix the classpath as needed. Those applications could also register their use (or discontinued use) of a specific version of the JRE to help the JRE installer cleaning up things that are no longer needed. I've seen a customer's machine that had accumulated over time several dozens of installed version of the JRE, taking considerable space, with no easy way for the customer to determine which version was really used for the application he wanted to have support: he really through that he had performed the needed updates.
A JRE versions cleanup tool could be helpful, as well as recommandations for application developers so that they install their JRE in easily manageable ways: when people update Windows, they update it once and think that this is done after that.
Java could still support multiple versions, but only through a scheme similar to Microsoft's "Side-by-Side" system, where all installed versions are kept in a central repository, and can be cleaned up or reinstalled when needed. For now the "C:\progam files\Java" installation root is not enforced and we can find various JRE's installed in various locations (including for example the installation roots of their prefered web browsers, that often don't installa the JRE using the Sun's JRE installer, but using various tricks to change the settings, despite all what they install was from original Sun JRE's).
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
