Skip to main content

Private JREs

17 replies [Last post]
abramsh
Offline
Joined: 2004-08-24

This has been brought up in separate threads, but each time the thread turns into some shoot-out over a specific license. I thought I'd re-address an issue I hope the new license chosen will allow for:

What I (and many others) would love to be able to do is to ship a private JRE, just as we do now, but remove pieces of the JRE that we do not use in our private case. For example, unused packages from rt.jar.

Keep in mind this is not 'forking' in two important ways:
1. It is a private JRE.
2. It is the 'official' JRE, only with the unused pieces stripped out.

Why hasn't this been allowed up until now? Will this be allowed in the OSS license? If so, will the license allow me to do so without the burden of shipping source/posting my changes to the JRE?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
dog
Offline
Joined: 2003-08-22

>
> The last JVM installed on a system automatically sets
> itself up as the default.
> That's the way the installers work...
>

No.. that's the way BAD installers work. Why on earth would an installer that is installing a component for only my app affect others..

Good installers allow many versions to coexist.. some may have the option of asking the user which one should be "default" (when such a concept is necessary). But component installers (as a "private" JVM would be) would not affect ANY global settings.. doing so is dumb!

>
> With a thousand "private" "JVM"s (they won't be, but
> they'll call themselves that) out there, each with
> its own limitations and classfile format (and
> language features, core libraries, etc. etc.) it's
> going to be a nightmare to support Java
> applications.

Absolutely not true.. its only trying to share what someone else installed that's a nightmare.

> Every time someone installs something else he'll also
> install a JVM incompatible with yours in some more or
> less subtle way.

so.. it shouldn't affect your app.. their JVM works for their app not yours.

>
> But maybe you're too young to have experienced the
> DLL Hell period of Windows 3.x (which is now starting
> to reappear under Linux with tons of conflicting
> shared libraries all trying to install themselves as
> the system default).

I'm not.. and it is precisely this unwanted/unnecessary sharing of DLLs (in this case JVMs) that cause these problems.

Originally DLLs served the following purposes (maybe not a complete list):
- Save disk space by allowing others to dynamically link to shared libraries
- Provide modularization so huge companies like Microsoft can share code between different groups

However, today:
- HDs are huge.. and who cares if you waste a couple of megs per app
- The hastle of trying to make your app work for all possible configurations is often not worth the trouble (we're starting to see this problem with shared JARs in open source projects)

So often it is easier to just setup your environment for your app and not be affected by other users.

Clearly I don't want my app to fail when another app installs JDK 1.6 and that doesn't work with my current software because its based on 1.5 (I've seen some apps that exhibit this behavior).

cowwoc
Offline
Joined: 2003-08-24

Frankly, the problem is that many Java applications under Windows are stupid. They incorrectly assume that java.exe in the path is the correct one to use. If the user has more than one JVM they are likely making the right choice. The correct approach, to my understanding, is to check the registry and pick up the newest JRE or alternatively prompt the user which one he'd like to use.

I still disagree with Sun's approach of dumping a stripped-down java.exe in c:\windows\system32. It causes a whole bunch of problems in its own right. Imagine what would happen if every single application decided to dump itself in that directory ;)

Anyway, back to the issue at hand, private JREs exist simply because for desktop application there is little else a sane developer can do. Most desktop users are not going to download 7MB on top of your 100k application. If Sun provided better alternatives (as outlined in a previous post) I'm sure no one would bother using private JREs because messing with them is a lot of headaches to begin with. I'd be more than happy to use a shared JRE which desktop users would be willing to download. Good luck if you think they'll download over 2MB because they won't :)

dog
Offline
Joined: 2003-08-22

> But I really believe Sun and others should do
> everything to stop people making private JREs. _Not_
> in legal ways, but in technical ways. Private JREs
> cause more problems (increased download size, many
> different dll problems, stopping portability,
> silently decreasing security, causing obscurity, ...)
> that they solve (knowing what JVM will be used - but
> not exactly what OS and other components). Making
> one, compatible, autoupgradable, easy to find and
> install (possibly bundled by default in OS) equiped
> with good tools (like JWS should be or better) JRE
> will hopefully make private JREs mania decrease...
>

I don't agree.. Microsoft has amply shown that you get into a load of trouble when different companies share DLLs (in this case JARs).

When I develop software I typically use 1 JVM and use 1 set of JARs. If and end user (say.. grandma) installs my software my software should use my JVM and my JARs for as long as that version of my software lasts.

It should continue to run perfectly even if grandma uninstalls JVMs, installs new versions, installs a bunch of extra JARs. Because my software should have its own private stuff that don't bug anybody else and isn't affected by others.

Global JARs are a bad idea.. so are global JVMs and global Dlls. This maybe would have worked if Sun had gotten the JVM installed on most popular OSes.. but since that isn't the case.. I'm for private JVMs.

That being said, for advanced apps (like IDEs, web apps and other server stuff) the user is an advanced user and may want to control what JVM to use. In those cases a shared JVM option is good.

abramsh
Offline
Joined: 2004-08-24

Private JREs are already allow, and I assume any new license will expand possibilities, not reduce them. There are many situations where a 'private' JRE is necessary or beneficial.

For example, what if I have a kiosk running an small linux kernel and a java app. By definition this is a private JRE because no one can run anything else on the machine. In that situation, I believe it would be beneficial for the new license to allow me to strip out things from the JRE that I will never need. Again, this isn't a fork; The same code that runs on the Kiosk will run on any 'standard' JRE. It's true that someone else's code may not run, but then again it would never have the opportunity to run on this kiosk.

The same holds true for desktop computers. I may depend on a specific version of the JRE, or the user may not even know I use the JRE. Many desktops lack the proper dependency mechanisms to convey the fact that my app is using a shared JRE, so the user could unknowingly break my app by changing the JRE in some way. I 100% agree that in a perfect world, in a desktop situation, that everyone Java app would use the user installed JRE, but in our current world that simple isn't workable in many situations.

Now for some replies:

>yes, the typical "noone needs it because we think they
>don't" mindset.

You've misunderstood. It's the "no-one needs it because I control who no-one is" mindset. This is a private JRE, so only my code runs on it, and I know what my code needs.

>In fact you hereby admit that you're in violation of the
>current license which explicitly states that the JRE may
>only be distributed in UNMODIFIED form, so not in your
>stripped variety.

No, this is not something I do currently, and to be clear there are a set of things you MAY MODIFY in the JRE if you are shipping it as a private JRE. It's all in the readme. I also want to be very clear that the company I work for is VERY sensitive to licenses which is why I'm asking for specific allowances.

>So it is forking. You're distributing something that's
>NOT Java yet you call it that, even telling your
>customers that it's Java you're distributing.

No, we are distributing something that is java with the dead code optimized out. We make not even be telling our customers we use java. To them, it is just an application that they double-click the desktop icon for or lives in their system tray.

>Quite simple. Your version will break code created by
>others.

As someone else pointed out, you've misunderstood. This is a private JRE, no one else's code can run on it. It may not even have a 'java' executable, just a native executable with the JVM linked in. This is all allowed currently; what I'm talking about is allowing the next step of removing 100% dead code from a private JRE.

>I'd still call it a fork too, even if it is a reduced version, precisely for the reason that it can no longer support the full API.

I guess we could argue about the definition of 'is' too, but the reason I feel it is not a fork is that it doesn't need to support the full API because what is removed can never be called. Also, my code can run on an unmodified JRE. I am not shipping it to others to use as their own JRE, just as a part of my runtime requirements.

Think of it this way; what if I use an open source C library that is static. I compile my code against the static library and my compiler only takes the code it needs for my application. Why is that bad? The same is true in this situation; If we think of rt.jar as a static library (because no one else can use it), then I am just optimizing out 100% dead code. Who does that hurt?

leouser
Offline
Joined: 2005-12-12

Isn't there a 'most used classes baked file' that the VM uses to load in the most frequently used classes? How does the system work with the baked file and the removed binaries, assuming you remove something that is baked?

leouser

abramsh
Offline
Joined: 2004-08-24

> Isn't there a 'most used classes baked file' that the
> VM uses to load in the most frequently used classes?
> How does the system work with the baked file and the
> e removed binaries, assuming you remove something
> that is baked?

From playing with a local copy, it appears that you can just remove the baked file and everything still works. I do not know how to regenerate the baked file, but I haven't really looked at this point since I'm not allowed to ship it like this anyway :)

cowwoc
Offline
Joined: 2003-08-24

I think people are getting worked up over nothing. There is a perfectly good solution which meets everyone's requirements, though it is a bit more complex to implement.

We need a 1-2MB JRE installer that unpacks the bare skeleton needed to run Java Webstart. You then extend Java Webstart to download JRE component on demand. Basic idea is that the JRE installs components on demand so it is still certified as Java (nothing is missing, it is just installed on demand) as well as meeting the demands of people not wanting to install more than they need.

If you are concerned about install times (over the network) or want a CD install you simply pre-package all the components you want with the JRE so they will get installed by default. You get the best of both worlds.

On the matter of version compatibility what you do is you apply the same version number to all components (such as core, AWT, Swing, Networking, etc) and synchronize their releases and testing *but* in between official releases you allow components to have independant release schedules for beta. So basically when an official release nears, each component "promotes" its latest stable build, you integrate all components and run a full-fledged test suite against the resulting integrated JDK.

What do you guys think?

Gili

abramsh
Offline
Joined: 2004-08-24

People often bring this up, and in the past, the guys (and gals) at Sun shoot it down for various reasons. I am for this idea, but not to address some the specific requirements I've talked about so far.

While I think this would help with the situations I've described, it wouldn't provide the optimal solution. For example, there will be components I need with APIs I do not. And for APIs I do need, there will be unneed symbol information that could be sacrificed to save space.

I'm not asking for the license to allow for me to redistribute the modified JRE as a shared JRE; just as a private JRE.

leouser
Offline
Joined: 2005-12-12

'I'm not asking for the license to allow for me to redistribute the modified JRE as a shared JRE; just as a private JRE'

You must be meaning something else, if you distribute a JRE you are sharing it.

leouser

abramsh
Offline
Joined: 2004-08-24

>> 'I'm not asking for the license to allow for me to
>> redistribute the modified JRE as a shared JRE; just
>> as a private JRE'
>
> You must be meaning something else, if you distribute
> a JRE you are sharing it.

Again, you've misunderstood. When I say a 'private JRE', I am speaking about the term defined in the JRE readme. A JRE that can only be used by a single application. A 'shared JRE' is one that is not private; one that can be used by multiple applications.

jwenting
Offline
Joined: 2003-12-02

> What I (and many others) would love to be able to do
> is to ship a private JRE, just as we do now, but
> remove pieces of the JRE that we do not use in our
> private case. For example, unused packages from
> rt.jar.
>
yes, the typical "noone needs it because we think they don't" mindset.

In fact you hereby admit that you're in violation of the current license which explicitly states that the JRE may only be distributed in UNMODIFIED form, so not in your stripped variety.

> Keep in mind this is not 'forking' in two important
> ways:
> 1. It is a private JRE.
> 2. It is the 'official' JRE, only with the unused
> pieces stripped out.
>
So it is forking. You're distributing something that's NOT Java yet you call it that, even telling your customers that it's Java you're distributing.

> Why hasn't this been allowed up until now? Will this
> be allowed in the OSS license? If so, will the
> license allow me to do so without the burden of
> shipping source/posting my changes to the JRE?

Quite simple. Your version will break code created by others.
Your customers will think they have a complete Java runtime when they don't, and when trying to use anything not written by you are liable to have crashes and blame the supplier of that other product and Sun rather than blame you, the person who supplied them that broken JRE.

You're an excellent reason to NEVER allow end users to modify the JRE, let alone the JDK, and ship it.

arooaroo
Offline
Joined: 2005-04-06

>
> In fact you hereby admit that you're in violation of
> the current license which explicitly states that the
> JRE may only be distributed in UNMODIFIED form, so
> not in your stripped variety.
>

I don't think there was an admission. He was stating something appears to be a common wish, which is to trim a private JRE.

> > Keep in mind this is not 'forking' in two
> important
> > ways:
> > 1. It is a private JRE.
> > 2. It is the 'official' JRE, only with the unused
> > pieces stripped out.
> >
> So it is forking. You're distributing something
> that's NOT Java yet you call it that, even telling
> your customers that it's Java you're distributing.
>

I'd still call it a fork too, even if it is a reduced version, precisely for the reason that it can no longer support the full API.

> > Why hasn't this been allowed up until now? Will
> this
> > be allowed in the OSS license? If so, will the
> > license allow me to do so without the burden of
> > shipping source/posting my changes to the JRE?
>
> Quite simple. Your version will break code created by
> others.
> Your customers will think they have a complete Java
> runtime when they don't, and when trying to use
> anything not written by you are liable to have
> crashes and blame the supplier of that other product
> and Sun rather than blame you, the person who
> supplied them that broken JRE.

I you're misunderstanding the poster. If I ship an app with a bundled JRE, then this JRE does not interfere with any other copies of the JRE: either other private copies or globally installed versions. So I don't think this would lead to the apocolyptic view that you predict.

jwenting
Offline
Joined: 2003-12-02

>
> I you're misunderstanding the poster. If I ship an
> app with a bundled JRE, then this JRE does not
> interfere with any other copies of the JRE: either
> other private copies or globally installed versions.
> So I don't think this would lead to the apocolyptic
> view that you predict.

The last JVM installed on a system automatically sets itself up as the default.
That's the way the installers work...

Sure you can override that if you know what you're doing, but most end users don't know (and none should be expected to know) and will therefore get in trouble.

With a thousand "private" "JVM"s (they won't be, but they'll call themselves that) out there, each with its own limitations and classfile format (and language features, core libraries, etc. etc.) it's going to be a nightmare to support Java applications.
Every time someone installs something else he'll also install a JVM incompatible with yours in some more or less subtle way.

But maybe you're too young to have experienced the DLL Hell period of Windows 3.x (which is now starting to reappear under Linux with tons of conflicting shared libraries all trying to install themselves as the system default).

abramsh
Offline
Joined: 2004-08-24

> The last JVM installed on a system automatically sets
> itself up as the default.
> That's the way the installers work...

That may be the way the Sun installer works, but that is not how a private JRE installer works. It is a completely hidden JRE. You probably have some on your machine right now and don't even know it.

gkulewski
Offline
Joined: 2006-08-17

Hi,

IANAL.

I think Sun should make most part of Java (especially system library and possibly VM too) completly free as in BSD revised license.

I also think that license should *allow* forks because this is the essence of opensource. Also the license should not prohibit GPL integration because it will make many Linux (and not only Linux) users suffer. But of course the license should not be GPL becasue it will make BSD people suffer and will make everybody release their source code and probably market isn't ready for that (yet?)... :)

Only thing that should be absolutelly prohibited is claiming that incompatible fork (= one that does not pass compatibility tests) is Java and making it for example open java executable files by deafult on some OSes. This of course is not against people that will test and even distribute incompatible Java enhancements for tests but against big business organisations that could try to break integrity of Java.

But in my opinion it should not be prohibited by license but by Java logo and trademark guideliness that should state clearly what could be named Java and what could not.

I personally don't believe anybody will be trying to attack Java by making bad forks. MS has .NET already and has probably way bigger problems than Java.

But I really believe Sun and others should do everything to stop people making private JREs. _Not_ in legal ways, but in technical ways. Private JREs cause more problems (increased download size, many different dll problems, stopping portability, silently decreasing security, causing obscurity, ...) that they solve (knowing what JVM will be used - but not exactly what OS and other components). Making one, compatible, autoupgradable, easy to find and install (possibly bundled by default in OS) equiped with good tools (like JWS should be or better) JRE will hopefully make private JREs mania decrease...

GK

mstevens
Offline
Joined: 2006-08-24

I agree that sun should stop people making private JREs. And I think I agree with what you're saying, but I wanted to clarify...

I think the way to stop it is by making the standard JRE so much more tempting, rather than putting obstacles in the way of people making their own.

jwenting
Offline
Joined: 2003-12-02

> I agree that sun should stop people making private
> JREs. And I think I agree with what you're saying,
> but I wanted to clarify...
>
Quite the reverse. If people want to mess up their internal environment by hacking the JRE into something that doesn't work with the standard that's their own problem.
What I don't want is people to distribute those hacks to the world, getting their own users (those unwary of the hacks) to get what they think is a JRE but isn't.