On Sun, May 20, 2001 at 04:13:31PM -0500, Adam Heath wrote:
> On Thu, 12 Apr 2001, Joe Emenaker wrote:
> > [...]
> > Well, each JVM on the system could have a script that builds the classpath
> > that it needs. That would be the first thing in the actual classpath passed
> > to the JVM. Next, you t
On Sun, May 20, 2001 at 04:13:31PM -0500, Adam Heath wrote:
> On Thu, 12 Apr 2001, Joe Emenaker wrote:
> > [...]
> > Well, each JVM on the system could have a script that builds the classpath
> > that it needs. That would be the first thing in the actual classpath passed
> > to the JVM. Next, you
On Thu, 12 Apr 2001, Joe Emenaker wrote:
> > Just to complicate the situation
> >
> > Any script that builds a PATHS,CLASSPATH, must also consider stripping
> > conflicts from them.
>
> Well, each JVM on the system could have a script that builds the classpath
> that it needs. That would be th
On Thu, 12 Apr 2001, Joe Emenaker wrote:
> > Just to complicate the situation
> >
> > Any script that builds a PATHS,CLASSPATH, must also consider stripping
> > conflicts from them.
>
> Well, each JVM on the system could have a script that builds the classpath
> that it needs. That would be t
On Thu, 12 Apr 2001, Cedric Berger wrote:
> > If I understand this extension mechanism correctly, the class loader can
> > potentially search the entire extensions directory at runtime. That seems
> > horribly inefficient if that directory can grow to dozens or hundreds of
> > .jar's.
>
> Isn't
On Thu, Apr 12, 2001 at 02:06:33PM -0400, Jeff Sturm wrote:
> However I like the idea of a Class-path: entry in the MANIFEST, to list
> dependencies by name. If an application is built as a .jar, it can have a
> Class-path: too. Then the linking mechanism is similar to ELF shared
> objects, and c
Jeff Sturm wrote:
> On 11 Apr 2001, Per Bothner wrote:
> > > The 'add everything' approach only invites DLL hell.
> >
> > Well, first this is what Sun does, at least to some extent, with the
> > "extensions" mechanism.
>
> If I understand this extension mechanism correctly, the class loader can
>
On Wed, Apr 11, 2001 at 12:32:12PM -0700, Per Bothner wrote:
> That is fine for nicely-packaged libraries and applications. However,
> I'm concerned about a random Java programmer who should not have to
> manually fiddle with their classpath. Such programmers should be able
> to write Java code w
On Thu, 12 Apr 2001, Cedric Berger wrote:
> > If I understand this extension mechanism correctly, the class loader can
> > potentially search the entire extensions directory at runtime. That seems
> > horribly inefficient if that directory can grow to dozens or hundreds of
> > .jar's.
>
> Isn'
On Thu, Apr 12, 2001 at 02:06:33PM -0400, Jeff Sturm wrote:
> However I like the idea of a Class-path: entry in the MANIFEST, to list
> dependencies by name. If an application is built as a .jar, it can have a
> Class-path: too. Then the linking mechanism is similar to ELF shared
> objects, and
Jeff Sturm wrote:
> On 11 Apr 2001, Per Bothner wrote:
> > > The 'add everything' approach only invites DLL hell.
> >
> > Well, first this is what Sun does, at least to some extent, with the
> > "extensions" mechanism.
>
> If I understand this extension mechanism correctly, the class loader can
>
On Wed, Apr 11, 2001 at 12:32:12PM -0700, Per Bothner wrote:
> That is fine for nicely-packaged libraries and applications. However,
> I'm concerned about a random Java programmer who should not have to
> manually fiddle with their classpath. Such programmers should be able
> to write Java code
> (As I'm reading this thread I'm debugging a classpath with 118 entries.
> It is a terrible mess, and the application is extremely slow to load.
Have you tried changing the classpath around so that the more commonly
needed classes appear earlier in the path?
- Joe
> Just to complicate the situation
>
> Any script that builds a PATHS,CLASSPATH, must also consider stripping
> conflicts from them.
Well, each JVM on the system could have a script that builds the classpath
that it needs. That would be the first thing in the actual classpath passed
to the JVM
On 11 Apr 2001, Per Bothner wrote:
> > The 'add everything' approach only invites DLL hell.
>
> Well, first this is what Sun does, at least to some extent, with the
> "extensions" mechanism.
If I understand this extension mechanism correctly, the class loader can
potentially search the entire e
> (As I'm reading this thread I'm debugging a classpath with 118 entries.
> It is a terrible mess, and the application is extremely slow to load.
Have you tried changing the classpath around so that the more commonly
needed classes appear earlier in the path?
- Joe
--
To UNSUBSCRIBE, email
> Just to complicate the situation
>
> Any script that builds a PATHS,CLASSPATH, must also consider stripping
> conflicts from them.
Well, each JVM on the system could have a script that builds the classpath
that it needs. That would be the first thing in the actual classpath passed
to the JV
On 11 Apr 2001, Per Bothner wrote:
> > The 'add everything' approach only invites DLL hell.
>
> Well, first this is what Sun does, at least to some extent, with the
> "extensions" mechanism.
If I understand this extension mechanism correctly, the class loader can
potentially search the entire
Just to complicate the situation
Any script that builds a PATHS,CLASSPATH, must also consider stripping
conflicts from them.
On my system, I have a set of use scripts, with which I can say:
use jdk -v 1.2
use jaxp
use jmx -v 1.0
If later I decide to do a
use jmx -v 1.0
then the old
Just to complicate the situation
Any script that builds a PATHS,CLASSPATH, must also consider stripping
conflicts from them.
On my system, I have a set of use scripts, with which I can say:
use jdk -v 1.2
use jaxp
use jmx -v 1.0
If later I decide to do a
use jmx -v 1.0
t
> On Sat, Apr 07, 2001 at 07:47:29PM -0700, Per Bothner wrote:
> > I disagree. My goal is that that /usr/share/java (or
> > /usr/share/java/lib if you prefer) should be similar to Sun's
> > extensions directory: a directory where *all* .jars
> > (i.e. /usr/share/java/*.jar) are added to the impli
[EMAIL PROTECTED] writes:
> I think explicitly specifying the .jars you want to import into your
> library or application, with sonames if necessary, seems better.
That is fine for nicely-packaged libraries and applications. However,
I'm concerned about a random Java programmer who should not ha
On Sat, Apr 07, 2001 at 07:47:29PM -0700, Per Bothner wrote:
> I disagree. My goal is that that /usr/share/java (or
> /usr/share/java/lib if you prefer) should be similar to Sun's
> extensions directory: a directory where *all* .jars
> (i.e. /usr/share/java/*.jar) are added to the implied classpat
> On Sat, Apr 07, 2001 at 07:47:29PM -0700, Per Bothner wrote:
> > I disagree. My goal is that that /usr/share/java (or
> > /usr/share/java/lib if you prefer) should be similar to Sun's
> > extensions directory: a directory where *all* .jars
> > (i.e. /usr/share/java/*.jar) are added to the impl
[EMAIL PROTECTED] writes:
> I think explicitly specifying the .jars you want to import into your
> library or application, with sonames if necessary, seems better.
That is fine for nicely-packaged libraries and applications. However,
I'm concerned about a random Java programmer who should not h
On Sat, Apr 07, 2001 at 07:47:29PM -0700, Per Bothner wrote:
> I disagree. My goal is that that /usr/share/java (or
> /usr/share/java/lib if you prefer) should be similar to Sun's
> extensions directory: a directory where *all* .jars
> (i.e. /usr/share/java/*.jar) are added to the implied classpa
> "Joe" == Joe Emenaker <[EMAIL PROTECTED]> writes:
Joe> Does the GNU definition say that the arch-independent stuff
Joe> "must" or "should" go there, or do they just say that it "can"?
Joe> Is /usr/lib/appname just as legal for the stuff that's
Joe> arch-independent or is it discouraged?
GNU
> "Joe" == Joe Emenaker <[EMAIL PROTECTED]> writes:
Joe> Does the GNU definition say that the arch-independent stuff
Joe> "must" or "should" go there, or do they just say that it "can"?
Joe> Is /usr/lib/appname just as legal for the stuff that's
Joe> arch-independent or is it discouraged?
GN
Joe> Well, to me, "share" means share, which the jvm-specific libs
Joe> aren't meant for.
FYI, traditionally `share' has actually meant
`architecture-independent'.
Fair enough. Since I only go into /usr/share/java and /usr/share/doc, I
had come to view it as the place where architecture-independe
>
>
> Joe> Well, to me, "share" means share, which the jvm-specific libs
> Joe> aren't meant for.
>
> FYI, traditionally `share' has actually meant
> `architecture-independent'.
Fair enough. Since I only go into /usr/share/java and /usr/share/doc, I
had come to view it as the place where arch
[Please cc this discussion to [EMAIL PROTECTED], the mailing list for
Gcj. A goal for this dicussion is to work out a policy that GNU tools
and applications, including Gcj and automake, can implement as their
default when configured with prefix=/usr. This is is a general GNU and
FHS standardizati
[Please cc this discussion to [EMAIL PROTECTED], the mailing list for
Gcj. A goal for this dicussion is to work out a policy that GNU tools
and applications, including Gcj and automake, can implement as their
default when configured with prefix=/usr. This is is a general GNU and
FHS standardizat
Joe Emenaker wrote:
It's also possible that 2 different (but very close) APIs have classes in
the same package.
What is Java supposed to do if it encounters two different classes of the
same name in the same package? Does it just take the first one that it
encounters?
While having classes for a
Joe Emenaker wrote:
>> It's also possible that 2 different (but very close) APIs have classes in
>> the same package.
>
> What is Java supposed to do if it encounters two different classes of the
> same name in the same package? Does it just take the first one that it
> encounters?
While havi
> "Joe" == Joe Emenaker <[EMAIL PROTECTED]> writes:
>> * Maybe putting jvm implementation jars in /usr/share/java/$impl
>> is the solution.
Joe> Well, to me, "share" means share, which the jvm-specific libs
Joe> aren't meant for.
FYI, traditionally `share' has actually meant
`architecture-in
> No, it's not that simple: you can always use the completely specified name
> to refer to a class (e.g. "java.util.Vector", even if you don't import the
> package nor the class). The "import" keyword is only there to ease the
> developer's work.
Correct. Many people assume that Java's "import" wo
> Java libraries:
> * Java libraries should go to /usr/share/java if they are
> jar files and /usr/share/java/repository if they are a collection
> of classes.
Well, being a big fan of Tomcat, I'd much more prefer to see .jar files in
"/usr/share/java/lib" and .class hierarchies in "/usr/shar
> "Joe" == Joe Emenaker <[EMAIL PROTECTED]> writes:
>> * Maybe putting jvm implementation jars in /usr/share/java/$impl
>> is the solution.
Joe> Well, to me, "share" means share, which the jvm-specific libs
Joe> aren't meant for.
FYI, traditionally `share' has actually meant
`architecture-i
> No, it's not that simple: you can always use the completely specified name
> to refer to a class (e.g. "java.util.Vector", even if you don't import the
> package nor the class). The "import" keyword is only there to ease the
> developer's work.
Correct. Many people assume that Java's "import" w
> Java libraries:
> * Java libraries should go to /usr/share/java if they are
> jar files and /usr/share/java/repository if they are a collection
> of classes.
Well, being a big fan of Tomcat, I'd much more prefer to see .jar files in
"/usr/share/java/lib" and .class hierarchies in "/usr/sha
--- Seth Arnold <[EMAIL PROTECTED]> wrote:
> * Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:09]:
> > Build:
> > Is it possible to create a script that generates this automaticly?
> > Like a dh_javadeps... It should also generate the dependencies
> > in the control file...
>
> I like this id
* Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:41]:
> Well to me it seems that this system will have some name clashes.
> Why not use the debian package name?
The initial revitalization of this thread comes from Per Bothner. His
own machine is Red Hat, and he seems pretty happy with it. :) He chos
On Fri, Apr 06, 2001 at 04:32:17AM -0700, Seth Arnold wrote:
> * Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:09]:
> > Build:
> > Is it possible to create a script that generates this automaticly?
> > Like a dh_javadeps... It should also generate the dependencies
> > in the control file...
>
On Fri, Apr 06, 2001 at 01:14:24PM +0100, Greg Wilkins wrote:
>
> Comments inline:
>
> Ola Lundqvist wrote:
>
> > Hi
> >
> > I have followed the java instalation issues thread. So I'l try
> > to summarize and give some new proposals.
> >
> > Java libraries:
> > * Java libraries should go to /u
* Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:09]:
> Build:
> Is it possible to create a script that generates this automaticly?
> Like a dh_javadeps... It should also generate the dependencies
> in the control file...
I like this idea. It *ought* to be fairly straightforward (famous last
w
Comments inline:
Ola Lundqvist wrote:
Hi
I have followed the java instalation issues thread. So I'l try
to summarize and give some new proposals.
Java libraries:
* Java libraries should go to /usr/share/java if they are
jar files and /usr/share/java/repository if they are a collection
of classe
--- Seth Arnold <[EMAIL PROTECTED]> wrote:
> * Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:09]:
> > Build:
> > Is it possible to create a script that generates this automaticly?
> > Like a dh_javadeps... It should also generate the dependencies
> > in the control file...
>
> I like this i
* Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:41]:
> Well to me it seems that this system will have some name clashes.
> Why not use the debian package name?
The initial revitalization of this thread comes from Per Bothner. His
own machine is Red Hat, and he seems pretty happy with it. :) He cho
On Fri, Apr 06, 2001 at 04:32:17AM -0700, Seth Arnold wrote:
> * Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:09]:
> > Build:
> > Is it possible to create a script that generates this automaticly?
> > Like a dh_javadeps... It should also generate the dependencies
> > in the control file...
>
On Fri, Apr 06, 2001 at 01:14:24PM +0100, Greg Wilkins wrote:
>
> Comments inline:
>
> Ola Lundqvist wrote:
>
> > Hi
> >
> > I have followed the java instalation issues thread. So I'l try
> > to summarize and give some new proposals.
> >
> > Java libraries:
> > * Java libraries should go to /
* Ola Lundqvist <[EMAIL PROTECTED]> [010406 04:09]:
> Build:
> Is it possible to create a script that generates this automaticly?
> Like a dh_javadeps... It should also generate the dependencies
> in the control file...
I like this idea. It *ought* to be fairly straightforward (famous last
Comments inline:
Ola Lundqvist wrote:
> Hi
>
> I have followed the java instalation issues thread. So I'l try
> to summarize and give some new proposals.
>
> Java libraries:
> * Java libraries should go to /usr/share/java if they are
> jar files and /usr/share/java/repository if they are a
52 matches
Mail list logo
