classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Japitools 1.5 support tough design issue


From: Stuart Ballard
Subject: Japitools 1.5 support tough design issue
Date: Wed, 7 Sep 2005 00:18:00 -0400

I'm posting to the list because I'm interested in general feedback
about this problem - it's a tricky one. I'm working on the problem of
getting 1.5 support into japitools; the biggest obstacle is figuring
out exactly how the 1.5 features should be represented in a japi file.

I just found a situation where the goal of accurately representing the
1.5 generic world appears to actually contradict the goal of
accurately representing the 1.4 non-generic world.

(I'm thinking I should start calling the world where Java generics
really exist "fairyland", because it's a wondrous magic place that
would be very nice if it existed, but unfortunately bears only a
tenuous relation to reality)

The problem is that in the japi file we want to have information about
reality (to support meaningful comparisons against 1.4-level APIs)
*and* about fairyland (to support meaningful comparisons of the new
1.5 features). In this case they're mutually exclusive as far as I can
tell :(

Suppose we have this:
class Super<T> {
  void foo(T t);
}
class Sub extends Super<String> {}

Clearly, in the real world, Sub has a foo(Object) method because it's
inherited from Super. Equally clearly, in fairyland, Sub has a
foo(String) method because it's inherited from Super<String>.

Sub definitely *doesn't* have a foo(String) method in the real world,
because the foo method might have been added to Super *after* Sub was
compiled so there may not have been any opportunity for the compiler
to add it. I'm not sure whether it has a foo(Object) method in
fairyland - that comes down to whether it's legal to write "new
Sub().bar(new Object())".

The real question, though, is how on earth do we represent that
inherited method in a japi file? Japi files, by design, contain all
inherited members because the rule in Java is that binary
compatibility doesn't depend on where in the hierarchy a method was
actually defined; the superclass may not be included in the japi file
at all so we can't rely on being able to go to its japi entry to look
up what its members are.

Even worse - what do we do if Sub actually *does* declare a
foo(String) or foo(Object) method? Or - worse yet - both? Which of
them ends up overriding the method from Super? How does fairyland
manage to match up with reality here? And what the heck should the
japi file say about that situation?

Um... help? Anyone?

Stuart.
-- 
http://sab39.dev.netreach.com/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]