Skip to main content

Need for new deployment schemes

15 replies [Last post]
wadechandler
Offline
Joined: 2003-06-24
Points: 0

It would be really nice to be able to deploy the JRE without having to include everything. There are many packages which are not used in different applications that would be really nice to be able to leave out completely when packaging/embedding the JRE within an application. This would allow for much smaller applications. Basically, not everyone has highspeed internet, so to distribute some applictions online it's nearly impossible considering code size of the JRE now days.

It would be awesome for Sun to come up with a way to change the license and the build (break out the packages which can be in separate jars and other files into separate jars/other files) to allow for slimmed down versions of runtime deployments. I think the standard jre install or shared VM install should keep everything as to be available from web start and applications of this nature, but I still believe this is needed for embedding the runtime into other applications. Changing the license and distribution layout and file structure to allow developers to distribute exactly what they need from the Runtime would be a huge help.

All of the new packages that get added to the VM as standard classes should really be in their own lib as well. Maybe they should be included in the ext directory completely separate as to mitigate these issues. It simply is not a good thing to keep increasing the size of the "required" deployment especially considering some applications must include a copy of a VM directly because of the nature of what they may be doing or for their use case users may simply not be willing to install separate software Java Runtime (they uninstall it because they say they didn't install it, and only want your product installed) I realize that may sound crazy but it happens, and it's not about customer education either as there simply is a large percentage of people with very limited understanding of a computer and software, and they just will not get it for what ever reason, and it compromises the ability to distribute software and build on the platform in some cases due to customer complaints and lack of understanding or willingness to do so.

Thanks,

Wade

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
coxcu
Offline
Joined: 2003-06-11
Points: 0

Mike,

Can you give any further details about the Deployment Toolkit?

Who is working on it?
When will it be released?
Is there any version available now?

Thanks,
Curt

miker
Offline
Joined: 2006-01-06
Points: 0

Hey Curt,

Sorry, right now all I can tell you is that the deployment toolkit is one of our top priorities. (Turn's out I was sorta jumping the gun when I opened my big mouth before. ;-) )

Anyway, as soon as there is news I can share I'll get it posted.

Mike.

miker
Offline
Joined: 2006-01-06
Points: 0

Oddly enough, I've looked into the JavaComm issue before. I'll give you the same advice I gave then (literally):

http://forum.java.sun.com/thread.jspa?threadID=682630&messageID=4007361#...

Search the page for the post from

MikeR.

robilad
Offline
Joined: 2004-05-05
Points: 0

Sun is not going to get people to ship code licensed under Sun's proprietary licenses in large numbers. The distributors could have been doing so already in the past 10 years. They haven't - Flash won the distribution battle for interactive content engines a couple of years ago.

With Vista coming later this year, there is going to be one managed runtime platform on every new Windows PC, and it's not going to be a JVM, it will be Whidbey, Microsoft's CLR 2.0.

Every nth PC may have a second managed runtime platform, as well, depending on the success of Sun's marketing team. I recall that successful tactic from the past ... Remember Netscape Navigator vs Internet Explorer? That worked really well for Netscape's Navigator.

cheers,
dalibor topic

javakiddy
Offline
Joined: 2004-01-23
Points: 0

I don't think the battle between the JVM and CLR will be quite the same as Netscape vs IE. End users aren't really aware of these underlying software platforms, in the same way they are with applications.

Given the CLR/.Net's limited availability on non-Windows platforms, it is, at least for the foreseeable future, just another way to write Windows software. Java's main appeal - WORA - remains unchallenged.

robilad
Offline
Joined: 2004-05-05
Points: 0

WORA worked wonders to keep developers hooked on perl and tcl/tk in light of passable, well marketed, free-as-in-beer competition, i.e. Java. ;)

cheers,
dalibor topic

robilad
Offline
Joined: 2004-05-05
Points: 0

The JSR277 web site has not been updated in more than 6 months. There are no public mailing lists, no mailing list archives, no community participation in the drafts, no nothing at all, afaict.

Is JSR 277 dead, or does it just look that way?

cheers,
dalibor topic

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

This, admittedly empty, mailing list appears to be public.
https://jsr-277-eg.dev.java.net/servlets/SummarizeList?listName=users

robilad
Offline
Joined: 2004-05-05
Points: 0

Thanks! I'll add that to my bookmarks.

cheers,
dalibor topic

robilad
Offline
Joined: 2004-05-05
Points: 0

Sun will never do that, or let developers do that. They see Java as a platform, rather than as a tool, so Sun will not allow people to pick cherries, as that could break unrelated code. And beside, there is the binary compatiblity thing with legacy applications.

If Mark's right, than Sun's trying to move away from the 'one VM per application' model to a 'system VM' one. In that case, they will have to continue adding anything someone may need onto that system VM, there is no way around it, given that licensing changes are extremely unlikely.

cheers,
dalibor topic

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

To be honest, I have to admit that I was rather surprised to find that Java wasn't included in Google Pack. I would have thought that a distribution and update method like this, from a company with this kind of public profile and perception would have been just what Sun would kill for. I wonder were they even approached by Google about it?

Message was edited by: aidan_walsh

wwk_killer
Offline
Joined: 2004-07-07
Points: 0

Wade, what are you writing about is RFE 4267080
"break up rt.jar into downloadable-on-demand components to reduce jre size" -- 256 votes.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4267080

The reasons are mostly marketing. They afraid that end-user will see cryptic ClassNotFoundException on limited JRE and will think that Java is crap.

miker
Offline
Joined: 2006-01-06
Points: 0

We are doing several thing to try and improve deployment. To begin with, we are making every effort we can to convince system providers to install Java on every system they ship. Because of this, on many newer machines there is no need for your application to provide/install the JRE. It can simply use the system JRE that is already installed.

We are also working on a Deployment Toolkit. This toolkit will help standardize the way Java is deployed over the network. Some of the things the toolkit will allow is a reliable method to determine A) if a user has Java installed, and B) if so, what version. Another feature helps developers get the latest version of the JRE installed on their customers machine.

As to breaking up the JAR files, this has been considered in the past, and is reviewed often. Aside from the benefits you point out, it may offer performance benefits as well, so we are always evaluating this.

Unfortunately, changing the license as you've suggested isn't as simple as it seems. Sun is trying hard to get Java on every machine out there. One of our goals is that all systems will have Java installed and available to all users of the system. This model is better than the old model of different vendor applications installing a private copy of the JRE. For one thing, the old model lead to duplication. But the main thing Sun wants is for developers to be able to depend on the existance of Java. In order for that to work, we can't really allow users to pick and choose between the components Sun considers to be "Core" components.

Another feature we are working on is Java modules. These are intended to make application deployment much simpler, and to provide an extension mechanism that really works. If you are interested, the Java modules specification is being tracked under JSR 277.

Mike.

ewin
Offline
Joined: 2005-07-15
Points: 0

[i]We are doing several thing to try and improve deployment.[/i]

I just had my deployment shock of the year (wrote another forum entry about it a minute ago). Sun in their infinite wisdom no longer provides a JavaComm reference implementation for Windows for download. So for applications intended to do serial communication on Windows its GAME OVER. It doesn't matter any more if users need to deploy a small or large JRE. The user can't deploy the JavaComm extension any more, because it is not available.

What does that mean?

- Stop distribution of current application
- Recall shipping in progress
- Put off complaining customers who recently got a shipping, but can't get the required JavaComm implementation any more
- Rewrite application to use another serial communication API
- If necessary buy licenses, pay royalties for that new API
- Rewrite installation so application is deployed with an implementation of that other API
- Ship new version
- Apologize to customers
- Eat losses and live with bad reputation

So whatever you do to improve JRE installation, it doesn't matter and is useless if Sun does such blunder.

barin
Offline
Joined: 2005-10-27
Points: 0

If I understand your post correctly, I believe this is what you are looking for:

https://sdlcweb4d.sun.com/ECom/EComActionServlet/DownloadPage:~:com.sun....