of dual
JNI-or-CNI mechanism. I.e. explore ways to reduce the
overhead of JNI when CNI is avaliable. I suggested one
approach in my previous email (which may be waiting for
moderator approval on the kaffe and java-gnome lists).
--
--Per Bothner
[EMAIL PROTECTED] http://per.bot
processor wit
extra functionality. For example many of the JNI callback functions
are just wrappers for CNI functions, so a simple conversion can
convert those, possibly removing the need for the JNIEnv
variable.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
--
To UNSUBSCRIBE, email
date all the pointers. That is
a very hard problem. Furthermore, it has been claimed that JNI also in
practice requires a conservative collector.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
/
http://mail.gnu.org/archive/html/classpath/2003-08/msg4.html
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ernative JVM. If the latter claims to support all JDK 1.x
features, then it will *probably* run, but you still have to test it.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
u can also "java-compatible-with-jdk1.3" but no Free JVM
are likely to satisfy such a constraint anytime soon.
(compilatible-with-jdk1.1 is getting close, though!)
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
u can also "java-compatible-with-jdk1.3" but no Free JVM
are likely to satisfy such a constraint anytime soon.
(compilatible-with-jdk1.1 is getting close, though!)
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
ernative JVM. If the latter claims to support all JDK 1.x
features, then it will *probably* run, but you still have to test it.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Arnaud Vandyck wrote:
A phone call may be worthwhile.
Is it a joke?! :-|
Why should it be a joke? If you want to contact someone
and are having trouble contacting them by email, but
you have a phone number for their place of business, then
a phone is a very practical tool.
--
--Per
ECTED]
As an alternative, as Ean is/was head of Brainfood, you
could try contacting Brainfood and asking them:
http://www.brainfood.com/aboutus/contactus.jsp
A phone call may be worthwhile.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
--
To UNSUBSCRIBE, email to [EMAIL PROT
g gij.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Arnaud Vandyck wrote:
A phone call may be worthwhile.
Is it a joke?! :-|
Why should it be a joke? If you want to contact someone
and are having trouble contacting them by email, but
you have a phone number for their place of business, then
a phone is a very practical tool.
--
--Per
ECTED]
As an alternative, as Ean is/was head of Brainfood, you
could try contacting Brainfood and asking them:
http://www.brainfood.com/aboutus/contactus.jsp
A phone call may be worthwhile.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
g gij.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
ifferent implementations, especially when
there is native code, for which GCJ prefers CNI over JNI.
Bottom line: Classpath is "upstream" to libgcj, but from a
Debian packaging point of view there is no relationship.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
Stephen Zander wrote:
>>>>>"Per" == Per Bothner writes:
Per> libgcj has had "core classes and JVM" (including ClassLoaders
Per> and JNI) for years.
The why doesn't the package 'Provide: java1-runtime'?
Possibly a different concep
core classes and JVM" (including ClassLoaders and JNI)
for years.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
ifferent implementations, especially when
there is native code, for which GCJ prefers CNI over JNI.
Bottom line: Classpath is "upstream" to libgcj, but from a
Debian packaging point of view there is no relationship.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
Stephen Zander wrote:
>>>>>"Per" == Per Bothner writes:
Per> libgcj has had "core classes and JVM" (including ClassLoaders
Per> and JNI) for years.
The why doesn't the package 'Provide: java1-runtime'?
Possibly a different co
uot;core classes and JVM" (including ClassLoaders and JNI)
for years.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Stefan Gybas wrote:
Sure, but since neither classpath nor libgcj* provide the virtual
runtime package
Why doesn't libgcj provide the virtual runtime package?
It seems like it should.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
Stefan Gybas wrote:
Sure, but since neither classpath nor libgcj* provide the virtual
runtime package
Why doesn't libgcj provide the virtual runtime package?
It seems like it should.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
--
To UNSUBSCRIBE, email to [
Ben Burton wrote:
IIRC the issue of automatically including every jar in /usr/share/java has
already been hashed out on this list and decided to be a bad idea (too much
overhead, poor control over conflicts, etc), thought I could be wrong.
I did on September 2 make the following suggestion:
Jav
Ben Burton wrote:
>IIRC the issue of automatically including every jar in /usr/share/java has
>already been hashed out on this list and decided to be a bad idea (too much
>overhead, poor control over conflicts, etc), thought I could be wrong.
>
I did on September 2 make the following suggestio
t *should* use
/usr/share/java/ext as the default such directory.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
irectories", it *should* use
/usr/share/java/ext as the default such directory.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
#x27;t a Java runtme, gcj comes
with an associated interpreter and runtime. The command 'gij' is
intended to be able to replace the 'java' command.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
command* isn't a Java runtme, gcj comes
with an associated interpreter and runtime. The command 'gij' is
intended to be able to replace the 'java' command.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
--
To UNSUBSCRIBE, email to [EMAIL PROTE
rld) behind
SableVM. This means at least 3 faculty-researcher and their graduate
and undergradute students.
I welcome the SableVM to consider whether their tchniques and
code could be consistent with GCJ and produce something better than
either. We would welcome such help.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
e's the whole Sable project (which has
>>brought the Soot bytecode analysis framework to the world) behind
>>SableVM. This means at least 3 faculty-researcher and their graduate
>>and undergradute students.
I welcome the SableVM to consider whether their tchniques and
code cou
low. After all you don't do the .c to .so
compilation at installation time, so why should .java to .so be
different?
Also, what happens if you install a Java package, and then install
gcj later? Shuld that so the compilation to .so when you install
gcj?
--
--Per Bothner
[EMAIL P
rdize packaging.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ink it would be too slow. After all you don't do the .c to .so
compilation at installation time, so why should .java to .so be
different?
Also, what happens if you install a Java package, and then install
gcj later? Shuld that so the compilation to .so when you install
gcj?
--
ill help to standardize packaging.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
k my patches, I'd like to know how they work.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
2002-04-10 Per Bothner <[EMAIL PROTECTED]>
* eval.c (evaluate_subexp_standard): Do overload resolution for Java.
* infcmd.c (run_command): Reset
o check my patches, I'd like to know how they work.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
2002-04-10 Per Bothner <[EMAIL PROTECTED]>
* eval.c (evaluate_subexp_standard): Do overload resolution for Java.
* infcmd.c (run_command)
done a fair bit recently, but there is
still quite a bit that needs to be done before the AWT implementation
is complete and stable enough to write real GUI applications or applets.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
en
merged in. Tom Tromey has done a fair bit recently, but there is
still quite a bit that needs to be done before the AWT implementation
is complete and stable enough to write real GUI applications or applets.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
--
To UNS
;t believe that is the case - could someone provide a reference?
4.1 What jvms work in Debian
Change title to "Sun-licensed" or "jck-derived" since there is a
separate following section for "free jvms"
4.2 What free JVMs are available in Debian?
Please add:
* GCJ.
Debian?
Please add:
* GCJ. The GCJ run-time libgcj includes an interpreter and classloader.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ntext of standardization for more general Linux and/or GNU
systems. I.e. if/when Linux Standard Base or some similar project
should tackle Java, can you make a good case that they should base it on
the Debian policy?
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
M systems?
Only in the context of standardization for more general Linux and/or GNU
systems. I.e. if/when Linux Standard Base or some similar project
should tackle Java, can you make a good case that they should base it on
the Debian policy?
--
--Per Bothner
[EMAIL PROTECTED] http:/
Adam Heath wrote:
Well, -classpath(jdk), --classpath(gcj).
It appears to me that gcj supports both -classpath and --classpath
equally. It does not support the newer -cp option.
However, gij does not appear to support either option, though it does
support a CLASSPATH environment variable. It also s
hey better match 'java' and 'java' would be
very welcome;
in lieu of that a gnats bug report would also be welcome so at least we know
there is a problem. (No guarantee that it will be fixed, of course.)
--Per Bothner
Adam Heath wrote:
On 20 Nov 2001, Tom Tromey wrote:
"Ben" == Ben Burton <[EMAIL PROTECTED]> writes:
Well, the gcj runtimes (libgcj or whatever the package name is)
should be fixed to provide java-runtime.
Ben> Oh.. I had figured it was a deliberate decision on behalf of the
Ben> gcc maintainers not
Adam Heath wrote:
>Well, -classpath(jdk), --classpath(gcj).
>
It appears to me that gcj supports both -classpath and --classpath
equally. It does not support the newer -cp option.
However, gij does not appear to support either option, though it does
support a CLASSPATH environment variable. It
' and 'gcj -C' so they better match 'java' and 'java' would be
very welcome;
in lieu of that a gnats bug report would also be welcome so at least we know
there is a problem. (No guarantee that it will be fixed, of course.)
--Per Bothner
--
To UNSUBSCRIBE, em
Adam Heath wrote:
>On 20 Nov 2001, Tom Tromey wrote:
>
>>>"Ben" == Ben Burton <[EMAIL PROTECTED]> writes:
>>>
Well, the gcj runtimes (libgcj or whatever the package name is)
should be fixed to provide java-runtime.
>>Ben> Oh.. I had figured it was a deliberate decision on beh
Ben Burton wrote:
Well, the gcj runtimes (libgcj or whatever the package name is)
should be fixed to provide java-runtime.
Oh.. I had figured it was a deliberate decision on behalf of the gcc
maintainers not to provide java-runtime (for reasons such as command-line
incompatibility, etc).
The "gi
java-runtime.
Well, the gcj runtimes (libgcj or whatever the package name is)
should be fixed to provide java-runtime.
--Per Bothner
Ben Burton wrote:
>>Well, the gcj runtimes (libgcj or whatever the package name is)
>>should be fixed to provide java-runtime.
>>
>
>Oh.. I had figured it was a deliberate decision on behalf of the gcc
>maintainers not to provide java-runtime (for reasons such as command-line
>incompatibility,
in main that provides java-runtime.
>
Well, the gcj runtimes (libgcj or whatever the package name is)
should be fixed to provide java-runtime.
--Per Bothner
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gnu.gcj.runtime.SharedLibLoader class. This
is a ClassLoader that wraps a .so (pre-compiled native shared library).
You could have a servlet engine that compiles a Java or jsp or whatever
to a native shared library as needed, and then loads it using a
SharedLibLoader.
--Per Bothner
cifically: Recent versions of gcj
(i.e. not 3.0) have a gnu.gcj.runtime.SharedLibLoader class. This
is a ClassLoader that wraps a .so (pre-compiled native shared library).
You could have a servlet engine that compiles a Java or jsp or whatever
to a native shared library as needed, and then load
ng server-style or other non-GUI application, I suggest
you try it. See htpp://gcc.gnu.org/java/
--Per Bothner
WT. If you're
running server-style or other non-GUI application, I suggest
you try it. See htpp://gcc.gnu.org/java/
--Per Bothner
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Stefan Gybas wrote:
Basically yes, but IMHO this should be the decision of the local admin
and not of the package maintainer. How could he know ig his package
contains "standard" jars? This means that no package should automatically
put jars or symlinks there. This would be /etc/java/default-classp
Ben Burton wrote:
Okay, so have I got this right? The proposal is to have a directory for
"standard" jars that are auto-included in the classpath for every JVM,
Yes, though how this is done is to be determined. For example some JVMs
might not have an "extensions" directory, or if they do it has t
Stefan Gybas wrote:
> Basically yes, but IMHO this should be the decision of the local admin
> and not of the package maintainer. How could he know ig his package
> contains "standard" jars? This means that no package should automatically
> put jars or symlinks there. This would be /etc/java/defa
Ben Burton wrote:
>Okay, so have I got this right? The proposal is to have a directory for
>"standard" jars that are auto-included in the classpath for every JVM,
>
Yes, though how this is done is to be determined. For example some JVMs
might not have an "extensions" directory, or if they do it
Ola Lundqvist wrote:
On Mon, Sep 17, 2001 at 12:15:59AM -0700, Per Bothner wrote:
My proposal does not say anything about /usr/bin/java, except that
the default classpath should include jars of installed packages.
I am agnostic about the specifics of how that is done.
Note that there are no
Ola Lundqvist wrote:
>On Mon, Sep 17, 2001 at 12:15:59AM -0700, Per Bothner wrote:
>
>>My proposal does not say anything about /usr/bin/java, except that
>>the default classpath should include jars of installed packages.
>>I am agnostic about the specifics of how tha
Ola Lundqvist <[EMAIL PROTECTED]> writes:
> Well this is not a simple HelloWorld program, it is a servlet. And
> the classes is in servlet2.2.jar right now.
I'm sorry but I don't see your point. I'm not particularly
concerned about simple HelloWorld programs.
--
is no way to extend an interface without breaking old clients..
The servlet API is of course notorious in this respect. C/C++
doesn't have this problem, at least not to the same extent.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
Ola Lundqvist <[EMAIL PROTECTED]> writes:
> Well this is not a simple HelloWorld program, it is a servlet. And
> the classes is in servlet2.2.jar right now.
I'm sorry but I don't see your point. I'm not particularly
concerned about simple HelloWorld programs.
--
is no way to extend an interface without breaking old clients..
The servlet API is of course notorious in this respect. C/C++
doesn't have this problem, at least not to the same extent.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
location: package servlet
import javax.servlet.Servlet;
^
1 error
On Sun, Sep 16, 2001 at 02:16:58PM -0700, Per Bothner wrote:
Let's just suppose that some crazy people disagree with you, and don't
want miscellaneous libraries in their classpath.
If people want that, th
jeff wrote:
Why not just put the jars in /usr/share/java, keep the system classpath
completely clean, and let the startup scripts for individual apps choose which
to include?
Because you're causing a big hassle for anybody writing a Java program,
even "hello world".
It is one thing to ask packager
upport. For example, Per Bothner said in a previous thread,
In Java we have a global namespace, so the user/developer should
not have to specify classpaths etc by default.
(http://lists.debian.org/debian-java/2001/debian-java-200104/msg00014.html)
I mention this because Per qualifies as somet
bol : class Servlet
location: package servlet
import javax.servlet.Servlet;
^
1 error
On Sun, Sep 16, 2001 at 02:16:58PM -0700, Per Bothner wrote:
>Let's just suppose that some crazy people disagree with you, and don't
>want miscellaneous libraries in their clas
jeff wrote:
>Why not just put the jars in /usr/share/java, keep the system classpath
>completely clean, and let the startup scripts for individual apps choose which
>to include?
>
Because you're causing a big hassle for anybody writing a Java program,
even "hello world".
It is one thing to ask p
ould point out that the opposite view
>has support. For example, Per Bothner said in a previous thread,
>
>In Java we have a global namespace, so the user/developer should
>not have to specify classpaths etc by default.
>
>(http://lists.debian.org/debian-java/2001/debia
$(LIBTOOL) --tag=GCJ --mode=compile $(GCJ) $(GCJFLAGS) \
--CLASSPATH=$(JAVAROOT):$(srcdir)/$(JAVAROOT) -c \
$^ $(EXTRA_GCJ_INPUTS) -o $(OFILES_DIR)/$(PACKAGE_FNAME).lo
The sourcesa are on ftp://ftp.gnu.org/pub/gnu/kawa/kawa-newest.tar.gz .
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
$(LIBTOOL) --tag=GCJ --mode=compile $(GCJ) $(GCJFLAGS) \
--CLASSPATH=$(JAVAROOT):$(srcdir)/$(JAVAROOT) -c \
$^ $(EXTRA_GCJ_INPUTS) -o $(OFILES_DIR)/$(PACKAGE_FNAME).lo
The sourcesa are on ftp://ftp.gnu.org/pub/gnu/kawa/kawa-newest.tar.gz .
--
--Per Bothner
[EM
ther thing to consider: Should gcjh-generated .h files be installed?
> For Freenet the compiled .so is about 3Mb, so this would actually be
> quite enough to worry about on my side.
In that case the clean solution would seem to be make two packages:
freenet and freenet-with-gcj (or wh
ve.
Another thing to consider: Should gcjh-generated .h files be installed?
> For Freenet the compiled .so is about 3Mb, so this would actually be
> quite enough to worry about on my side.
In that case the clean solution would seem to be make two packages:
freenet and freenet-with-gcj (or wh
he size of a .so isn't
enough to worry about.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
he size of a .so isn't
enough to worry about.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
due to lack of support for multiple versions of a library, and applications
installing a version they need without consideration for other applications.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
problem,
due to lack of support for multiple versions of a library, and applications
installing a version they need without consideration for other applications.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subje
> legality, since I think Sun's Java license says something like: If the user
> types "javac", they'd better get the compiler from the JDK.)
Unless they have trademarked "javac" they don't get to say what gets
run when a user types it. The only relevant license issue I know about
is about re-distributing jdk but only as long as no part is "replaced".
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
ge of
> legality, since I think Sun's Java license says something like: If the user
> types "javac", they'd better get the compiler from the JDK.)
Unless they have trademarked "javac" they don't get to say what gets
run when a user types it. The only relevant license issue I know about
is about re-distributing jdk but only as long as no part is "replaced".
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 Bothn
linker and Class.forName will
> agree -- it won't matter to the end program whether a class is loaded
> at runtime or at link time.
Do you have a write-up of this?
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
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 Bothn
linker and Class.forName will
> agree -- it won't matter to the end program whether a class is loaded
> at runtime or at link time.
Do you have a write-up of this?
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ative and .class files, JNI support,
debugging with gdb, compatibility and integration with other GNU
languages, and quickly growing maturity of libraries. As I said
before, I am surprised and disappointed that the Free Software
community has not supported Gcj better, but I think it may have
reached enough "critical mass" that more people will start using it.
(The Gcc 3.0 release should help.)
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
t can be compiled to native, because Red Hat should support gcj,
and Red Hat has not traditionally dealt with thousands of packages.
For Debian the choice might be different.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
native and .class files, JNI support,
debugging with gdb, compatibility and integration with other GNU
languages, and quickly growing maturity of libraries. As I said
before, I am surprised and disappointed that the Free Software
community has not supported Gcj better, but I think it may have
rea
Of course, the implementation for which the user has "java"
> selected by his $PATH is the one that should be used.
When compiling a Java application to native code, the executable should
preferably be a native program. Requiring an extra shell wrapper
is just extra clutter and overhead.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
t can be compiled to native, because Red Hat should support gcj,
and Red Hat has not traditionally dealt with thousands of packages.
For Debian the choice might be different.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Of course, the implementation for which the user has "java"
> selected by his $PATH is the one that should be used.
When compiling a Java application to native code, the executable should
preferably be a native program. Requiring an extra shell wrapper
is just extra clutter and overhead.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
installing gcj-compiled code, I would like to keep the gcj people in
the discussion. (Personally, I would like to see gcj become the
default free Java implementation for GNU/Linux. People seem to be
sadly unaware of it, including that it *does* include a VM, yet is
really coming together well now.)
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 maintainersh
installing gcj-compiled code, I would like to keep the gcj people in
the discussion. (Personally, I would like to see gcj become the
default free Java implementation for GNU/Linux. People seem to be
sadly unaware of it, including that it *does* include a VM, yet is
really coming together well now.)
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 maintainersh
sspaths.
(2) Java applications compiled with gcj automatically find the
necessary ,so files, without the users having to explicitly list
them on the gcj command line.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
sspaths.
(2) Java applications compiled with gcj automatically find the
necessary ,so files, without the users having to explicitly list
them on the gcj command line.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
eans lots of things are
missing, but that does not mean we would not like to add them. (For
example an optional JIT, complete AWT, other classes, JNI invocation
API, improved debugging support, more code optimization, flexible
configuration.)
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
eans lots of things are
missing, but that does not mean we would not like to add them. (For
example an optional JIT, complete AWT, other classes, JNI invocation
API, improved debugging support, more code optimization, flexible
configuration.)
--
--Per Bothner
[EMAIL PROTECTED] http://ww
1 - 100 of 119 matches
Mail list logo
