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
of
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
of
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 will
* 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 programs.
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 will
* 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 programs.
* 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
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 runtime or
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 main
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
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.jar, but
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 way to
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
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
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 runtime or
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 main
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
* 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.
There are
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
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, but
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
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 not ...
* 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 Debian
as
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
* 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.
There are several
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 hope not ...
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
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
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 just
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.
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 not ...
36 matches
Mail list logo
