This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
Re: More bugs with inner classes (was: Freenet compilation errors.)
- To: Alexandre Petit-Bianco <apbianco at cygnus dot com>
- Subject: Re: More bugs with inner classes (was: Freenet compilation errors.)
- From: "Mark J. Roberts" <mjr at statesmean dot com>
- Date: Fri, 19 Jan 2001 15:16:23 -0600 (CST)
- cc: java-discuss at sources dot redhat dot com
On Thu, 18 Jan 2001, Alexandre Petit-Bianco wrote:
> Mark J. Roberts writes:
>
> > So the problem is with parsing the .class file for
> > Connection.java. I'll try to make a test case right now.
>
> OK. Here's what's happening. finit$ is generated on the fly by the
> class being compiled, it's looked up, but there's really only one
> valid candidate which always sits in the class being searched. In your
> case, the bytecode loader was grabbing an already generated finit$
> which was conflicting with the one we're searching. This situation
> uncovered an other problem: we weren't marking synthetic members when
> loaded from the bytecode parser (hence the confusing error message.)
>
> With the following patch, gcj bails out building Freenet.contrib.fproxy.\
> mumail.mime.MIME_text_plain because there isn't a sun.io.CharacterEncoding.\
> aliasName method available. This patch include Tom's suggestion of
> simplifying resolve_package which contained irrelevant code, and clean
> things a bit (we've been picking up some warnings lately.)
>
> I need to throughly test this patch before I commit it.
I applied it and could successfully build Core.java, but not
HttpHandlerServlet.java. The problem might be related to the following
test case (guess what I did last night). The value of id is horribly
munged:
[root@rm03-24-131-185-22 /freenet]# gcj -o test --main=Test Test.java
[root@rm03-24-131-185-22 /freenet]# ./test
Works here: 1234567890
But not here: 4627002352841261056
It will usually repeat the same value time after time, but once and a
while it gave me a different one. This test case seems to always give me
the above, but in its natural environment it occasionally was different.
public class Test
{
public static void main(String[] args) {
Test t = new Test();
}
public Test() {
Inner1 i = new Inner1();
i.doThing();
}
protected abstract class Inner
{
protected long id;
public Inner() {
id = 1234567890;
}
}
protected class Inner1 extends Inner
{
public Inner1() {
super();
}
public void doThing() {
Inner2 i2 = new Inner2();
System.out.println("Works here: "+id);
i2.printVal();
}
private class Inner2
{
public void printVal() {
System.out.println("But not here: "+id);
}
}
}
}
--
Mark Roberts
mjr@statesmean.com