Date: Fri, 18 Dec 1998 16:41:41 -0700 From: Nate Williams <nate@mt.sri.com> To: Chuck Robey <chuckr@mat.net> Cc: Nate Williams <nate@mt.sri.com>, freebsd-java@FreeBSD.ORG Subject: Re: Where to put java libs Message-ID: <199812182341.QAA10374@mt.sri.com> In-Reply-To: <Pine.BSF.4.05.9812181834130.310-100000@picnic.mat.net> References: <199812182231.PAA09737@mt.sri.com> <Pine.BSF.4.05.9812181834130.310-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > and it goes on to say that, if this is under local, the same rules > > > > > apply, just that it's locally installed stuff. Well, the class files, > > > > > jar files, zip files, etc, aren't ascii. The only way to stretch this > > > > > is claiming its architecturally independent, but so is tcl (establishing > > > > > a precedent for /usr/local/lib, for arch-independent stuff). > > > > > > > > I think it's a mistake to put things other than libraries in lib, > > > > from hier(7): > > > > > > > > lib/ archive libraries > > > > ... > > > > libdata/ misc. utility data files > > > > > > But that's my point. The java stuff is shared code, unable to execute > > > alone, needed to execute by other java programs, exactly like anything > > > that depends on a C lib (like libc). > > > > *EVERYTHING* share is 'shared' and requires something to do with it. > > What good is a termcap w/out a program to run it? What about syscons > > keymaps? It needs something to execute it. > > "shared" isn't the criteria, nor what I asked. The kernel is shared > among all processes (to take things to the ridiculous limit). Shared in this context (the FS) is shared across disks, aka. NFS. Java libraries can be shared across architectures, so they can be safely exported to other machines to save disk space. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812182341.QAA10374>