On Wed, Sep 19, 2001 at 11:03:50AM +1000, Jeff Turner wrote: > > There have been quite lot of discussion about the classpaths... > > :) > > The only good classpath is a dea.. clean one.
Just curious what does dea stand for? :) > > > There are a couple of things that I have found that people think > > is good. > > > > * If the user specifies a classpath that one should override the > > "system classpath". But still the "system classpath" should be > > there if the user does not specify enough information. > > Okay, but by "override", I mean *really* override, not just mask. Don't > rely on later versions being strict supersets of earlier versions, > thereby "hiding" the old version, because if they're not, I think you'll > get sealing violations. Ok. The option should be there. I have two solutions. 1) Let the wrapper make a difference between $CLASSPATH and the argument -classpath. One of them (-classpath?) does a complete override, and the other one just mask. 2) Have two different wrappers. > > This can be done in the following way: > > /usr/bin/java (or similar) takes the $CLASSPATH and contacinates > > it with the "internal" classpath for the jvm. > > Like, CLASSPATH=$CLASSPATH:$INTERNALCLASSPATH before running > > the real jvm. > > This amounts to adding another layer to hide the old layer. Bits of the > old layer can show through and cause problems. Yes. But in this case we are talking about the jvm (java.*) classes so that should not be a big problem. But you are right that it might cause trouble if we define a set of standard (and external) packages, see below. > > * All jvm:s and java compilers must follow this structure. > > * Or is there any disadvantages with this? > > > > Dependencies: > > ------------- > > > > * Some sort of function should be there to get the classpath that > > a specific jar-file needs to run correctly. > > That would be nice. Perhaps just a text file listing required jars? Probably yes, but with a nice tool around that data. > Also consider that most programs' startup script has this info > implicitly. If the startup script handles everything including classpath > setup, what else is needed? Yes that is true. This just simplifies things and make it easier to handle (and build) libraries. > > * This tool should be implemented to help the developers and > > maintainers to create a good classpath before running the jvm. > > * It should also be possible to use it to create the necessary > > symbolic links, to for example tomcat. So it should probably > > spit out the jars that are needed, so you can do anything you > > want with them. > > > > Default classpath: > > ------------------ > > > > * This discusses the default classpath, except the classpath that > > are needed by the jvm. Should there be any such thing? > > Or rather, *can* any such thing exist without: > > - breaking non-packaged programs which assume a clean classpath. Well it depends on what packages that are in the default classpath. :) We can be _very_ restrictive about it. > - upsetting a lot of developers who like to make a clean-classpath > assumption. I think most Apache coders fall into this category, > because most (all?) Apache projects ignore the classpath, and use an > Ant properties file to find jars. Perhaps other Apache people <waves > to Marcus Crafter> can confirm/deny this. Well I object :) I have personally had to manually fix all classpaths personally. That is why I want a tool that fixes the classpath for me when I tell what jars that I directly need. :) But this have not much to do with a default classpath. I'm not sure if I like the idéa myself. But I can be convinced. But if the option to have a clean classpath exist this might(?) not be a problem, or? Regards, // Ola -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 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 / ---------------------------------------------------------------
