On Wed, Jan 02, 2002 at 09:35:25AM -0800, Ian Clarke wrote:
> On Wed, Jan 02, 2002 at 11:53:18AM +0100, Oskar Sandberg wrote:
> > I don't like it at all. I like having the java code in it's own module
> > so that I can check it out directly into my java tree - otherwise you
> > have to mess with symlinks (I'm on a mission of finding whoever started
> > the practice of setting the classpath variable explicitely for every
> > single java package installed and removing their medulla oblongata
> > through their eyesockets with a rusty hedgecutter).
> 
> Hmmm, well you may not like it, but it is increasingly standard
> practice, and not dissimilar to the way that new software is added to
> operating systems like Plan 9, it also works more nicely for .jar files.

You can't possibly have every piece of software referenced in a path
line, and that isn't what people are doing. Instead they are using shell
scripts that set the classpath before executing with every program -
resulting in a Windows like situation where every program is distributed
with all it's dependancies (making the effort toward unique naming
completely pointless).

You are right that jar files are part of the problem, because of the
stupid way they are handled (jar files should either be transparent or
seen as equivalent to subdirectories by the class loader). It seems to
me that this whole thing is a conscious effort by the worlds java
developers to cripple platform beyond usefulness (akin to loading an
entire virtual machine with each application).

I don't think that you can argue that standard practice really matters,
since this effort has been so successful that for all but a small
minority Freenet will be the first java program they use (it's the only 
java program _I_ use (beyond development)).

> > Also, I don't see the point of checking in compiled javadocs, and
> > especially binary class files, into cvs.
> 
> I wasn't proposing that these things are checked in, merely that the
> directories are there for stuff to go into when generated from the
> Makefile.

I don't really care how the build looks of course.

> > > That looks reasonable.  I'd rather you named the build dir "build"
> > > instead of "classes", it is fairly standard.
> > 
> > One java tree, one java tree, one java tree.
> 
> I really don't think this is practical, for example, it makes upgrading
> software a pain in the butt, and there is no established place on any
> operating system to place this mythical unified Java tree.  Trying to
> pretend that a practice exists when it doesn't will only make things
> more of a pain for everyone.

It would seem to me that being able to locate all the existing classes
would make upgrading a hell of lot easier (say there is a bug in a
crypto class used by twenty programs - good luck if every program dumped
it in the jar where nobody can see it). It needs constant interfaces and
unique naming - which are two things that we are told to do already
(pointlessly as it is).

(In my understanding /usr/lib/java is supposed to be a root in Debian,
though it will probably be abused.)

> > > Changing the package name from Freenet has been brought up before.  This
> > > would be a good time to do that.
> > 
> > This otoh is a good idea. It should be "freenet".
> 
> Why?

All other packages we use have lower case letters. It isn't a big deal,
and certainly not worth the effort of moving everything in CVS - but if
you are planning to do that anyways.

<>

-- 

Oskar Sandberg
oskar at freenetproject.org

_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl

Reply via email to