Hi,
I used to put utility-jarfiles, which I use in projects, into the jre's x:\...\java\lib\ext folder.
Howerver, when updateing the JRE, I alway's have to move this utility.jar's from the previous JRE to the new JRE-folder.
Is there any way to avoid this?
I tried to put the files into the CLASSPATH environment variable but then, the java applications can't find them...
> Is there any way to avoid this?
Put them anywhere where you can find them.
> I tried to put the files into the CLASSPATH
> environment variable but then, the java applications
> can't find them...
Forget about the classpath and either use the -cp or -classpath flags of java and javac, or refer to the JARs from the Class-Path entry of your app's JAR's manifest. It makes sense that each of your apps has its own lib/ directory with only the JARs it needs anyway.
To avoid misunderstandings:
=======================
We have several apps (app1.jar, app2.jar, appx.jar) which make use of same utility1.jar, utility2.jar.
I want to put these utilityX.jar's centralised (e.g. folder on our server)
1) To be sure all applications use same utilityX.jar
2) When these utilityX.jar are changed, I only have to replace 1 jar-file
Up until now I used the ...\lib\ext folder from the JRE.
Sollution?
========
1) CLASSPATH environment
It seems that the 'CLASSPATH' environment variable is not a good alternative anymore.
2) JRE-ext-lib
Not a good option because of the JRE-updates
3) -CP parameter
I don't want to use it because of application roll-out probs.
4) Class-path entry
This seems to be a good sollution but: Can I add the full external classpath to it?
example:
Class-Path:
x:\jarfiles\utility1.jar
x:\jarfiles\itulity2.jar
...
5) Better alternative?
> To avoid misunderstandings:
> =======================
> We have several apps (app1.jar, app2.jar, appx.jar)
> which make use of same utility1.jar, utility2.jar.
> I want to put these utilityX.jar's centralised (e.g.
> folder on our server)
No you don't want to do that.
> 1) To be sure all applications use same utilityX.jar
Maybe some applications won't work with newer versions of the same libs...
> 2) When these utilityX.jar are changed, I only have
> to replace 1 jar-file
See above.
> Up until now I used the ...\lib\ext folder from the JRE.
>
> Sollution?
See my post.
> 1) CLASSPATH environment
> It seems that the 'CLASSPATH' environment variable is
> not a good alternative anymore.
As I said.
> 2) JRE-ext-lib
> Not a good option because of the JRE-updates
As I said.
> 3) -CP parameter
> I don't want to use it because of application
> roll-out probs.
You don't need that on roll-out.
> 4) Class-path entry
> This seems to be a good sollution but: Can I add the
> full external classpath to it?
Why not use a relative path and keep your apps actually deployable, if deployment is what you're worried about?
I strongly suggest to tread your apps as entirely separate entities without shared libs. The only argument for sharing JARs is "disk space", and that won't pull anymore since 15 years. The arguments against it are possible verison incompatibilities and leftovers if the last app that used a shared JAR is removed.
ok, I understand that I should to keep jar-files attached to my application itself. Surely the application would not suffer from changes of the utility-jars because they have their own version of it.
BUT...
What happens when, in time, 10 applications are using the utility.jar?
Because this utility.jar has changed also (new classes added) they probably use different versions of this utility.jar
Finally this results in different jar versions of the same jar-file loaded in the java-engine... would this not give any conflicts?
And what about applets which will retrieve the jar-file from the server?
BTW, I added the jarfiles to the Class-Path as follows:
Manifest-Version: 1.0
Main-Class: myHolidays.HolidayMenu
Class-Path: P:\java\utility1.jar
P:\java\utility1.jar
but the application still cannot find the jars.
Now I've tried to include the jar-files in the application.
The application-jarfile contains at root-level:
- application classes (in package folder)
- resource folder with some text-files
- image folder with images
- META-INF folder (with manifest-file)
- 2 utility- jars
the manifestfile contains following entry:
Manifest-Version: 1.0
Main-Class: myHolidays.HolidayMenu
Class-Path: utility1.jar
utility2.jar
Still the jar-files are not found when I execute the application.
==> I start the application by a double-click on the application-jar-file.
> What happens when, in time, 10 applications are using
> the utility.jar?
Nothing.
> Because this utility.jar has changed also (new
> classes added) they probably use different versions
> of this utility.jar
Yes.
> Finally this results in different jar versions of the
> same jar-file loaded in the java-engine... would this
> not give any conflicts?
Huh? Only if you run all applications in the same JVM instance. If at all. I don't know whether each one would have its own classloaders.
> And what about applets which will retrieve the
> jar-file from the server?
What about them? You have to refer to the specific JAR anyway.
> BTW, I added the jarfiles to the Class-Path as
> follows:
> Manifest-Version: 1.0
> Main-Class: myHolidays.HolidayMenu
> Class-Path: P:\java\utility1.jar
> P:\java\utility1.jar
>
> but the application still cannot find the jars.
How do you execute it? And what's the second P:\java\utility1.jar there for?
Found the following sollution:
All the applications are stored (jarfiles) in following net_folder:
==> x:\java_apps
All utility-jars are stored in subfolder of this net_folder:
==> x:\java_apps\utils
Manifestfile of application contains link to this folder:
==> Class-Path: utils/utility1.jar utils/utility2.jar
Now the applications use same utility_jars which are stored on 1 location without the problem of moving thes files when updating JRE.
It seems that the Class-Path entry starts from the folder where the application-jars are. It doesn't help giving the full path (e.g. x:\tools\util1.jar)
Big advantages of this (IMHO):
- 1 place to store util-jars
- all apps use same util-jar
- application-jar much smaller (doesn't contain each utility.jar)
any comments on this?
> Now the applications use same utility_jars which are
> stored on 1 location without the problem of moving
> thes files when updating JRE.
In that case, you could have just as well used the system classpath.
> It seems that the Class-Path entry starts from the
> folder where the application-jars are. It doesn't
> help giving the full path (e.g. x:\tools\util1.jar)
I told you to use relative paths, didn't I?
> Big advantages of this (IMHO):
> - 1 place to store util-jars
Again, not an advantage.
> - all apps use same util-jar
Again, not an advantage.
> - application-jar much smaller (doesn't contain each utility.jar)
JARs are never supposed to contain any other JARs.
> any comments on this?
Yes. Many.
And what do you do if you remove an application? Do you start guessing which app used which JAR? How do you resolve version clashes?
ok, first I would like to tell that i'm not an experienced java developer. Therefore it is possible that there are better way's to do things...
1) Using system-class path
I think you refer here to the ...\lib\ext folder?
I didn't wanted to use this because we have to move the utility.jar's each time the user updates his JRE.
Using the CLASSPATH environment variable was told to be 'not preferrable'
2) relative paths
Indeed you told me but I didn't know how to 'code' this in the manifest-file.
3) Advantages / deployment
my first attempts to refer to the utility.jar's didn't work, therefore I tried to include the jar's into the application.jar (which didn't work either).
How do you deploy applications then?
Do they all have their own folder, containing subfolders with utility.jar's?
This is what I do:
- Create application
- Create application.jar (classes+images+other resources+manifestfile)
- Copy this application.jar into 1 net_folder accessible by users
Users can double_click the application.jar to start the application.
maybe there is a better way and I would really like to hear about this.
> 1) Using system-class path
> I think you refer here to the ...\lib\ext folder?
I refered to the system's classpath variable.
> Using the CLASSPATH environment variable was told to
> be 'not preferrable'
Yes, indeed. But what you're doing is just "doing away with the classpath variable, but keeping the same problems".
> How do you deploy applications then?
By handing out the application JAR and the required libaries.
> Do they all have their own folder, containing
> subfolders with utility.jar's?
Usually yes.
> Users can double_click the application.jar to start the application.
Not that great an idea, to execute JARs from web folders. ClassLoading will be very slow. Maybe you want to have a look at Webstart.
Webstart is a deployment mechanism that loads application to the client. Those applications then can either be run using a socalled Application Manager, or simply by clicking on an URL, or, after the application was downloaded by Webstart, using a desktop link.
Webstart also automatically checks for updated versions of the JARs used.
Java Desktop Apps
Firstly, this topic is about deploying for Desktop Apps. The net-folder i was referring to was a netfolder on our local network. We have a fileserver on which we put the java_apps. The users have access to this application_folder and can start their applications from that folder.
Java Web Apps
I know the existance of WebStart and have done some tests with it. I plan to use it for applications which will be access through a web browser. (in stead of using applets)
thanks for your info, i will surely take your comments in mind. I agree that there could be some problems with versions, removing apps,... but on the other hand, the utility.jar's I'm referring to are self written classes which we use to access db, convert things etc. These files will very regularly be refreshed, updated, corrected and we do not wan't to have different 'versions' around. When a class is updated, we want the updated class be used by ALL the applications which uses this class.
Probably, when more applications are written and the util_jar's are not changing again and again, we can consider about having each application it's own utility.jar versions.
