On 0, Ola Lundqvist <[EMAIL PROTECTED]> wrote: > > I just noticed I mixed library references in Manifest files and Java > > extensions, but they are similar, and as far as I know them, they're not > > good. If anyone feels they're sufficient for our problems, please explain > > :-) > > I'm not very good at them. What is the differentce?
When you write in a manifest file: Class-Path: xalan.jar xerces.jar the JVM adds xalan.jar and xerces.jar to the class path before running the application. Both are in the same directory as the main file. Even Sun suggests using relative paths like 'lib/xalan.jar' when the library is in a different path - this is horrible, and unlikely to be portable! (http://java.sun.com/docs/books/tutorial/jar/basics/manifest.html). Still, this parameter is nice for applets where you want to provide several .JAR files instead of one huge one (e.g. when you use JDBC drivers). The extensions in Java 2 are more powerful. Unfortunately, the people at Sun have stopped when they finished the basics. Again, read http://java.sun.com/docs/books/tutorial/jar/basics/manifest.html for details. In short, every library provides its version in the manifest, and the name of its specification and the version of the specification - I couldn't find information what this is about. Maybe something like a 'Provides' line, but it seems you can only provide one in every library. In an application which requires the library, you can specify which library at which version you need (http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html) - and provide a download address. This whole thing seems to me very broken, like an idea of sales guys. It's focused on applets which automatically download required libraries when they start. You have to provide an URL to the implementation; I don't have to tell you what happens when the library moves. > It makes things easier to handle, yes. One though though. Is there > just a problem when two jars that contain the same thing is installed > or is it also problems when you load the wrong one? In fact, Xalan and any other XSLT processor won't really conflict; when you try it out, you will be able to load more than one library at the same time which implements TRAX; when you create a TransformerFactory object, you will get the one which comes first in the classpath. But still we should be very very careful. Imagine: lib A and B are in conflict (like the TRAX example with Xalan), but are in the same classpath because application C requires A, and library D (which is also loaded) requires B. lib A happens to comes first in classpath, before lib B. Now D thinks: well, B is installed in my classpath, now I'll use the ABJava API to create an object, and cast it into GreatObjectOfB - but surprise, surprise, ClassCastException, D did not call B's implementation, it called A's implementation without knowing it, and SillyObjectOfA was returned instead, which can't possibly casted into GreatObjectOfB. I'm not sure if this is too paranoid... Regards, Max
