On Fri, Nov 09, 2001 at 06:19:52PM +0100, Max Kellermann wrote: > On 0, Ola Lundqvist <opal@debian.org> 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, I have now read this. Not very much of a documentation so I have some questions... :) The Class-Path:-thing. Is it per Name: (class) or per jar-file? > 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 s/me very broken/be an applet thing/; http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html seems to be the best entry point for this kind of documentation. I think we have to use this as the basic information for out java debs. At least we should make the use of it possible with proper manifest files. It is not the best solution but it is one solution that adresses some of the problems. But some things must be stated: * NO directories in the Class-Path: statement. Just the jar-file. Every jar must be in /usr/share/java so that should not be a problem. The jar name should be the one that it really depends on. We have a problem here that we can not say things like. Class-Path: xerces.jar (>= 1.0.3). So we should do like Class-Path: xerces-1.jar * The deb maintaner have to be the one responsible for the information in the mainfest file. We should of course use information provided by the upstream developer but the maintainer have to make sure that it follows the policy. * Maybe we should also use signing. I have to look this up further and see if it is possible to make a nice debhelper tool for that. :) If siginging is done by upstream it should not be replaced. The debian maintainer should only add its signatures. Well this is a start at least. I suggest that we allow some sort of wrapper for the java1 compliant virtual machines to adress the Class-Path thing. > 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. Everything seems to be an applet thing. But make it easier for applet developers we should adopt this too. We have to have an other solution around this though. I think. > > 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 got the point. > I'm not sure if this is too paranoid... Not too paranoid. But is this solvable at all? To me it seems unsolvable so let us not adress this too much. The alternative is to say: This kind of stuff does not work, so let us not even try (at program start). So what I say is that the extension mechanism and manifest file is not the solution. Rather something that we have to follow... We should then make a solution that complies with theese thoughts and also give all other extra featues that we need. Some debhelper tools should be very nice: * One that reads the manifest (or some other more general database) and give some dependency information. * One that sign jars (and such stuff). * One that fixes the manifest from some more general information. * One that takes the source and generates a dependency line. It should be possible. :) At least suggest some dependencies. Regards, // Ola > Regards, > Max > > > -- > To UNSUBSCRIBE, email to debian-java-request@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > -- --------------------- Ola Lundqvist --------------------------- / opal@debian.org Björnkärrsgatan 5 A.11 \ | opal@lysator.liu.se 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------
Attachment:
pgpP6EtnpnyY8.pgp
Description: PGP signature