Re: Compiling with jikes > 1.13
Eric Blake wrote: > > Mark Wielaard wrote: > > > > And this time it actually had a valid VerifyError! > > This new jikes is a bit to clever about String concatenations. > > I'll fix that today, and repost here when it is up. I committed that patch to Jikes' CVS earlier today, fixing the VerifyErrors with string concatenation. I'm trying to get one more patch through the test suite and in CVS by tomorrow morning, then I'll take a look at the other verify errors you reported. My gut feeling is that we may have to make some private constructors in inner classes more accessible as a temporary workaround, until jikes 1.16 is released. -- 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
AWT components ?
Hi, I've foud a project called KJC, which is a set of AWT components that were designed to bring Swing-like abilities to applets. It doesn't seems to be maintained any more, but the license is "open" and perhaps the author could give it to the FSF ? I haven't looked at the source but we could perhaps find some usefull stuff ? Here is the link : http://openlab.ring.gr.jp/kyasu/ Cheers, yann. -- / Yann SECQEquipe SMAC [EMAIL PROTECTED] \ | Multi-Agent Systems Modeling & Agent Oriented Programming | \ http://www.lifl.fr/SMAChttp://www.lifl.fr/~secq / ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Compiling with jikes > 1.13
Eric Blake <[EMAIL PROTECTED]> writes: > Eric Blake wrote: > > > > Mark Wielaard wrote: > > > > > > And this time it actually had a valid VerifyError! > > > This new jikes is a bit to clever about String concatenations. > > > > I'll fix that today, and repost here when it is up. > > I committed that patch to Jikes' CVS earlier today, fixing the > VerifyErrors with string concatenation. I'm trying to get one more > patch through the test suite and in CVS by tomorrow morning, then I'll > take a look at the other verify errors you reported. My gut feeling is > that we may have to make some private constructors in inner classes more > accessible as a temporary workaround, until jikes 1.16 is released. Let me know what I should pull from jikes cvs to compile with for the official release. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Hi Brian, On Fri, 2002-02-08 at 06:00, Brian Jones wrote: > For me, make distcheck fails for unknown reasons at this time distcheck fails for me with a 'Error: files left after uninstall' since all files (classes) that where unpacked from the zip file are still in the install directory after an uninstall. That is annoying but not very bad. > I've placed a pre-release file at > ftp://alpha.gnu.org/gnu/classpath/classpath-0.03-pre1.tar.gz Tried it on my main development machine and compiling went all OK. But when trying out orp I got $ mains/orp/Linux/dbg/orp -swapjit 0 1 -classpath $CLASSPATH Hello Linking error: (6) while resolving method at constant pool index 33 in class gnu/java/io/encode/Encoder8859_1 Linking error: (6) while resolving method at constant pool index 33 in class gnu/java/io/encode/Encoder8859_1 Fatal error: can't compile gnu/java/io/encode/Encoder8859_1.()V I am going to check what went wrong. When I tried the build on a machine without jikes and zip installed something went wrong. The build automatically used gcj to compile the classes (good). But since $(ZIP) was not defined it then gave the following error: r -D glibj.zip gnu java javax > /dev/null /bin/sh: r: command not found make[1]: [glibj.zip] Error 127 (ignored) configure should complain about the absence of zip. > In the time I have, I could not make it possible > to include generated JNI header files, so a user would need gcjh if > configuring with --enable-jni I don't think that is a very big problem. Most people that are trying Classpath now probably have gcc installed. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Hi, On Fri, 2002-02-08 at 15:42, Mark Wielaard wrote: > $ mains/orp/Linux/dbg/orp -swapjit 0 1 -classpath $CLASSPATH Hello > > Linking error: (6) while resolving method at constant pool index 33 > in class gnu/java/io/encode/Encoder8859_1 > > Linking error: (6) while resolving method at constant pool index 33 > in class gnu/java/io/encode/Encoder8859_1 > > Fatal error: can't compile gnu/java/io/encode/Encoder8859_1.()V > > I am going to check what went wrong. OK. Ignore me. I still had the jikes with the StringBuffer.append bug in my path. Reconfigure with jikes 1.15 and everything works. I will try the new jikes from CVS now. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Hi, On Fri, 2002-02-08 at 16:20, Mark Wielaard wrote: > > OK. Ignore me. I still had the jikes with the StringBuffer.append bug in > my path. Reconfigure with jikes 1.15 and everything works. > > I will try the new jikes from CVS now. Same problem :( I have not yet figured out if it is a jikes compiler problem or a ORP jit problem. The StingBuffer.append() bug is gone though. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Trouble with gcj 3.0.4 (BasicPermission.java)
Hi, When testing the pre-release tarbal with gcj 3.0.4 20020202 (Debian prerelease) I got the following: /usr/bin/gcj -C -d . @classes ./../java/security/BasicPermission.java:64: Class `java.security.BasicPermission' can't subclass interface `java.security.acl.Permission'. public abstract class BasicPermission extends Permission implements ^ The released version of gcj (3.0.3) does not have this strange bug. Changing Permission to java.security.Permission solves it. Strangely enough I only have this with the release tarbal not with the cvs tree. Hmmm. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Hi, On Fri, 2002-02-08 at 16:43, Mark Wielaard wrote: > > I will try the new jikes from CVS now. > > Same problem :( > I have not yet figured out if it is a jikes compiler problem or a ORP > jit problem. The problem seems to come from the fact that jikes 1.15 (and gcj) generate things like: 1804: invokestatic #34= But jikes 1.15a (from CVS) generates: 1804: invokestatic #33= Since loadTable() is a static method in (the superclass) EncoderEightBitLookup not in (the subclass) Encoder8859_1 it seems that jikes 1.15a generates wrong code in this case. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Trouble with gcj 3.0.4 (BasicPermission.java)
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes: Mark> /usr/bin/gcj -C -d . @classes Mark> ./../java/security/BasicPermission.java:64: Class Mark> `java.security.BasicPermission' can't subclass interface Mark> `java.security.acl.Permission'. Mark>public abstract class BasicPermission extends Permission implements Mark> ^ Mark> The released version of gcj (3.0.3) does not have this strange bug. Mark> Changing Permission to java.security.Permission solves it. You'll have to work around it. 3.0.4 is perhaps the last of the 3.0 releases (hard to be certain). 3.1 is due in April. The gcj hackers aren't really fixing bugs in 3.0 at all any more; I have that tree checked out for reference but I haven't built it in many months. For problems like this, where the fix is something we wouldn't write from scratch and is just a workaround for a current compiler problem, I would prefer that we only have the fix in this particular Classpath release. So the idea would be that we make a release branch and then add the workarounds there. My idea here is that in the long term we'd prefer the existing code, as it is "more natural", and perhaps by the time the next Classpath release comes around we won't have to worry about this particular compiler any more. What do you think? Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Actually, the bug was in jikes 1.15, and is still in the jit. JLS 13
requires that compilers emit method references relative to the class
that qualifies the method invocation, even if that class only inherits
the method. It is then up to the VM to correctly track inheritance
issues when resolving method calls. Sun's javac 1.3 also had this bug,
JDK 1.4 compiles the way jikes 1.15a does (ie. Encoder8859_1.loadTable).
It makes a difference in this example:
in A.java:
class A
{
static void m() { System.out.print("a"); }
}
in B.java:
class B extends A {}
in C.java:
class C
{
public static void main(String[] args)
{
B.m();
}
}
Now, recompile B.java:
class B extends A
{
static void m() { System.out.print("b"); }
}
The result of executing the (unchanged) C.class should now be "b", not
"a".
This is also the reason that Sun's javap program will often list null as
the method or field name for classes compiled with javac 1.4, because
they have not yet fixed javap to take inheritance into account.
Mark Wielaard wrote:
>
>
> The problem seems to come from the fact that jikes 1.15 (and gcj)
> generate things like:
> 1804: invokestatic #34= gnu.java.io.encode.EncoderEightBitLookup.loadTable ()void>
>
> But jikes 1.15a (from CVS) generates:
> 1804: invokestatic #33= gnu.java.io.encode.Encoder8859_1.loadTable ()void>
>
> Since loadTable() is a static method in (the superclass)
> EncoderEightBitLookup not in (the subclass) Encoder8859_1 it seems that
> jikes 1.15a generates wrong code in this case.
>
> Cheers,
>
> Mark
--
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: Trouble with gcj 3.0.4 (BasicPermission.java)
Hi, On Fri, 2002-02-08 at 20:11, Tom Tromey wrote: > > For problems like this, where the fix is something we wouldn't write > from scratch and is just a workaround for a current compiler problem, > I would prefer that we only have the fix in this particular Classpath > release. So the idea would be that we make a release branch and then > add the workarounds there. My idea here is that in the long term we'd > prefer the existing code, as it is "more natural", and perhaps by the > time the next Classpath release comes around we won't have to worry > about this particular compiler any more. What do you think? I think a branch is a little over the top for this release. We have some other workarounds in the current tree for compiler problems. e.g. java/lang/reflect/Proxy.java: // FIXME workaround for bug in gcj 3.0.x java/util/TreeMap.java: // FIXME gcj cannot handle this. Bug java/4695 And I think some compilers versions might be much longer around then we hope (just look at all the different versions of jikes that people are still using). So I will just commit the workaround with the words FIXME, gcj, workaround and/or bug. The workaround is to simply use the fully qualified classname in this case and that doesn't matter for other compiler (versions). Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Hi Eric, On Fri, 2002-02-08 at 20:14, Eric Blake wrote: > Actually, the bug was in jikes 1.15, and is still in the jit. JLS 13 > requires that compilers emit method references relative to the class > that qualifies the method invocation, even if that class only inherits > the method. It is then up to the VM to correctly track inheritance > issues when resolving method calls. Sun's javac 1.3 also had this bug, > JDK 1.4 compiles the way jikes 1.15a does (ie. Encoder8859_1.loadTable). That (and the example) seems to make sense. But it also means that we don't have one bug in jikes, but two bugs, one in ORP and one in gcj byte code generation. Sigh. That basicly means we don't recommend jikes 1.15a for this Classpath release and ORP 1.0.9, or we wait for a new ORP release with a fix. H. I would opt for releasing now and adding a note about this problem (with newer versions of jikes and ORP) to the README/INSTALL file. Or we could try to produce a patch for ORP, but I am not sure that is very easy. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Keep in mind that a workaround for this is to explicitly qualify the
method with the desired class (ie. the one where the method is actually
defined).
In other words, instead of
Encoder8859_1.loadTable()
in the source code, use
EncoderEightBitLookup.loadTable()
The only problem I see with this approach is if EncoderEightBitLookup is
not accessible when Encoder8859_1 is. Then an alternative workaround
would be to modify Encoder8859_1 by adding this method:
public static void loadTable() { super.loadTable(); }
I'm not familiar with the ORP code, but these workarounds shouldn't be
too hard.
Do you want me to file a PR for the gcc bug? I've yet to get a working
compile of gcj on my cygwin box, so I'm not sure how well I would do on
bug reporting.
Mark Wielaard wrote:
>
> That (and the example) seems to make sense. But it also means that we
> don't have one bug in jikes, but two bugs, one in ORP and one in gcj
> byte code generation. Sigh.
>
> That basicly means we don't recommend jikes 1.15a for this Classpath
> release and ORP 1.0.9, or we wait for a new ORP release with a fix.
> H. I would opt for releasing now and adding a note about this
> problem (with newer versions of jikes and ORP) to the README/INSTALL
> file. Or we could try to produce a patch for ORP, but I am not sure that
> is very easy.
>
> Cheers,
>
> Mark
--
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: make dist fixes
Hi, On Sat, 2002-02-09 at 02:16, Eric Blake wrote: > Keep in mind that a workaround for this is to explicitly qualify the > method with the desired class (ie. the one where the method is actually > defined). > > In other words, instead of > Encoder8859_1.loadTable() > in the source code, use > EncoderEightBitLookup.loadTable() O boy, a workaround that can be put in the Classpath code. And it works! (for HelloWorld, I still haven't setup Mauve for more extensive testing). Great! I can checkin that workaround for the encode/decode code. What are your thoughts on jikes 1.15a (CVS) is it better then jikes 1.15? Do you want to make a (semi) release of that code? > I'm not familiar with the ORP code, but these workarounds shouldn't be > too hard. I did look briefly at the ORP code and it isn't that dificult. The code can be found in common/class_loader/Resolve.cpp and Class.cpp. I think I understand what goes wrong (the method gets looked up by going up in the class hierarchy, but then the constant pool of the original referenced class seems to be used) but I haven't actually tried to change/fix the code. > Do you want me to file a PR for the gcc bug? I've yet to get a working > compile of gcj on my cygwin box, so I'm not sure how well I would do on > bug reporting. I think your explanation plus example is good enough to put in the bug database (maybe with a reference to the email that showed the bytecode). That way the issue will not be forgotten. I am afraid that gcj does not yet compile on cygwin, although there is currently a lot of work done to get it to compile on Windows (if mingw is the same kind of thing as cygwin). Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes: Mark> That (and the example) seems to make sense. But it also means Mark> that we don't have one bug in jikes, but two bugs, one in ORP Mark> and one in gcj byte code generation. Sigh. If you have the time, would you mind constructing a test case so we can see if gij also has the runtime bug? I'd appreciate that. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes: Mark> I think your explanation plus example is good enough to put in Mark> the bug database (maybe with a reference to the email that Mark> showed the bytecode). I concur. Eric's email was certainly enough for me to understand the problem. Eric, would you mind simply pasting the text of your email into a new gcj Gnats PR? Mark> I am afraid that gcj does not yet compile on cygwin, although Mark> there is currently a lot of work done to get it to compile on Mark> Windows (if mingw is the same kind of thing as cygwin). Sort of. Adam's work is targeted at being able to build a linux-x-mingw toolchain. This means you'll be able to run gcj on Linux and have it generate a Windows executable. After his work you still won't be able to build a native Cygwin (or Windows) compiler. There are still some remaining compiler bugs relating to case-insensitive file systems. (The ongoing Darwin port avoids this by requiring you to use a case-sensitive fs.) (The bugs are probably not too hard to fix, but nobody has seriously looked into it.) Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Trouble with gcj 3.0.4 (BasicPermission.java)
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes: Mark> I think a branch is a little over the top for this release. Perhaps. I think someday we'll have to do branches. Sometimes it is helpful to work out the process before you really need it. (With automake I found I didn't know I needed a branch until it was too late... so obviously that experience colors my perception.) Mark> So I will just commit the workaround with the words FIXME, gcj, Mark> workaround and/or bug. Works for me, thanks. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: make dist fixes
Hi,
On Sat, 2002-02-09 at 03:51, Tom Tromey wrote:
> > "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
>
> Mark> That (and the example) seems to make sense. But it also means
> Mark> that we don't have one bug in jikes, but two bugs, one in ORP
> Mark> and one in gcj byte code generation. Sigh.
>
> If you have the time, would you mind constructing a test case so we
> can see if gij also has the runtime bug? I'd appreciate that.
Simple tests don't show the bug with either orp or gij (it must be
something special about gnu/java/io/encode/Encoder8859_* (the workaround
that Eric posted does work though). But the following Test which fails
with orp seems to succeed with gij.
public class Test
{
public static void main(String[] args)
{
new gnu.java.io.encode.Encoder8859_1(null);
}
}
A quick look in interpret.cc and resolve.cc also seems to suggest to me
that gij is doing the correct thing.
Cheers,
Mark
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
The release
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. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
