Re: Release [Was: Orp does zip files]
Brian Jones wrote: > > Anything else left to do before releasing? I'm going to tag the > source tree when it is definite. You mentioned updating the INSTALL > file for jikes. I'm good to go. Jikes 1-15b is now up and running on its CVS server, and Classpath's INSTALL and HACKING have been updated accordingly. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Orp does zip files
Mark Wielaard <[EMAIL PROTECTED]> writes: > Hi, > > I complained to Brian that the new make install only installed the > glibj.zip file but not the class files which I thought were neccessary > for Orp. Silly me. Orp 1.0.9 added support for reading classes from zip > files. So I have updated the GNU Classpath and ORP page > http://www.gnu.org/software/classpath/doc/orp.html > to mention this fact. Anything else left to do before releasing? I'm going to tag the source tree when it is definite. You mentioned updating the INSTALL file for jikes. make install should handle zip or no zip now. Let me know if you have other problems. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Orp does zip files
Hi, I complained to Brian that the new make install only installed the glibj.zip file but not the class files which I thought were neccessary for Orp. Silly me. Orp 1.0.9 added support for reading classes from zip files. So I have updated the GNU Classpath and ORP page http://www.gnu.org/software/classpath/doc/orp.html to mention this fact. Just thought to mail it to the list so people know to adjust their classpath (and don't make a fool out of themselves by mailing bogus complaints to Brian...) Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Draft release announcement (please comment)
Hi, On Sat, 2002-02-09 at 23:58, Bryce McKinlay wrote: > > I think this part sounds a bit too pessimistic. How about something like: > > 5). Who should use this software? > > Although it is already capable of supporting many Java applications, > this is a development release. As such, there are still many unfinished > components, and some problems are to be expected. You should install it > if you are interested in Classpath development or reporting bugs. We > appreciate both. Thanks. Sounds much better. I have added it to the announcement text. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Compiling with jikes > 1.13
Mark Wielaard wrote: > > Yes, could you please also add a note in the INSTALL file about this > version (were to get it and that the jikes developers recommend this > version for compiling Classpath, etc, etc.) OK, that will be my next patch. > I can generate binaries for > GNU/Linux x86 and powerpc if you want. That would be nice, except that I only have CVS write access for jikes, not access to the project web site, so I can't post any binaries or tarballs. The way I see it, if someone is willing to download Classpath, it won't kill them to build their own version of jikes from CVS. > > > Shall I go ahead and commit the patch? > > Yes please. But could you please explicitly mark these as "FIXME > workaround for bug" in the source code so we don't > accidentially remove them again in the future (for example when we > remerge with libgcj). And could you in the future please separate > indentation formating from code change, that make the diffs easier to > read. The workarounds are committed, and separately from formatting changes. By the way, in the source code I only commented about the method inheritance workaround. Adding a non-private constructor to private inner classes is a good idea even if it weren't a compiler workaround, since it results in less bytecode (the compiler would have had to generate a synthetic non-private constructor anyways in addition to the implicit private one). -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Draft release announcement (please comment)
Mark Wielaard wrote: > > 5). Who should use this software? > > This is a development release only. You should only install it if you are > interested in Classpath development or reporting bugs. We appreciate both. > You might also be interested if you enjoy installing random alpha > software. > I think this part sounds a bit too pessimistic. How about something like: 5). Who should use this software? Although it is already capable of supporting many Java applications, this is a development release. As such, there are still many unfinished components, and some problems are to be expected. You should install it if you are interested in Classpath development or reporting bugs. We appreciate both. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Crash in java_lang_Double.c with kissme
On Sat, Feb 09, 2002 at 02:41:00PM -0500, Brian Jones wrote: > John Leuner <[EMAIL PROTECTED]> writes: > > > The code in java_lang_Double.c was crashing with my JVM (kissme) > > because it was failing to recognise the infinity values. > > > > The following patch fixes the crash, but there are still many mauve > > failures (which might be causes by kissme or classpath) > > > > The comparison was failing even though the two values have the same > > binary value (when printed out in gdb). > > I think I tested this with ORP and Mauve quite a bit. Yeah, I need to investigate more. It probably has to do with the code that loads Doubles from the constant pool. John Leuner ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Crash in java_lang_Double.c with kissme
John Leuner <[EMAIL PROTECTED]> writes: > The code in java_lang_Double.c was crashing with my JVM (kissme) > because it was failing to recognise the infinity values. > > The following patch fixes the crash, but there are still many mauve > failures (which might be causes by kissme or classpath) > > The comparison was failing even though the two values have the same > binary value (when printed out in gdb). I think I tested this with ORP and Mauve quite a bit. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build question
Tom Tromey <[EMAIL PROTECTED]> writes: > > "Eric" == Eric Blake <[EMAIL PROTECTED]> writes: > > Eric> It has to be line terminator translation somewhere, because this > Eric> hack to automake makes everything work for me. > > Thanks for looking into this. > I'll see if we can come up with a better patch. > Would you mind testing one when it is available? > We're planning to release automake 1.6 shortly, and I'd like to make > sure this bug is fixed in that release. It may just be that Eric needed to mount the drive/directory in binmode instead of textmode in cygwin or that the CYGWIN environment variable needed 'binmode' in it. You can of course make automake more immune to this problem and that's good too. -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Crash in java_lang_Double.c with kissme
The code in java_lang_Double.c was crashing with my JVM (kissme) because it was failing to recognise the infinity values. The following patch fixes the crash, but there are still many mauve failures (which might be causes by kissme or classpath) The comparison was failing even though the two values have the same binary value (when printed out in gdb). Index: native/jni/java-lang/java_lang_Double.c === RCS file: /cvsroot/classpath/classpath/native/jni/java-lang/java_lang_Double.c,v retrieving revision 1.8 diff -u -r1.8 java_lang_Double.c --- native/jni/java-lang/java_lang_Double.c 22 Jan 2002 22:27:02 - 1.8 +++ native/jni/java-lang/java_lang_Double.c 9 Feb 2002 19:25:11 - @@ -149,6 +149,9 @@ char *s, *d; int i; + memset(buffer, 0, sizeof(buffer)); + memset(result, 0, sizeof(result)); + #ifdef DEBUG fprintf (stderr, "java.lang.Double.toString (%g)\n", value); #endif @@ -156,10 +159,10 @@ if ((*env)->CallStaticBooleanMethod(env, cls, isNaNID, value)) return (*env)->NewStringUTF(env, "NaN"); - if (value == POSITIVE_INFINITY) + if ((long long) value == (long long) POSITIVE_INFINITY) return (*env)->NewStringUTF(env, "Infinity"); - if (value == NEGATIVE_INFINITY) + if ((long long) value == (long long) NEGATIVE_INFINITY) return (*env)->NewStringUTF(env, "-Infinity"); _dtoa (value, 0, 20, &decpt, &sign, NULL, buffer, (int)isFloat); ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build question
> "Eric" == Eric Blake <[EMAIL PROTECTED]> writes: Eric> It has to be line terminator translation somewhere, because this Eric> hack to automake makes everything work for me. Thanks for looking into this. I'll see if we can come up with a better patch. Would you mind testing one when it is available? We're planning to release automake 1.6 shortly, and I'd like to make sure this bug is fixed in that release. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: build question
Tom Tromey wrote:
>
> > "Eric" == Eric Blake <[EMAIL PROTECTED]> writes:
>
> Eric> automake: native/jni/java-lang/Makefile.am: `\' is not a standard
> Eric> libtool library name
>
> This is curious. This error shouldn't happen. Apparently what is
> happening here is that automake thinks that the `\' continuation
> character in the definition of pkglib_LTLIBRARIES is supposed to be
> the name of a library.
>
> I can't reproduce this problem here. Since you are using Cygwin,
> which most of us aren't, perhaps the problem is somehow related to
> that. For instance, it could be a line termination problem.
>
> Could you investigate this for me? I'd like to fix automake.
It has to be line terminator translation somewhere, because this hack to
automake makes everything work for me. I'm sure you could find a more
elegant way to fix the problem, and that the real fix should be upstream
in the sources rather than in the final executable; however, I'm not
familiar enough with the automake sources and/or perl to suggest a
better fix.
$ diff -u automake.bak automake
--- automake.bakSat Feb 9 10:35:42 2002
+++ automakeSat Feb 9 11:31:48 2002
@@ -6455,6 +6455,7 @@
while ($_ = $am_file->getline)
{
+s/\r\n/\n/g;
if (/$IGNORE_PATTERN/o)
{
# Merely delete comments beginning with two hashes.
@@ -6498,6 +6499,7 @@
# FIXME: shouldn't use $_ in this loop; it is too big.
while ($_)
{
+s/\r\n/\n/g;
$_ .= "\n"
unless substr ($_, -1, 1) eq "\n";
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Undocumented values of documented final fields
> "arenn" == arenn <[EMAIL PROTECTED]> writes:
>> does Classpath aim to provide the same values for final fields as the Sun
>> JDK implementation does, even if the concrete value is not part of the
>> specification?
This is required. Otherwise the "write once run anywhere" feature of
Java is compromised.
arenn> In short, yes. I've captured these values in the past by
arenn> writing short programs that dump them to stdout.
In libgcj we have a simple program that uses reflection to print
integer values. I've appended this. This can be really useful when
you have a lot of such constants.
Tom
// Show a value given class name and constant name.
/* Copyright (C) 2000 Free Software Foundation
This file is part of libgcj.
This software is copyrighted work licensed under the terms of the
Libgcj License. Please consult the file "LIBGCJ_LICENSE" for
details. */
/* Written by Tom Tromey <[EMAIL PROTECTED]>. */
// Use like this to print a `static final' value (integers only, not
// strings yet):
// java showval java.awt.geom.AffineTransform.TYPE_IDENTITY
// Prints result like:
// TYPE_IDENTITY = 0
// In conjunction with a keyboard macro you can do a number of
// constants very easily.
import java.lang.reflect.*;
public class showval
{
public static void main (String[] args)
{
int ch = args[0].lastIndexOf ('.');
String className = args[0].substring (0, ch);
String constName = args[0].substring (ch + 1);
try
{
Class klass = Class.forName (className);
Field field = klass.getField (constName);
System.out.println (constName + " = " + field.getInt (null));
}
catch (Throwable _)
{
System.out.println (_);
}
}
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: The release
Mark Wielaard <[EMAIL PROTECTED]> writes: > Hi, > > It is Saturday already (for me) and I did not do everything I wanted to > for the release (fix last build glitches and try some bigger tests/setup > mauve). I can spend some time tomorrow to polish it a bit more and test > it better. But it is already much, much better then the 0.02 release > that we have now (and which people still seem to download now and then). > > Brian, if you just want to make a release now please go ahead and I will > do the announcements first thing in the morning. If you think it can use > some more polish (it can probably always use some more polish) then I > will try to polish it some more tomorrow. I'm fixing that header stuff, not quite done. I also need to grab the new jikes when it is tagged and ready. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Undocumented values of documented final fields
Sascha Brawer ([EMAIL PROTECTED]) wrote: > does Classpath aim to provide the same values for final fields as the Sun > JDK implementation does, even if the concrete value is not part of the > specification? > > Context: I am currently working on java.util.logging, and the > documentation of the Logging API does not specify the integer values for > the standard logging levels -- for example the result of > java.util.logging.Level.WARNING.intValue(). My question is not specific > to java.util.logging, though. In short, yes. I've captured these values in the past by writing short programs that dump them to stdout. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/ "We have a choice, either to change the way we live, which is unacceptable, or to change the way that they live, and we chose the latter." - Sec. of Defense Donald Rumsfeld, News briefing, 2001-09-18 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: can't compile with SUN's javac
Hi, Mark. From: Mark Wielaard <[EMAIL PROTECTED]> Subject: Re: can't compile with SUN's javac Date: 09 Feb 2002 15:31:44 +0100 > We don't officially support the Sun javac compiler (there are now > multiple free compilers). But these errors seem real and I will fix the > code (although I think the compiler could just issue a warning here). > > Which version of Sun javac is this? > In the past the Sun compilers didn't like to compile some of the core > classes. I use jdk1.3.1_02 on linux. $ java -version java version "1.3.1_02" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02) Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode) best regards. Takashi Okamoto ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Undocumented values of documented final fields
Hi, does Classpath aim to provide the same values for final fields as the Sun JDK implementation does, even if the concrete value is not part of the specification? Context: I am currently working on java.util.logging, and the documentation of the Logging API does not specify the integer values for the standard logging levels -- for example the result of java.util.logging.Level.WARNING.intValue(). My question is not specific to java.util.logging, though. -- Sascha Brawer, [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Compiling with jikes > 1.13
Hi, On Sat, 2002-02-09 at 10:24, Eric Blake wrote: > > Name: verify-jikes.libgcj > > It looks like all the errors listed in this file were "incompatible type > on stack", in other words, side effects of your ClassLoader hack. Yeah. Sorry about all the false positives. It did show some bugs in the libgcj verifier earlier though, so it was not a complete waste. > >Name: verify-jikes.gcj > > I have addressed all the errors listed in this file. With the attached > patch and the latest CVS version of jikes (as of 9:15 am UTC Feb 9), > this should be completely resolved. If you agree with me, then I will > tag the current version of jikes CVS as stable, and bump the version to > 1.15b. Yes, could you please also add a note in the INSTALL file about this version (were to get it and that the jikes developers recommend this version for compiling Classpath, etc, etc.) I can generate binaries for GNU/Linux x86 and powerpc if you want. > Shall I go ahead and commit the patch? Yes please. But could you please explicitly mark these as "FIXME workaround for bug" in the source code so we don't accidentially remove them again in the future (for example when we remerge with libgcj). And could you in the future please separate indentation formating from code change, that make the diffs easier to read. This great, you even put in some workaround for gcj which now enables me to get around the problem I had with ORP and gcj compiled classes when testing DatagramSocket. Thanks, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: can't compile with SUN's javac
Hi, On Sat, 2002-02-09 at 10:55, Takashi Okamoto wrote: > > I can't compile classpath with SUN's javac. I got following messages. > When I added 'this.' before pointed-out place, I could compile them. We don't officially support the Sun javac compiler (there are now multiple free compilers). But these errors seem real and I will fix the code (although I think the compiler could just issue a warning here). Which version of Sun javac is this? In the past the Sun compilers didn't like to compile some of the core classes. Thanks, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
can't compile with SUN's javac
Hello,classpath. I can't compile classpath with SUN's javac. I got following messages. When I added 'this.' before pointed-out place, I could compile them. regards. Takashi Okamoto # javac -classpath .:vm/reference -d classes `find java gnu/java gnu/tools gnu/classpath gnu/vm -name "*.java"` arpa:/usr/local/tmp/classpath# LANG=C javac -classpath .:vm/reference -d classes `find java gnu/java gnu/tools gnu/classpath gnu/vm -name "*.java"` java/util/Arrays.java:2433: equals(java.lang.Object,java.lang.Object) is inherited from java.util.AbstractCollection and hides method in outer class java.util.Arrays. An explicit 'this' qualifier must be used to select the desired instance. if (equals(o, a[i])) ^ java/util/Arrays.java:2442: equals(java.lang.Object,java.lang.Object) is inherited from java.util.AbstractCollection and hides method in outer class java.util.Arrays. An explicit 'this' qualifier must be used to select the desired instance. if (equals(o, a[i])) ^ java/util/WeakHashMap.java:486: get() is inherited from java.lang.ref.Reference and hides method in outer class java.util.WeakHashMap. An explicit 'this' qualifier must be used to select the desired instance. final Object key = get(); ^ 3 errors ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Compiling with jikes > 1.13
Mark Wielaard wrote:
>
> The rest of the verify output follows, but I have not analysed it yet.
>
> Cheers,
>
> Mark
>
>
> Name: verify-jikes.libgcj
>verify-jikes.libgcjType: Plain Text (text/plain)
> Encoding: quoted-printable
It looks like all the errors listed in this file were "incompatible type
on stack", in other words, side effects of your ClassLoader hack.
>
>Name: verify-jikes.gcj
>verify-jikes.gcjType: Plain Text (text/plain)
>Encoding: quoted-printable
I have addressed all the errors listed in this file. With the attached
patch and the latest CVS version of jikes (as of 9:15 am UTC Feb 9),
this should be completely resolved. If you agree with me, then I will
tag the current version of jikes CVS as stable, and bump the version to
1.15b. Shall I go ahead and commit the patch?
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
2002-02-09 Eric Blake <[EMAIL PROTECTED]>
* java/net/DatagramSocketImpl.java (setOption, getOption): Work
around gcj bug of wrong emitted qualifier for inherited method.
* java/net/SocketImpl.java (setOption, getOption): Ditto.
* java/util/WeakHashMap.java (WeakEntrySet): Work around jikes
1.15 bug of private constructors in inner classes.
* java/rmi/server/RMIClassLoader.java (MyClassLoader): Ditto.
* gnu/java/rmi/server/UnicastRemoteCall.java
(DummyObjectOutputStream, DummyObjectInputStream): Ditto.
Index: java/net/DatagramSocketImpl.java
===
RCS file: /cvsroot/classpath/classpath/java/net/DatagramSocketImpl.java,v
retrieving revision 1.11
diff -u -r1.11 DatagramSocketImpl.java
--- java/net/DatagramSocketImpl.java22 Jan 2002 22:27:00 - 1.11
+++ java/net/DatagramSocketImpl.java9 Feb 2002 09:17:31 -
@@ -1,5 +1,5 @@
/* DatagramSocketImpl.java -- Abstract class for UDP socket implementations
- Copyright (C) 1998, 1999 2000, 2001 Free Software Foundation, Inc.
+ Copyright (C) 1998, 1999 2000, 2001, 2002 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -203,4 +203,34 @@
{
return localPort;
}
+
+ /**
+ * Sets the specified option on a socket to the passed in object. For
+ * options that take an integer argument, the passed in object is an
+ * Integer. For options that are set to on or off, the
+ * value passed will be a Boolean. The option_id
+ * parameter is one of the defined constants in the superinterface.
+ *
+ * @param option_id The identifier of the option
+ * @param val The value to set the option to
+ *
+ * @exception SocketException If an error occurs
+ */
+ public abstract void setOption(int option_id, Object val)
+throws SocketException;
+
+ /**
+ * Returns the current setting of the specified option. The
+ * Object returned will be an Integer for options
+ * that have integer values. For options that are set to on or off, a
+ * Boolean will be returned. The option_id
+ * is one of the defined constants in the superinterface.
+ *
+ * @param option_id The option identifier
+ *
+ * @return The current value of the option
+ *
+ * @exception SocketException If an error occurs
+ */
+ public abstract Object getOption(int option_id) throws SocketException;
}
Index: java/net/SocketImpl.java
===
RCS file: /cvsroot/classpath/classpath/java/net/SocketImpl.java,v
retrieving revision 1.7
diff -u -r1.7 SocketImpl.java
--- java/net/SocketImpl.java22 Jan 2002 22:27:00 - 1.7
+++ java/net/SocketImpl.java9 Feb 2002 09:17:31 -
@@ -1,5 +1,5 @@
/* SocketImpl.java -- Abstract socket implementation class
- Copyright (C) 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
+ Copyright (C) 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -234,4 +234,34 @@
return "[addr=" + address.toString() + ",port=" + Integer.toString(port) +
",localport=" + Integer.toString(localport) + "]";
}
+
+ /**
+ * Sets the specified option on a socket to the passed in object. For
+ * options that take an integer argument, the passed in object is an
+ * Integer. For options that are set to on or off, the
+ * value passed will be a Boolean. The option_id
+ * parameter is one of the defined constants in the superinterface.
+ *
+ * @param option_id The identifier of the option
+ * @param val The value to set the option to
+ *
+ * @exception SocketException If an error occurs
+ */
+ public abstract void setOption(int option_id, Object val)
+throws SocketException;
+
+ /**
+ * Returns the current settin
