[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary of the idéas.

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.
> >   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,


// Ola

 --------------------- 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 /

Reply to: