FYI: An OpenJDK bug regarding this has now been opened as well:
https://bugs.openjdk.org/browse/JDK-8307977
--
Best regards,
Per
On 2023-04-20 00:03, Vladimir Petko wrote:
Oh, thank you for providing a patch for a quite annoying bug
The pleasure is ours. :-) (I didn't write the patch myself but I helped
out a bit with the initial debugging)
Would it be possible to add a header to the patch, so that it is
possible
On 2023-04-19 10:22, Thorsten Glaser wrote:
On Tue, 18 Apr 2023, Per Lundberg wrote:
wanted to share it with you as well. One option would be to include this in
Debian's set of local JDK patches
Shouldn’t this be added to 11 as well? Apparently, both are affected.
Good point. Ye
-team/openjdk/-/tree/master/debian/patches),
but I don't know how conservative the project is re. fixes like this?
I'll leave this up to the debian-java maintainers to decide.
Best regards,
Per--- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
+++ b/src/jdk.attac
Sorry, was sent to the wrong address.
Forwarded Message
Subject: #897945 still present/breaks with Java 8
Date: Tue, 29 Jan 2019 11:40:42 +0200
From: Per Lundberg
To: 897...@bugs.debian.org
CC: pkg-java-maintain...@lists.alioth.debian.org, Markus Koschany
FWIW, version 1.4.2
Hi!
I updated the libjbcrypt-java package.
libjbcrypt-java (0.3-3) unstable; urgency=low
* Team upload.
* Remove build-depends-indep on default-jdk.
* Bumped standards version to 3.9.2, no changes.
* Add quilt patch for adding org.mindrot package.
-- Per Andersson Fri, 10 Feb 2012
On Wed, Apr 21, 2010 at 4:56 AM, tony mancill wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/20/2010 04:48 PM, Per Andersson wrote:
>> From: Per Andersson
>> To: debian-java@lists.debian.org
>> Subject: RFS: libjbcrypt-java
>>
>>
From: Per Andersson
To: debian-java@lists.debian.org
Subject: RFS: libjbcrypt-java
Dear debian-java,
I am looking for a sponsor for my package "libjbcrypt-java".
* Package name: libjbcrypt-java
Version : 0.3-1
Upstream Author : Damien Miller
* URL
Package: wnpp
Severity: wishlist
Owner: Per Andersson
* Package name: libjbcrypt-java
Version : 0.3
Upstream Author : Damien Miller
* URL : http://www.mindrot.org/projects/jBCrypt/
* License : ISC/BSD
Programming Lang: Java
Description : libjbcrypt
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
s has nothing to do with the debian meta information.
I believe Tom meant: If you find a problem where gij is command-line
incompatible with javac, then we consider that a bug in gij, not in the
debian packaging of gij, and so the bug should be reported to the "upstream"
maintainers - which means using gnats.
--Per
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
em where gij is command-line
incompatible with javac, then we consider that a bug in gij, not in the
debian packaging of gij, and so the bug should be reported to the "upstream"
maintainers - which means using gnats.
--Per
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
involved in maintaining Debian packages.
--Per
java-runtime.
Well, the gcj runtimes (libgcj or whatever the package name is)
should be fixed to provide java-runtime.
--Per Bothner
well I
don't know if any of them are involved in maintaining Debian packages.
--Per
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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]
1 - 100 of 132 matches
Mail list logo
