> On 03 Apr 2001 07:50:33 +0200, Egon Willighagen wrote:
> I was playing around with a scheme; it went like this:
> -> versioned files and symlinks much like .so
> -> e.g.
> ---> antlr-1.2.3.jar
> ---> antlr-1.2.4.jar
> ---> antlr-2.0.1.jar
> ---> antlr-2.1.0.jar
> ---> antlr-2.1.3.jar
> ---> antl
> On 03 Apr 2001 07:50:33 +0200, Egon Willighagen wrote:
> I was playing around with a scheme; it went like this:
> -> versioned files and symlinks much like .so
> -> e.g.
> ---> antlr-1.2.3.jar
> ---> antlr-1.2.4.jar
> ---> antlr-2.0.1.jar
> ---> antlr-2.1.0.jar
> ---> antlr-2.1.3.jar
> ---> ant
On 05 Apr 2001 00:26:11 -0700, Seth Arnold wrote:
> * Egon Willighagen <[EMAIL PROTECTED]> [010405 00:14]:
> > This would certainly be a good option... If we good get it as flexible
> > as the proposed Perl launcher
>
> I've got to throw in my two cents: I too hate the idea of using any sort
>
On 05 Apr 2001 00:26:11 -0700, Seth Arnold wrote:
> * Egon Willighagen <[EMAIL PROTECTED]> [010405 00:14]:
> > This would certainly be a good option... If we good get it as flexible
> > as the proposed Perl launcher
>
> I've got to throw in my two cents: I too hate the idea of using any sort
* Per Bothner
| Egon Willighagen <[EMAIL PROTECTED]> writes:
|
| > I like the idea of a Perl launcher...
|
| I hate the idea of requiring Perl in order to run Java ...
|
| Of course Debian can use whatever wrappers it will, but no Java
| application *I* manage will require Perl to run.
Debian
* Per Bothner
| Egon Willighagen <[EMAIL PROTECTED]> writes:
|
| > I like the idea of a Perl launcher...
|
| I hate the idea of requiring Perl in order to run Java ...
|
| Of course Debian can use whatever wrappers it will, but no Java
| application *I* manage will require Perl to run.
Debia
* Egon Willighagen <[EMAIL PROTECTED]> [010405 00:14]:
> This would certainly be a good option... If we good get it as flexible
> as the proposed Perl launcher
I've got to throw in my two cents: I too hate the idea of using any sort
of script to start execution of 'native-looking' Java program
Op donderdag 05 april 2001 01:43, schreef Per Bothner:
> Egon Willighagen <[EMAIL PROTECTED]> writes:
> > I like the idea of a Perl launcher...
>
> I hate the idea of requiring Perl in order to run Java ...
>
> Of course Debian can use whatever wrappers it will, but no Java
> application *I* manage
* Egon Willighagen <[EMAIL PROTECTED]> [010405 00:14]:
> This would certainly be a good option... If we good get it as flexible
> as the proposed Perl launcher
I've got to throw in my two cents: I too hate the idea of using any sort
of script to start execution of 'native-looking' Java progra
Op donderdag 05 april 2001 01:43, schreef Per Bothner:
> Egon Willighagen <[EMAIL PROTECTED]> writes:
> > I like the idea of a Perl launcher...
>
> I hate the idea of requiring Perl in order to run Java ...
>
> Of course Debian can use whatever wrappers it will, but no Java
> application *I* manag
On 4 Apr 2001, Per Bothner wrote:
> Egon Willighagen <[EMAIL PROTECTED]> writes:
>
> > I like the idea of a Perl launcher...
>
> I hate the idea of requiring Perl in order to run Java ...
So gcj has jvgenmain. You can do the same for other VMs-- generate a
small executable that invokes the ma
>> The `L.so' in this case should probably follow the naming scheme we
>> adopted for the `.so' files that Class.forName will automatically try
>> to load. That will make it so that the linker and Class.forName will
>> agree -- it won't matter to the end program whether a class is loaded
>> at run
Egon Willighagen <[EMAIL PROTECTED]> writes:
> I like the idea of a Perl launcher...
I hate the idea of requiring Perl in order to run Java ...
Of course Debian can use whatever wrappers it will, but no Java
application *I* manage will require Perl to run.
--
--Per Bothner
[EMAIL PROTEC
Tom Tromey <[EMAIL PROTECTED]> writes:
> I think we'll need a way to disable the built-in search path except
> for libgcj.jar.
I'm concentrating on the default paths, for installed software.
We will need flags to override the builtin paths, for example
for building libgcj itself, or for building
On 4 Apr 2001, Per Bothner wrote:
> Egon Willighagen <[EMAIL PROTECTED]> writes:
>
> > I like the idea of a Perl launcher...
>
> I hate the idea of requiring Perl in order to run Java ...
So gcj has jvgenmain. You can do the same for other VMs-- generate a
small executable that invokes the m
>> The `L.so' in this case should probably follow the naming scheme we
>> adopted for the `.so' files that Class.forName will automatically try
>> to load. That will make it so that the linker and Class.forName will
>> agree -- it won't matter to the end program whether a class is loaded
>> at ru
Egon Willighagen <[EMAIL PROTECTED]> writes:
> I like the idea of a Perl launcher...
I hate the idea of requiring Perl in order to run Java ...
Of course Debian can use whatever wrappers it will, but no Java
application *I* manage will require Perl to run.
--
--Per Bothner
[EMAIL PROTE
Tom Tromey <[EMAIL PROTECTED]> writes:
> I think we'll need a way to disable the built-in search path except
> for libgcj.jar.
I'm concentrating on the default paths, for installed software.
We will need flags to override the builtin paths, for example
for building libgcj itself, or for building
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> So to summarize: The builtin search path should be (in this order):
Per> (1) each .jar file in /usr/share/java/$implementation
Per> (2) each .jar file in /usr/share/java
Per> (3) the /usr/share/java directory itself
I think we'll need a
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> So to summarize: The builtin search path should be (in this order):
Per> (1) each .jar file in /usr/share/java/$implementation
Per> (2) each .jar file in /usr/share/java
Per> (3) the /usr/share/java directory itself
I think we'll need
Op dinsdag 03 april 2001 18:49, schreef Paul Reavis:
> On 03 Apr 2001 07:50:33 +0200, Egon Willighagen wrote:
> > > I've left out versioning issues. If one want to support multiple
> > > versions of the same library one could install LIBRARY-VERSION.jar,
> > > and install a symlink from LIBRARY.ja
Op dinsdag 03 april 2001 19:00, schreef Per Bothner:
> > Or maybe, to have two conflicting packages program and program-gcj?
>
> I've concentrated on where things get installed, not so much on how
> things get split into package, but here are soem notes on the latter.
> For libraries it might be re
Op dinsdag 03 april 2001 18:49, schreef Paul Reavis:
> On 03 Apr 2001 07:50:33 +0200, Egon Willighagen wrote:
> > > I've left out versioning issues. If one want to support multiple
> > > versions of the same library one could install LIBRARY-VERSION.jar,
> > > and install a symlink from LIBRARY.j
Op dinsdag 03 april 2001 19:00, schreef Per Bothner:
> > Or maybe, to have two conflicting packages program and program-gcj?
>
> I've concentrated on where things get installed, not so much on how
> things get split into package, but here are soem notes on the latter.
> For libraries it might be r
[EMAIL PROTECTED] (Andrew Pimlott) writes:
> > JNI libraries shold probably (by default) go in either /usr/lib
> > or /usr/lib/java. The latter again has the advantage of reducing
> > clutter and name clashes, but I don't know how awkward that would
> > be for other Java implementations.
>
> Ok,
Ok, it looks like my understanding of the details is lacking. I'll
try to keep this message on a higher level. Sorry for any
confusion.
On Tue, Apr 03, 2001 at 08:58:19AM -0700, Per Bothner wrote:
> [EMAIL PROTECTED] (Andrew Pimlott) writes:
> > On the other hand, if JNI is an ABI, it would
> >
egonw <[EMAIL PROTECTED]> writes:
> Ok, in addition to the current Debian policy, a third, preferred
> option, being the gcj compiled library.
Yes. The interpreter (VM) that is part of the gcj run-time library
allows you to include a .so in the classpath, and it is searched for
needed classes ju
On 03 Apr 2001 07:50:33 +0200, Egon Willighagen wrote:
> > I've left out versioning issues. If one want to support multiple
> > versions of the same library one could install LIBRARY-VERSION.jar,
> > and install a symlink from LIBRARY.jar, but having compilers and
> > VMs pick the right version is
[EMAIL PROTECTED] (Andrew Pimlott) writes:
> > JNI libraries shold probably (by default) go in either /usr/lib
> > or /usr/lib/java. The latter again has the advantage of reducing
> > clutter and name clashes, but I don't know how awkward that would
> > be for other Java implementations.
>
> Ok
[EMAIL PROTECTED] (Andrew Pimlott) writes:
> What recommendation should we make to packagers of libraries that
> have native components? I assume that Java native method APIs (like
> JNI) are source-level, not binary-level.
JNI is binary-level, in the sense that compiled JNI code should
be indep
Ok, it looks like my understanding of the details is lacking. I'll
try to keep this message on a higher level. Sorry for any
confusion.
On Tue, Apr 03, 2001 at 08:58:19AM -0700, Per Bothner wrote:
> [EMAIL PROTECTED] (Andrew Pimlott) writes:
> > On the other hand, if JNI is an ABI, it would
> >
On Tue, Apr 03, 2001 at 06:47:37AM -0400, egonw wrote:
> Indeed. But the principle holds that in Debian, with dependencies, that
> a certain executable exactly knows where to find a certain library.
Not true. Executables declare dependencies on soname's. It is the
job of the runtime linker to de
egonw <[EMAIL PROTECTED]> writes:
> Ok, in addition to the current Debian policy, a third, preferred
> option, being the gcj compiled library.
Yes. The interpreter (VM) that is part of the gcj run-time library
allows you to include a .so in the classpath, and it is searched for
needed classes j
On 03 Apr 2001 07:50:33 +0200, Egon Willighagen wrote:
> > I've left out versioning issues. If one want to support multiple
> > versions of the same library one could install LIBRARY-VERSION.jar,
> > and install a symlink from LIBRARY.jar, but having compilers and
> > VMs pick the right version i
My background in these issues is modest, but I have a strong
interest in seeing them resolved, so let me try to add something.
On Mon, Apr 02, 2001 at 05:43:55PM -0700, Per Bothner wrote:
> So where should be put the .jar files? I suggest leaving this as
> /usr/share/java. However, we should add
[EMAIL PROTECTED] (Andrew Pimlott) writes:
> What recommendation should we make to packagers of libraries that
> have native components? I assume that Java native method APIs (like
> JNI) are source-level, not binary-level.
JNI is binary-level, in the sense that compiled JNI code should
be inde
On Tue, Apr 03, 2001 at 06:47:37AM -0400, egonw wrote:
> Indeed. But the principle holds that in Debian, with dependencies, that
> a certain executable exactly knows where to find a certain library.
Not true. Executables declare dependencies on soname's. It is the
job of the runtime linker to d
My background in these issues is modest, but I have a strong
interest in seeing them resolved, so let me try to add something.
On Mon, Apr 02, 2001 at 05:43:55PM -0700, Per Bothner wrote:
> So where should be put the .jar files? I suggest leaving this as
> /usr/share/java. However, we should ad
Quoting Per Bothner <[EMAIL PROTECTED]>:
> > Op dinsdag 03 april 2001 02:43, schreef Per Bothner:
> > > I'd like to make some progress on standard Linux/GNU installation
> > > standards for Java, and how GCJ fits into this.
> >
> > Have you taken over the maintainership? (Just wondering)
>
> I
Quoting Seth Arnold <[EMAIL PROTECTED]>:
> > > With this setup:
> > > (1) All Java compilers and VMs can compile find all "installed"
.jars,
> > > without users having to fiddle with classpaths.
>
> I do not like this idea.
I agree. I mentioned it because it came up in earlier discussions.
> Ther
Quoting Per Bothner <[EMAIL PROTECTED]>:
> > Op dinsdag 03 april 2001 02:43, schreef Per Bothner:
> > > I'd like to make some progress on standard Linux/GNU installation
> > > standards for Java, and how GCJ fits into this.
> >
> > Have you taken over the maintainership? (Just wondering)
>
> I
* Per Bothner <[EMAIL PROTECTED]> [010403 00:01]:
> Well, I'm not focusing on Debian - I'm actually currently using Red Hat.
Aha; I assumed you used Debian because you have posted in debian-java
before, over the course of several months IIRC.
I imagine that most any improvements in handling Java
Quoting Seth Arnold <[EMAIL PROTECTED]>:
> > > With this setup:
> > > (1) All Java compilers and VMs can compile find all "installed"
.jars,
> > > without users having to fiddle with classpaths.
>
> I do not like this idea.
I agree. I mentioned it because it came up in earlier discussions.
> The
Seth Arnold <[EMAIL PROTECTED]> writes:
> (Per, glad to see you are interested in making Java as cool in Debian
> as native stuff is handled currently. :)
Well, I'm not focusing on Debian - I'm actually currently using Red Hat.
My goal is to make Java cool in GNU generally, and GNU/Linux specific
* Egon Willighagen <[EMAIL PROTECTED]> [010402 22:58]:
> Op dinsdag 03 april 2001 02:43, schreef Per Bothner:
> > I'd like to make some progress on standard Linux/GNU installation
> > standards for Java, and how GCJ fits into this.
(Per, glad to see you are interested in making Java as cool in Deb
Egon Willighagen <[EMAIL PROTECTED]> writes:
> Op dinsdag 03 april 2001 02:43, schreef Per Bothner:
> > I'd like to make some progress on standard Linux/GNU installation
> > standards for Java, and how GCJ fits into this.
>
> Have you taken over the maintainership? (Just wondering)
I hope no
Op dinsdag 03 april 2001 02:43, schreef Per Bothner:
> I'd like to make some progress on standard Linux/GNU installation
> standards for Java, and how GCJ fits into this.
Have you taken over the maintainership? (Just wondering)
> This could lead to an updated Debian Java policy (which is
> at
* Per Bothner <[EMAIL PROTECTED]> [010403 00:01]:
> Well, I'm not focusing on Debian - I'm actually currently using Red Hat.
Aha; I assumed you used Debian because you have posted in debian-java
before, over the course of several months IIRC.
I imagine that most any improvements in handling Java
Seth Arnold <[EMAIL PROTECTED]> writes:
> (Per, glad to see you are interested in making Java as cool in Debian
> as native stuff is handled currently. :)
Well, I'm not focusing on Debian - I'm actually currently using Red Hat.
My goal is to make Java cool in GNU generally, and GNU/Linux specifi
* Egon Willighagen <[EMAIL PROTECTED]> [010402 22:58]:
> Op dinsdag 03 april 2001 02:43, schreef Per Bothner:
> > I'd like to make some progress on standard Linux/GNU installation
> > standards for Java, and how GCJ fits into this.
(Per, glad to see you are interested in making Java as cool in De
Egon Willighagen <[EMAIL PROTECTED]> writes:
> Op dinsdag 03 april 2001 02:43, schreef Per Bothner:
> > I'd like to make some progress on standard Linux/GNU installation
> > standards for Java, and how GCJ fits into this.
>
> Have you taken over the maintainership? (Just wondering)
I hope n
Op dinsdag 03 april 2001 02:43, schreef Per Bothner:
> I'd like to make some progress on standard Linux/GNU installation
> standards for Java, and how GCJ fits into this.
Have you taken over the maintainership? (Just wondering)
> This could lead to an updated Debian Java policy (which is
> a
I'd like to make some progress on standard Linux/GNU installation
standards for Java, and how GCJ fits into this.
This could lead to an updated Debian Java policy (which is
at http://people.debian.org/~bortz/Java/policy.html) and ultimately
be part of a future Linux File Hierarchy Standard.
Curren
I'd like to make some progress on standard Linux/GNU installation
standards for Java, and how GCJ fits into this.
This could lead to an updated Debian Java policy (which is
at http://people.debian.org/~bortz/Java/policy.html) and ultimately
be part of a future Linux File Hierarchy Standard.
Curre
54 matches
Mail list logo
