Our customer wants us to ship his application with an embedded JVM. We tried to convince him otherwise but had no luck.
Now, here is the way we are contemplating taking. We want to take the Apache Harmony VM and libraries. We would then strip everything we don't need and ship the application with the bare minimum in terms of libraries.
My questions are thus:
1) Where can I find detailled explanations about the functionality provided by the different libraries (natives and classes) coming with a JVM?
2) How can i know if a JVM library file is needed or not?
I know the questions are a bit convoluted, but i hope somebody out there have done something similar.
Regards,
Gregoire.
It looks like you can also distribute the Sun JDK if you do not modify anything (I would consult a lawyer to be sure).
Whichever way you go I would not prune anything, that would make it more complicated if and when you needed to upgrade the client's software.
The problem is not the license of Sun/Oracle, they allow redistribution of the Java Runtime Environment, so developers can embed it into their application installation packages.
However, the problem is export regulations. By law, you may not export parts of the JRE to certain countries, so you would have to check whether your customers are in the allowed list of countries before they can download your application package which includes the JRE. This for example applies to such things as the Java Cryptography.
Use a Sun JVM embedded within your application and start it with the invocation API. That way you could save some more diskspace :) IBM has an example source code how to start the JVM.
Try launch4j to bundle the JVM with your application and save some work.
Related
DISCLAIMER: I'm relatively new to Linux. I debated putting this on SuperUser or ServerFault because the answer does require an explanation of Linux as a system (and not a specific programming problem), however I'm interested in this from a Java developer's perspective, and I argue that this is a specific problem because where I install GlassFish greatly impacts my Java configuration, and ultimately, app configuration. Not to mention posting this question on those other sites probably won't garnish any attention from a Java developer, more over system admins, who may not know enough about Java to weigh-in fully on this decision.
I'm trying to decide where to install GlassFish and it seems to me I have (realistically) 4 viable options:
/opt/glassfish/
/usr/local/glassfish/
/home/myUsers/glassfish/ (which is what all the OGS docs show in their examples)
/home/ogs/glassfish (as its own user, similar to how Apache web server is sometimes setup)
I'm wondering what the pros (taking into consideration the nature of how Linux treats these directories differently, the FHS, etc.) and cons of each approach are.
I've read that there are mounting/paritioning benefits to installing it under opt/. However, I normally install 3rd party software to usr/local/, so I'm a little unsure about that as a strategy.
The Oracle GlassFish Server (OGS) docs all demonstrate (but never outright recommend) GlassFish being installed under your home directory (home/myUser/).
Then again, I've read that it is fairly common to install daemon-type services (which is what I would imagine I would be using GlassFish as - where I start it once and it only comes down for routine maintenance or crashes) as their own user (home/ogs/glassfish/).
I'm sure this decision is also impacted by how I'm going to use GlassFish, so let me qualify this question with a few constraints:
I intend to deploy 4 OGS instances across 4 VMs on the same physical machine and cluster them into the same domain (1 of the 4 server instances will be the admin server for the domain)
Several applications will be deployed to this cluster (all 3 non-admin nodes) at the same time, and should be running 24/7/365 except for when they crash (hopefully not often!) or when I need to maintenance or tune them
Each application will be farily large and I would like to configure them with real admin, not "bare bones" de minimis, default settings
If these don't provide specific-enough information to help make this choice, please ask and I can be more specific.
I guess, when the dust settles at the end of the day, I'm looking (more or less) for a matrix with each of the four directory options (plus any other obvious ones I've omitted) compared against their respective pros & cons.
There's also the option of using your Linux distro's package management system to install Glassfish. On Ubuntu for example, you could install it using
sudo apt-get install glassfish-appserv
and let it get installed to wherever the package owner thought it should be installed.
I myself tend to steer away from the above option, as I like to exert my own control over which exact version of Glassfish (or any other Java server/software) is installed and where, but I just wanted to throw that out there, as it's one of the things you could do.
Now for the individual options you've provided:
/opt/glassfish/
This is the preferred option as far as I'm concerned. It keeps the software on a separate directory outside of the regular Linux installation, and allows the mounting and partitioning benefits you mention.
/usr/local/glassfish/
I don't like this much, because /usr/local is generally used by third-party software that is installed using the distro's package management software (apt/yum/etc), and on most distros has directories like bin, etc and lib under it. Putting a directory for glassfish under it, would make it out of place.
Also I prefer to keep system directories separate from custom software that doesn't use the distro's package management tools.
/home/myUsers/glassfish/ , /home/ogs/glassfish
These 2, I would not recommend.
They are only described in most places, because the author doesn't want to assume that the user has root access on those boxes, in which case the home directory would be the only one you'd be guaranteed to own. If you own the system and are managing it, those restrictions don't apply.
Remember, home directories are for specific users. I always recommend server software being managed with individual users' accounts that have the required privileges. Putting software in someone's home directory would mean that you either
Give everyone who needs to manage Glassfish, the password to that user account
Give multiple users read/write access to the home directory of a specific user.
Either way, that's not good system administration policy.
There's not much of a Java perspective here, but if you ask me, there doesn't need to be.
Regarding the prior recommendation, some tradeoffs remain:
If placed in /opt or /usr/local, you will have to have read/write access to those directories, meaning that you will have to have root access to the box. In some environments (where IT controls the platform), IT will not let you have root access. You would have to delegate to IT the responsibility of installing, patching, and upgrading the GlassFish binaries.
If placed in /opt or /usr/local, then you will also have to place the domain directories (--domaindir) in a separate location unless you want them owned by root (unlikely). This was the default in GlassFish 2.x RPM installs on Linux. GlassFish 3.x does not have RPM installs (from Oracle, anyway), but you can still split the two. This isn't a bad tradeoff, but something you should understand.
If placed in a "home directory", then you have rights to upgrade the core binaries, install patches, etc, separate from IT. There is good/bad/ugly in this approach depending on organizational responsibilities.
Hope this helps.
I'm looking for advice on good options to deploy Java applications on end user systems.
Our end users are not tech savvy experts but casual computer users who can't be expected to figure out directories and version conflicts.
Runnable jar is not practical because we need to provide VM parameters. Batch files are not practical because for whatever reason, java.exe is not on the $PATH in a huge amount of Windows system.
Webstart is an option, but our users commonly complain that no shortcuts are created (a feature that's apparently broken), every click on the website prompts a new download, and a plethora of other issues make this option seem incredibly unprofessional to the end user.
Many of the things one finds when googleing for Java deployments are themselves built with Java, which means they won't run either on a system with a missing or broken Java installation.
If you do not want to spend any money, a popular solution is izpack.
If you're looking for a commercially supported solution, there is install4j (Disclaimer: My company develops install4j). The installer is a Java application here as well. However, it is started by a native launcher that can download a JRE bundle from your server on the fly. You can also statically bundle a private JRE. See here for more information on JRE bundles.
Webstart is an option, but our users commonly complain that no shortcuts are created (a feature that's apparently broken), every click on the website prompts a new download, and a plethora of other issues make this option seem incredibly unprofessional to the end user.
Many webstart deployments are quite unprofessional. Make sure any deployment that is showing problems is validated using JaNeLA. For the shortcuts specifically, look into the IntegrationService of the JNLP API for establishing them after launch, with feed-back.
Ultimately though, APIs will have bugs. If you find one in web start, please report it on the bug database (v. broken at the moment, but you have to try).
Many of the things one finds when googleing for Java deployments are themselves built with Java, which means they won't run either on a system with a missing or broken Java installation.
As to missing or too low version Java, use deployJava.js to ensure a suitable JRE is present. No ideas on the broken installs.
I doubt you will swing back to JWS for this immediate deployment, but please investigate it according to the ideas outlined above, for future use.
I worked on a Java project in which web services are used, values are to be modified in registry and there are some DLLs to be register with system. there are some environment variables to set, at the time of installation, keeping in mind these requirements , which Java installer is best, i also need a installer which is platform independent as my Java project is platform independent.
I think i may use IzPack
but i think you guys can help me better and suggest me an installer.
If a commercial product is an option, you could take a look at install4j, but I can't say anything about it.
IzPack seems to be the only open source Java installer that's still being actively developed. I've recently used it myself, and it has a lot of powerful features, but is not easy to get started with. There's a lot of documentation that describes some things in great detail, but unfortunately no simple "how to" for the most common case. Expect to spend a lot of time on trial-and-error.
I would use IzPack, its a great tool which bundles your installer in a jar. platform independent and with the possibility to only use some routines when special conditions a present. For example, only install DLL on Windows, mess with the registry (Custom Action) and so on.
I always enjoyed using IzPack and suggest you should give it a try.
The doc is also a great resource for the possibilities Doc
I am working on a java based application and we are looking to ease our deployment of updates. Up until now, we've always simply sent out new install packs & had the sysadmin's on our customer sites roll out the upgrades - painful for a large number of users.
what I'd like to do is something similar to java webstart (or eclipse p2) - when the application starts, it checks for updates in a specified location and then downloads the updates prior to starting.
But here's my problem - I want more control over what's done outside of the scope of plugins & jar files. For example:
I'd like to be able to upate my JVM (we ship a modified version with additional security features).
I need to install DLL's - possibly local to the jar files, sometimes to windows
Occasiontally run MSI's to install windows components (e.g. printer drivers).
I need to modify config files & the registry.
I have found a few applications that support this (such as AppLifeUpdate at http://www.kineticjump.com/) but they tend to be .NET focused and it seems a bit perverse to introduce a .NET dependancy on a java application ;)
I know I could write my own here, but if there is already a 3rd party library out there that supports this kind of facility, then it would make my life a lot easier.
So, has anyone else had a similar problem & knows of some products I could look at?
Thanks, Brian.
I have done similar things but on Linux/Unix, so can't suggest any specific products for Windows. But I always found helpful to either package everything in OS format and distribute everything that way (rpms, debian pkg, Solaris pkg, ...) or have the platform deployed through OS mechanisms and have the application deployed through Java mechanism (Web start).
The reason is that sysadmins typically don't like things that magically update themselves without them knowing or in a way that does not follow standard practices. That is: you can't expect to make your life easier if you are not sure that you are not making their life more difficult...
Also: whatever work I do at the OS level, I do it with OS tools. If on Windows it means using .NET, I would very much consider using that...
Hope this helps!
I authored a Java freeware (closed source) product that I deploy on a web host and distribute via JNLP, inclusive Linux clients.
I plan to suggest this product for inclusion into several Linux distro, if possible "as is" (JNLP-based).
Can I already contact distros, or I need to reconfigure something (deploy on another host, convert JNLP to something, etc.)? What is your experience?
I would say that a freeware JNLP application is pretty much the opposite of what Linux distributions would tend to include.
Firstly, JNLP will not work with the native package management solution. If you wanted to get an application included in a distribution it would need to be package in the native format and updated in the standard way.
Secondly, most distributions will favour open source packages and many will not include non open source packages in their default repositories. Some distributions may have specical non-free repositories. Up until OpenJDK you may not even Java itself would be in these repositories.
In my opinion you would be better trying to build a user base on your own as you then have complete control over releases etc.
Generally Linux distros aren't very interested in things they can't integrate into their release schedules. Since JNLP allows you to deploy a new version at any time, they can't do a version freeze before release. This will exclude you from most distros - Debian even removed Adobe's flash plugin for this very reason, and if they'll remove Flash, don't expect them to make exceptions for a less well known application.
If you're willing to distribute it as just a plain .jar, you might be able to get it in - for debian, you'll want to read the Debian New Maintainer's Guide and Debian Policy on how to package things, submit an ITP (intent to package), upload a package, then seek sponsorship on the debian-mentors mailing list. More info can be found at the Debian mentors FAQ. Packages submitted to Debian will also make their way into Ubuntu in due course.
Other distributions will have different policies, of course; if in doubt, check their faqs, or ask on an appropriate mailing list for the distro in question.
Figure out a way to package it properly on each of the platforms you want to include your software on, and prepare for rigid software management (freezing, multiple versions etc if you want the code included in the standard installation.
Otherwise you may be able to create a simple package just containing the link to the JNLP page which may be included in the non-core parts. It is worth a try.
What applcation are we talking about?
Java programs tend to be very difficult to package and maintain. Therefore guidelines vary from distro to distro. So you should have a look at the specific guidelines for some popular distros first.
In addition to that: Everything that updates itself independently from the package manager can be real pain for the user and maintainer of the package so you should consider a different distribution model for inclusion in linux distros.