Re: Japitools 1.5 support tough design issue
On 9/7/05, David Holmes <[EMAIL PROTECTED]> wrote: [Lots of very very useful and insightful observations and explanation snipped] Thanks very much for taking the time to go through my examples and pick my code apart. You confirmed a lot of things I thought, and clarified a bunch of areas where I was still unsure. > > The goal is to try to compare these in a way that's meaningful both > > from a 1.4 perspective and a 1.5 perspective. However... > > I don't quite follow the problem here, in that if you are processing a > parameterized 1.5 type then you need to apply the 1.5 rules regarding > overloads, overrides, covariant returns and allow for bridge methods (which > should be marked as such). Unfortuanately this is the crux of the problem. Japitools needs to keep a foot in both camps - we need to be able to answer questions like "how well is Classpath's main branch (which is non-generic and living in the 1.4 world) doing at providing API compatibility with JDK 1.5?" What it comes down to is that I need to find a way to apply both sets of rules simultaneously, and figure out which problems are real problems and which are just artefacts of the different sets of rules. When I compare a 1.4 implementation of java.util.List against 1.5's java.util.List, the comparison should accurately identify the fact that the implementation is largely correct, while also flagging the fact that all the generic parts are missing. A comparison in the other direction should result in essentially no errors because (except when Sun screws up) 1.5 should be completely backward compatible with 1.4. Of course these cases are straightforward compared to what happens if you try to compare a hypothetical 1.4 versus 1.5 implementation of my Super, Sub1, Sub5 and Sub8 classes. It's true that situation probably wouldn't come up in practice but in my experience if I can't answer what should happen in a corner case, it's usually a sign of a deeper design problem that will bite me eventually. > You need to know whether you are applying 1.4 or 1.5 rules regardless, to > deal with covariant returns and varargs. It's true that generics aren't the only issue where japitools gets into difficulty due to the need to live in both worlds, but generics seem to have the most tricky corner cases to figure out... > Hope this helps. Generics are so much fun - NOT! :-) I have to say, I'm glad I mostly work in C# these days. Much as I hate to credit Microsoft, they did generics *sooo* much better. > Oh a final warning: javac at least still contains many bugs with regard to > generics. What you observe need not be what the language truly allows or > prohibits. Can't speak for the other compilers. Hopefully it can at least accurately cover anything that will show up in the standard class libraries, which is the most important for japitools to cover correctly... Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Japitools 1.5 support tough design issue
Stuart,
> It appears that what actually happens is that the foo(String) method
> of Sub1 actually gets compiled as if it were:
> String foo(Object o) {foo((String) o);}
> String foo(String str) {...}
> I assume that the foo(Object) method is one of those "bridge" methods
> that we're currently ignoring in japitools.
Yes a bridge method will typically be generated to meet the requirements of
JLS 15.12.4.5. Such methods will be marked as synthetic.
You need to remember that generic types, eg. T, will be replaced by their
erasure in the bytecode and that the compiler will then introduce bridge
methods as needed to cause casts to the right "T" to occur.
> class Super
> {
> String foo(T t) {return "Super";}
> }
So class Super has the method:
String foo(Object t);
> class Sub1 extends Super {
> String foo(String str) {return "Sub1(String)";}
> }
Sub1 logically has a single method:
String foo(String t)
which is inherited from Super and overridden in Sub1. But the
bytecode physically has two methods:
String foo(Object);
String foo(String);
and the compiler "overrides" the Object version with a bridge method that it
casts to String and invokes the String version - thus ensuring only the one
implementation actually gets called from the callers perspective.
> // Sub2 is a compile error: "name clash: foo(java.lang.Object) in Sub2
> and foo(T) in Super have the same erasure, yet
> neither overrides the other"
> //class Sub2 extends Super {
> // String foo(Object str) {return "Sub2(Object)";}
> //}
Right. The method you try to add as an overload of foo in Sub2 has the same
signature as the erasure of the Super.foo method - hence a compile-time
error.
> // Sub3 is a compile error: "name clash: foo(java.lang.Object) in Sub3
> and foo(T) in Super have the same erasure, yet
> neither overrides the other"
> //class Sub3 extends Super {
> // String foo(String str) {return "Sub3(String)";}
> // String foo(Object str) {return "Sub3(Object)";}
> //}
Same problem.
> // Sub4 is a compile error: "foo(java.lang.String) in Sub4 cannot
> override foo(T) in Super; attempting to use incompatible return type"
> //class Sub4 extends Super {
> // void foo(String str) {System.out.println("Sub4(String)");}
> //}
Sub4.foo differs from the logical form of Super.foo only in return type.
That is only permitted if the return type is covariant with the original
which it isn't. So again an error.
> class Sub5 extends Super {
> void foo(Object str) {System.out.println("Sub5(Object)");}
> }
Logically you have:
String foo(String) from Super
void foo(Object) from sub5
That is okay as they have different signatures. Physically you have three
methods in the bytecode:
String foo(Object);
String foo(String);
void foo(Object);
This is okay the VM knows how to handle this. The VM's rules are less strict
than the languages. But it is hard to grok. The compiler will choose the
most specific form of the method to invoke based on the type of the argument
actually passed - so foo("aString") will always invoke the "String
foo(String)" form.
> // Sub6 is a compile error: "foo(java.lang.String) in Sub6 cannot
> override foo(T) in Super; attempting to use incompatible return type"
> //class Sub6 extends Super {
> // void foo(String str) {System.out.println("Sub6(String)");}
> // void foo(Object str) {System.out.println("Sub6(Object)");}
> //}
Same error as Sub4.
> // Sub7 is a compile error: "foo(java.lang.String) in Sub7 cannot
> override foo(T) in Super; attempting to use incompatible return type"
> //class Sub7 extends Super {
> // void foo(String str) {System.out.println("Sub7(String)");}
> // String foo(Object str) {return "Sub7(Object)";}
> //}
Same again.
> class Sub8 extends Super {
> String foo(String str) {return "Sub8(String)";}
> void foo(Object str) {System.out.println("Sub8(Object)");}
> }
Okay again. An override of the logically inherited method, plus a new
method.
> // Prints Sub1(String)
> try {System.out.println(s1.foo(""));} catch (Exception e)
> {System.out.println(e);}
Yep that's okay.
> // ClassCastException
> try {System.out.println(s1.foo(new Object()));} catch (Exception
> e) {System.out.println(e);}
Yep Sub1's bridge method takes care of this.
> Super ss1 = new Sub1();
> // Prints Sub1(String)
> try {System.out.println(ss1.foo(""));} catch (Exception e)
> {System.out.println(e);}
Yep okay.
> Super s5 = new Sub5();
> // Prints Super
> try {System.out.println(s5.foo(""));} catch (Exception e)
> {System.out.println(e);}
Ack! Unchecked warning - you have a raw Super object.
> // Prints Super. Really interesting that this *isn't* a
> ClassCastException.
> try {System.out.println(s5.foo(new Object()));} catch (Exception
> e) {System.out.println(e);}
A raw Super object has a String foo(Object) method and that is what you have
invoked. So the signature used was for the Object version that exists in
Super
Re: Japitools 1.5 support tough design issue
I did some testing and I'm more confused than ever.
class Super
{
String foo(T t) {return "Super";}
}
class Sub1 extends Super {
String foo(String str) {return "Sub1(String)";}
}
// Sub2 is a compile error: "name clash: foo(java.lang.Object) in Sub2
and foo(T) in Super have the same erasure, yet
neither overrides the other"
//class Sub2 extends Super {
// String foo(Object str) {return "Sub2(Object)";}
//}
// Sub3 is a compile error: "name clash: foo(java.lang.Object) in Sub3
and foo(T) in Super have the same erasure, yet
neither overrides the other"
//class Sub3 extends Super {
// String foo(String str) {return "Sub3(String)";}
// String foo(Object str) {return "Sub3(Object)";}
//}
// Sub4 is a compile error: "foo(java.lang.String) in Sub4 cannot
override foo(T) in Super; attempting to use incompatible return type"
//class Sub4 extends Super {
// void foo(String str) {System.out.println("Sub4(String)");}
//}
class Sub5 extends Super {
void foo(Object str) {System.out.println("Sub5(Object)");}
}
// Sub6 is a compile error: "foo(java.lang.String) in Sub6 cannot
override foo(T) in Super; attempting to use incompatible return type"
//class Sub6 extends Super {
// void foo(String str) {System.out.println("Sub6(String)");}
// void foo(Object str) {System.out.println("Sub6(Object)");}
//}
// Sub7 is a compile error: "foo(java.lang.String) in Sub7 cannot
override foo(T) in Super; attempting to use incompatible return type"
//class Sub7 extends Super {
// void foo(String str) {System.out.println("Sub7(String)");}
// String foo(Object str) {return "Sub7(Object)";}
//}
class Sub8 extends Super {
String foo(String str) {return "Sub8(String)";}
void foo(Object str) {System.out.println("Sub8(Object)");}
}
public class Tester {
public static void main(String[] args) {
Super s1 = new Sub1();
// Prints Sub1(String)
try {System.out.println(s1.foo(""));} catch (Exception e)
{System.out.println(e);}
// ClassCastException
try {System.out.println(s1.foo(new Object()));} catch (Exception
e) {System.out.println(e);}
Super ss1 = new Sub1();
// Prints Sub1(String)
try {System.out.println(ss1.foo(""));} catch (Exception e)
{System.out.println(e);}
Super s5 = new Sub5();
// Prints Super
try {System.out.println(s5.foo(""));} catch (Exception e)
{System.out.println(e);}
// Prints Super. Really interesting that this *isn't* a ClassCastException.
try {System.out.println(s5.foo(new Object()));} catch (Exception
e) {System.out.println(e);}
Super ss5 = new Sub5();
// Prints Super
try {System.out.println(ss5.foo(""));} catch (Exception e)
{System.out.println(e);}
Super s8 = new Sub8();
// Prints Sub8(String)
try {System.out.println(s8.foo(""));} catch (Exception e)
{System.out.println(e);}
// ClassCastException
try {System.out.println(s8.foo(new Object()));} catch (Exception
e) {System.out.println(e);}
Super ss8 = new Sub8();
// Prints Sub8(String)
try {System.out.println(ss8.foo(""));} catch (Exception e)
{System.out.println(e);}
}
}
What do I conclude from these results?
It appears that what actually happens is that the foo(String) method
of Sub1 actually gets compiled as if it were:
String foo(Object o) {foo((String) o);}
String foo(String str) {...}
I assume that the foo(Object) method is one of those "bridge" methods
that we're currently ignoring in japitools.
Furthermore Sub5 is interesting because it ends up with two methods
foo(Object), which differ only in return type. The one with return
type String is only accessible when used as an unqualified Super. In
other words the compiler probably doesn't actually insert a String
foo(Object) method here at all, it's just found at runtime by
superclass lookup.
Sub8 is just the combination of these two, but it's interesting
because in that case both String foo(Object) *and* void foo(Object)
must actually exist, with implementation bodies, in the class itself.
Presumably String foo(Object) is marked as ACC_BRIDGE and so will be
ignored by normal method lookup if the type is known at compiletime to
be Sub8.
What does this mean to Japitools?
Firstly, that many of the particularly evil cases are accounted for
and forbidden by the compiler.
Secondly, that ignoring bridge methods simplifies the Sub8 case.
But when I try to go into more detail it all seems more murky than
ever. Here's a breakdown as I see it...
Sub1 has the following methods:
1A) String foo(Object) (BRIDGE)
1B) String foo(Object but instantiated as String) (inherited from Super)
1C) String foo(String) (declared directly)
Sub5 has the following methods:
5A) String foo(Object but instantiated as String) (inherited from Super)
5B) void foo(Object) (declared directly)
5C) (maybe?) String foo(String) (BRIDGE?) (automatically added by
compiler? I can't think of a straightforward test for whether this
actually exists or not)
Sub8 has the following methods:
8A) String foo(Object) (BRIDGE)
8B) String foo(Object b
Re: gcc bugzilla notifications
On Sep 7, 2005, at 5:36 PM, Julian Scheid wrote: Hi Andrew, So could you please configure me as the gjdoc maintainer or let me know what else I can do in order to receive notifications? You now are the initial owner for the new bugs for gjdoc. I am sending this to the classpath mailing list too so people don't freak out. Thanks, Andrew Pinski ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Starting work on javax.rmi.CORBA
Hi Audrius, On Wed, 2005-09-07 at 11:19 +0200, Meskauskas Audrius wrote: > Despite the first classes of javax.rmi.CORBA were written long time ago > by Wu Gansha, this package is still largely incomplete and non > functional. This work could not be done properly before completing > org.omg.CORBA.ORB class. Those were written and committed back then as a quick hack to get JBoss working with Intel Orp. Being older and wiser now I realize that we should not have added these stubs and workarounds since they are mostly non-functional. Please feel free to rip them out completely and rewrite them cleanly from scratch. Thanks for working on this. And apologies for letting the non-functional stubs slip in. Thanks, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[Bug swing/22966] swing: JTextArea.setText("") causes StringIndexOutOfBoundsException later
--- Additional Comments From langel at redhat dot com 2005-09-07 17:51 --- fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22966 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: JAWT odds
On Wed, 2005-09-07 at 18:15 +0200, Mark Wielaard wrote: > Hi Tom, > > On Tue, 2005-09-06 at 20:50 -0400, Thomas Fitzsimmons wrote: > > > It would be nice if the makefile would work without the need to copy the > > > sources > > > over. > > > > Yes, even better would be if the JAWT demo were built automatically > > along with the other examples. But that requires extra build machinery > > that's not in place yet. > > That is the idea. But I didn't want to introduce that extra build > machinery one day before the release. So I choose to make a self > contained example that the user would have to compile/run by hand for > 0.18. If someone wants to merge example/Makefile.am with > example/Makefile.jawt.in that would be cool. > > > Yes, I'm currently sorting this out for libgcj and java-gcj-compat. Sun > > puts libjawt.so in $JAVA_HOME/jre/lib/i386. To ensure that libjawt.so > > is found automatically, Sun's java executable prepends > > $JAVA_HOME/jre/lib/i386 to LD_LIBRARY_PATH then re-exec's itself within > > the new environment. > > > > I've just added a java command to java-gcj-compat that does the same > > thing only exec's gij instead of re-exec'ing itself. > > I am not sure I have to be impressed or appalled by this hack :) > > Would it by an idea for the runtime (libgcj or some other) to dlopen the > installed jawt library with RTLD_GLOBAL set before opening any other jni > library (or maybe dlopen with the full path to libjawtgnu.so with > RTLD_GLOBAL as soon as dlopen on a jni library fails and then retry > loading that jni library)? That way it seems the linker can resolve the > jawt symbols without needing to explicitly opening the shared library > itself. Yes, good idea. I'm going to leave libgcj as-is since I'm pretty sure its maintainers would reject hacks like this (whereas java-gcj-compat is a good place to contain them) but it might be interesting to try these approaches in other runtimes. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Japitools 1.5 support tough design issue
> "Stuart" == Stuart Ballard <[EMAIL PROTECTED]> writes: Stuart> Does Java draw any distinction at all between, say, java.util.List and Stuart> java.util.List? In the language, yes. List is the raw type, and List is a particular parameterization. Raw types are kind of a special hack for backward compatibility, in particular so that you can genericize your library and let code using it still compile. Stuart> In other words, will there be any difference in bytecode between: Stuart> class MyList implements List Stuart> and Stuart> class MyList implements List I think there will be a difference in the Signature attributes that are emitted. Maybe the former won't even have a Signature, I'm not sure. I don't think there are other differences. This particular difference is important due to special handling of raw types in the compiler. I haven't checked this but I think: List foo = new MyList(); ... is required to emit an 'unchecked' conversion warning for the former, but not the latter. (Or maybe it is an error. My memory for some of these details is bad.) Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Japitools 1.5 support tough design issue
> "Stuart" == Stuart Ballard <[EMAIL PROTECTED]> writes:
Stuart> The problem is that in the japi file we want to have information about
Stuart> reality (to support meaningful comparisons against 1.4-level APIs)
Stuart> *and* about fairyland (to support meaningful comparisons of the new
Stuart> 1.5 features). In this case they're mutually exclusive as far as I can
Stuart> tell :(
Stuart> Suppose we have this:
Stuart> class Super {
Stuart> void foo(T t);
Stuart> }
Stuart> class Sub extends Super {}
Suppose we extend this a little:
class Sub extends Super { void foo(String x) ... }
In this case, a 1.5 compiler will emit both Sub.foo(Object) and
Sub.foo(String).
This has always been valid in bytecode -- there was just no way to
construct such a .class from a pre-1.5 java compiler.
My first reaction here is to say that japi should just be naive. For
instance, in this case, it could just treat the two things as
different methods, distinguishing them by their descriptors (what was
called a 'signature' in the 1.4 days -- the signature without any
generic information).
But maybe that yields too many false positives when comparing a 1.5
classpath against a 1.4 jdk? (Do we care about this?)
Plan B, I think, would be to try to emulate "real" 1.5 overriding
rules. Perhaps this would only mean recognizing and discarding
methods with ACC_BRIDGE set, and then looking for subclassing
relationships in argument and return types (which is a pain as it
means constructing a type hierarchy) -- though perhaps this could be
done by parsing the body of the bridge methods.
Tom
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: JAWT odds
Hi Robert,
On Wed, 2005-09-07 at 02:10 +0200, Robert Schuster wrote:
> I have some questions about the JAWT interface in Classpath.
>
> 1) To compile the JAWT demo I had to copy the source files into the object
> folder and run make with:
>
> make -f Makefile.jawt (from ${obj_dir}/examples)
>
> It would be nice if the makefile would work without the need to copy the
> sources
> over.
You should be able to do that in the install folder. It wasn't really
designed to be run/compiled in the object folder (although that works
when objdir == srcdir).
> 2) Then I had troubles running the demo in the way I am used to (JDK-like). I
> would call:
>
> jamvm -Djava.library.path=. gnu.classpath.examples.jawt.DemoJAWT
> [...]
> The only way I to run the demo was by calling:
> LD_LIBRARY_PATH=.:/home/rob/INSTALL/classpath/lib/classpath jamvm
> gnu.classpath.examples.jawt.DemoJAWT
The Makefile.jawt and README in examples should give the above as hint
to get it to run.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: JAWT odds
Hi Tom, On Tue, 2005-09-06 at 20:50 -0400, Thomas Fitzsimmons wrote: > > It would be nice if the makefile would work without the need to copy the > > sources > > over. > > Yes, even better would be if the JAWT demo were built automatically > along with the other examples. But that requires extra build machinery > that's not in place yet. That is the idea. But I didn't want to introduce that extra build machinery one day before the release. So I choose to make a self contained example that the user would have to compile/run by hand for 0.18. If someone wants to merge example/Makefile.am with example/Makefile.jawt.in that would be cool. > Yes, I'm currently sorting this out for libgcj and java-gcj-compat. Sun > puts libjawt.so in $JAVA_HOME/jre/lib/i386. To ensure that libjawt.so > is found automatically, Sun's java executable prepends > $JAVA_HOME/jre/lib/i386 to LD_LIBRARY_PATH then re-exec's itself within > the new environment. > > I've just added a java command to java-gcj-compat that does the same > thing only exec's gij instead of re-exec'ing itself. I am not sure I have to be impressed or appalled by this hack :) Would it by an idea for the runtime (libgcj or some other) to dlopen the installed jawt library with RTLD_GLOBAL set before opening any other jni library (or maybe dlopen with the full path to libjawtgnu.so with RTLD_GLOBAL as soon as dlopen on a jni library fails and then retry loading that jni library)? That way it seems the linker can resolve the jawt symbols without needing to explicitly opening the shared library itself. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Japitools 1.5 support tough design issue
Stuart Ballard wrote: > Out of interest, exactly what difference in behavior would you see in > the compiler and/or reflection based on those two different > declarations of MyList? Only the obvious things really. With reflection you can use Class.getGenericSuperclass() to get a Type that describes the super class in generic terms (including the complicated stuff) and the compiler uses it to determine what exactly you can do with the class. The subinterfaces of java.lang.reflect.Type give you a pretty good idea of what Japi would need to understand to acurately support of the generics features. I have to warn you though, when I originally look at it I kind of lost hope... ;-) Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Japitools 1.5 support tough design issue
On 9/7/05, Jeroen Frijters <[EMAIL PROTECTED]> wrote: > Depends on what you mean by "Java" . The JVM (outside of reflection > support) has absolutely no knowledge of generics, so as far as the JIT > and EE are concerned both are identical. That was why I phrased my question as "any distinction at all" - I know that different bits of the Java world have different levels of understanding of generics :) > > In other words, will there be any difference in bytecode between: > > class MyList implements List > > and > > class MyList implements List > > The part is a separate attribute in the class file, but that > attribute is only used for reflection and by Java compilers. Hmm, sounds like Japitools should recognize that distinction, then. Especially if it makes a difference to the compiler. Out of interest, exactly what difference in behavior would you see in the compiler and/or reflection based on those two different declarations of MyList? Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Japitools 1.5 support tough design issue
Stuart Ballard wrote: > I have another question about Java generics behavior and hopefully > people here are expert enough on the subject to be able to answer > it... > > Does Java draw any distinction at all between, say, java.util.List and > java.util.List? Depends on what you mean by "Java" . The JVM (outside of reflection support) has absolutely no knowledge of generics, so as far as the JIT and EE are concerned both are identical. > In other words, will there be any difference in bytecode between: > class MyList implements List > and > class MyList implements List The part is a separate attribute in the class file, but that attribute is only used for reflection and by Java compilers. > or between > List list = new ArrayList(); > and > List list = new ArrayList(); No difference at all, not even an attribute. Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Japitools 1.5 support tough design issue
I have another question about Java generics behavior and hopefully people here are expert enough on the subject to be able to answer it... Does Java draw any distinction at all between, say, java.util.List and java.util.List? In other words, will there be any difference in bytecode between: class MyList implements List and class MyList implements List or between List list = new ArrayList(); and List list = new ArrayList(); I'm trying to decide whether the APIs I'm constructing ought to allow any difference between a generic type where none of its type parameters are supplied at all, and a generic type where its type parameters are each set to the primary constraining type... Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Japitools 1.5 support tough design issue
On 9/7/05, Casey Marshall <[EMAIL PROTECTED]> wrote: > From this description it kind of sounds as though JVML (that is, > bytecode) defies the kind of static analysis Japitools is trying to > do. At least, when you aren't guaranteed to have the entire class > tree down to Object. Sort of... As you may or may not know, japitools runs in two phases: Japize, which takes a bunch of classfiles and turns them into a .japi file, and japicompat which compares two japi files for compatibility. Japize *is* guaranteed to have access to the entire tree down to Object. japicompat only has whatever Japize puts in the japi file, and Japize only puts the classes that it's told to include. In order to make this work, Japize puts *all* members of the classes into the japi file - not just the ones declared at that level, but anything inherited from superclasses too. When japicompat compares these lists, therefore, it's almost exactly equivalent to the JVM logic: if the list of members consists of all the superclass members as well as those declared in the class itself, comparing those members is equivalent to walking the superclass chain. > Maybe it would be a useful tool that took two sets of class files, > and compared them for binary compatibility, applying the same > semantics that would be used when looking up methods or fields when > run in a VM. That is, each available method or field in the base set > would be looked up in the target one, to see if it is equivalently > accessible. If I understood that right, I think it's what japitools does. It's what I *try* to achieve anyway. > I guess this might produce, uh, interesting results, > where Classpath might prove entirely binary compatible, but not > source compatible, so you could run binaries against Classpath, but > not compile them ;-) (I'm no JVM expert, so I don't know if this is > true). I think it's theoretically true. I'm not sure how much of a problem it is in practice, however. > But anyway, it is best to target meaningful compatibility issues, and > to do that in a tractable way. So, what does API compatibility mean > as far as Classpath is concerned? And what is the best (or easiest) > way to test that? Exactly the goal I've had with japitools. The problem is that in the generic world there's all these weird corner cases that I'm not quite sure what to do with. Java's generics live in a kind of limbo state halfway between binary and source compatibility, and trying to represent that reasonably in a format designed for pure binary compatibility checking, and still produce meaningful results on the generic part, is tough. As far as my particular question, I'm beginning to feel that the file format needs to allow for specifying both types - the "real" type and the one that applies in fairyland. Something like this: pkg.name,Sub!foo(Ljava/lang/Object;=Ljava/lang/String;) Then the full set of information is available to japicompat. Exactly what it should *do* with that information isn't quite clear, but at least we're not eliminating the information before it gets a chance to make an informed decision. Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jamvm-general] JamVM and Eclipse
Hi Robert,
Thanks for giving everything a test. I'll have a look at the PATH
issue once I've got a new release out. JamVM 1.3.2 won't work with
the latest Classpath snapshot now that 0.18 has been released so I
need to do this ASAP! It's basically releasing the CVS version, but I
need to put in a fix for a library naming change on Max OS X...
Rob.
On 9/7/05, Robert Schuster <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
> as you can see in the Eclipse section of our showcase page[0] running the IDE
> with JamVM still needs a small kludge:
>
> PATH=.:${PATH} ./eclipse -consoleLog -debug -vm jamvm -vmargs -mx256m
>
> I wonder why the PATH thing is necessary and whether this is a bug in our
> class
> library or JamVM. I used Classpath and JamVM from CVS for this, my machine
> runs
> Gentoo x86 and Eclipse is 3.1 RC5 (yeah its an older version).
>
> It may be of interest that I can run Eclipse this way too:
>
> jamvm -mx256m -jar startup.jar
>
> or
>
> jamvm -xm256m -jar /home/rob/tmp/native-eclipse/eclipse-3.1/./startup.jar
> (which
> is what the starter program does)
>
> and it works without problems.
>
> cu
> Robert
>
> [0] -
> http://developer.classpath.org/mediation/ClasspathShowcase#head-77e64cc6893026805e96c751a32012d79dd93e4f
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFDHjcqG9cfwmwwEtoRAim9AKCfvOc4oWdOC80q8PtmdvrkGpojtQCgkTIn
> pc+LKtjBdlA7LizQbJfcLUg=
> =/YNt
> -END PGP SIGNATURE-
>
>
> ---
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> ___
> Jamvm-general mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jamvm-general
>
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: Question about createUI() method?
Am Dienstag, den 06.09.2005, 21:13 + schrieb David Gilbert:
> Hi,
>
> A quick question about Swing:
>
> A lot of the createUI() methods in the look and feel code are implemented
> with a
> HashMap to retain references to the UI delegates that are created. For
> example:
>
>public static ComponentUI createUI(JComponent component)
>{
> if (instances == null)
>instances = new HashMap();
>
> Object o = instances.get(component);
> MetalComboBoxUI instance;
> if (o == null)
>{
> instance = new MetalComboBoxUI();
> instances.put(component, instance);
>}
> else
>instance = (MetalComboBoxUI) o;
>
> return instance;
>}
>
> I was wondering if anyone can explain the purpose of retaining the instance
> for each
> component? (As opposed to just returning a new instance for each call). As
> I
> understand it, the createUI() method will only be called once for each
> component
> each time the look and feel is changed. So I don't see the need for
> retaining the
> instances in the HashMap. Any pointers?
That was introduced by me. Honestly I don't remember myself why I found
this important. I think I might have been mislead of the API docs in
ComponentUI.createUI(): 'If the UI delegate is stateful, then it should
return a new instance per component.'
I think it would be ok to change this to simply return a new instance on
each call without storing them in the hashtables.
Best regards,
Roman
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Starting work on javax.rmi.CORBA
Despite the first classes of javax.rmi.CORBA were written long time ago by Wu Gansha, this package is still largely incomplete and non functional. This work could not be done properly before completing org.omg.CORBA.ORB class. I plan to use the documentation at http://www.omg.org/cgi-bin/doc?formal/03-09-04. Regards Audrius. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath 0.18 released
Alexander Shopov wrote: Is there a page outlining what part of J2SE 1.3, 1.4 and 5.0 this release is covering? Which methods need further development, which classes are unimplemented? Best regards: al_shopov On the GNU Classpath home page: http://www.gnu.org/software/classpath/ ...third section down, "Classpath::Status", click on the JDK1.0-JDK1.4 links to see reports on the API completeness. Regards, Dave Gilbert ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath 0.18 released
Hi, the JAPI Tools provide an analysis of what you request. The results are published here: Classpath vs. JDK 1.3 http://www.kaffe.org/~stuart/japi/htmlout/h-jdk13-classpath.html Classpath vs. JDK 1.4 http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html Classpath vs. JDK 1.5 http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-classpath.html (JAPI Tools are not optimized to 1.5 style class files yet, so the results have to be read with a grain of salt.) The wayback machine of archive.org tells that Classpath was at 67.25 % in Octobre 2004: http://web.archive.org/web/20041019084158/http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html That means we got 24 % of JDK1.4 API completeness in 11 months. Great work! cu Robert Alexander Shopov wrote: > Is there a page outlining what part of J2SE 1.3, 1.4 and 5.0 this > release is covering? Which methods need further development, which > classes are unimplemented? > Best regards: > al_shopov > > > ___ > Classpath mailing list > Classpath@gnu.org > http://lists.gnu.org/mailman/listinfo/classpath > > ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath 0.18 released
Hi to all the adventurous! > * QT4 AWT peers, enable by giving configure --enable-qt-peer. Setting this up is still not that easy because most OS do not ship Qt4 at the moment. However you find a tested and tried walkthrough to get the Qt4 peers working on the showcase page of our Wiki[0]. Please do not hesitate to amend the manual if your platform requires special steps which have not been mentioned yet. Furthermore if you discover bugs in the Qt4 AWT peer implementation please let us know, too. :) Happy hacking! cu Robert [0] - http://developer.classpath.org/mediation/ClasspathShowcase#head-f83172f07f6d2e7979f3ca718e37be95fae048c8 ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
