t up so it uses the standard Java
extensions directories. Tweaking some shell scripts or sym links
might work.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
java respectively (or
whatever becomes the policy). It is seems better to have a single
extensions directory (pair), rather than two.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
t up so it uses the standard Java
extensions directories. Tweaking some shell scripts or sym links
might work.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
java respectively (or
whatever becomes the policy). It is seems better to have a single
extensions directory (pair), rather than two.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
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
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]
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
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 [
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]
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
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/
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]
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
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
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]
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
/
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]
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]
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
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
work. One problem is different licenses. That does not
preclude someone donating the same or similar code to all of them,
but it does preclude whole-sale merging.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
that I've been able to find
goes into any depth about the text stuff.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
es,
especially C++, since we can think of Java as a subset of C++.
CNI is just a set of helper functions and conventions built on the
idea that C++ and Java have the *same* calling convention and
object layout; they are binary compatible. (This is a
simplification, but close enough.)
Bernd Kreimeier <[EMAIL PROTECTED]> writes:
> Question: will it be possible to mix JNI and CNI operations, per
> binary, or even interleaved in source?
The same executable has to be able to mix JNI and CNI, as Gcj will
continue to use CNI to call the core library methods. I think
ion.
>
> Where is the modification?
There is none. However, because Cygnus owns the copyright, they can
distribute the code udner a *different* license *simultaneously* to
different people/companies, if they wish.
Hopefully, with the news Anthony mentioned, this will soon no longer
be an
.cygnus.com/java/
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
t in Gdb for debugging any JVM that
supports the JVMDI. Unfortunately, the Gdb internals changed,
and the code was never merged into the Gdb main branch or
released.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
e foreseeable future.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
y would
open-source it. See http://www.sun.com/forte/tools4dotcom/opensource.html
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
list, though.
I assume the CpNNN ones as Windows "Code Pages". I know what
many of the others are, or can guess.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
Error
if there is a bug in the Kaffe implementation, since the standard
classes are not allowed to change interfaces.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
tation.
The license for the documentation is:
http://java.sun.com/j2se/1.3/docs/relnotes/SMICopyright.html
Now that license does have some problems, but that is another discussion.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
"Ean R . Schuessler" <[EMAIL PROTECTED]> writes:
> On Tue, Jul 04, 2000 at 11:00:18PM -0700, Per Bothner wrote:
> > The license for the documentation is:
> > http://java.sun.com/j2se/1.3/docs/relnotes/SMICopyright.html
> > Now that license does ha
rovocative. Of course one can build a
serious application without java.security. One can even build a
secure application without it, though java.security gives you better
control. A compiler, a word-processor, an editor, or any single-user
application should not to deal with security concerns.
--
d innunendos?
(Note I am not particularly interested in the success of Kaffe,
given my association with Gcj, which can be viewed as a Kaffe
competitor.)
--
--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://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/
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
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 ge
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/
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/
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
> 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/
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/
he size of a .so isn't
enough to worry about.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
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
$(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/
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
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
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
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.
--
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
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/default-classp
ng server-style or other non-GUI application, I suggest
you try it. See htpp://gcc.gnu.org/java/
--Per Bothner
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
java-runtime.
Well, the gcj runtimes (libgcj or whatever the package name is)
should be fixed to provide java-runtime.
--Per Bothner
involved in maintaining Debian packages.
--Per
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
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:
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
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/
;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.
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/
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
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]
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
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/
#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/
t *should* use
/usr/share/java/ext as the default such directory.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
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
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
tation.
The license for the documentation is:
http://java.sun.com/j2se/1.3/docs/relnotes/SMICopyright.html
Now that license does have some problems, but that is another discussion.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/~per/
--
To UNSUBSCRIBE, email to [EMA
"Ean R . Schuessler" <[EMAIL PROTECTED]> writes:
> On Tue, Jul 04, 2000 at 11:00:18PM -0700, Per Bothner wrote:
> > The license for the documentation is:
> > http://java.sun.com/j2se/1.3/docs/relnotes/SMICopyright.html
> > Now that license does ha
f course one can build a
serious application without java.security. One can even build a
secure application without it, though java.security gives you better
control. A compiler, a word-processor, an editor, or any single-user
application should not to deal with security concerns.
--
--Per
d innunendos?
(Note I am not particularly interested in the success of Kaffe,
given my association with Gcj, which can be viewed as a Kaffe
competitor.)
--
--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://ww
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]
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
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 ge
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]
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]
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
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]
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
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]
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
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]
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
$(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
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
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
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
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]
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.
--
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
1 - 100 of 132 matches
Mail list logo
