Thanks Leo for your input. It forces me to think about some aspects of
compatibility again.
On 5/6/06, Leo Simons <[EMAIL PROTECTED]> wrote:
On Sat, May 06, 2006 at 12:33:52PM +0700, Vladimir Ivanov wrote:
> Recently I thought about guaranteeing binary and source compatibility
> between HARMONY API and other compatible J2SE API implementations, what
is
> our goal and how to check it, automation. Let me share my thoughts - for
us
> to understand clearly what we want and how to test it.
Thanks, vladimir, very clear!
=== Some observations ===
>
> Observation #1: I think, in general, binary compatibility is a weaker
> requirement then source compatibility and is completely covered by
source
> compatibility.
Hmm. For the "general" form of "general", this is not true, which stems
from
the use of preprocessors and non-deterministic transformations with which
the
non-java world is full. Eg when you do C development and change the
definition
of how big an int is, you lose binary compatibility but preserve source
compatibility if this definition is inherited.
In the specific, you might very well be very right here, which is quite
interesting...how'd you come to these observations? Can I read more about
them
elsewhere?
This observation based on another observation that compiler does linking
(name resolution) in the same way as runtime (seems, for your example with C
language it will not break linking, i.e. binary compatibility in terms of
JLS).
Of cause, if the compiler does not start linker or rules for compilation and
runtime are different it will not work, but I know only some primitive
assemblers that violate these rules.
Sorry, I can't refer to articles just because I don't know any one related
to source compatibility 'in general'. My observation based on the experience
only.
> Observation #2: I think, talking about 1.4, checking of 2-way binary
> compatibility + throws clause + inheritance hierarchy will guarantee
2-way
> source compatibility. I did not find any contra examples.
+ serialized form
I can imagine naughty/hacky code that uses reflection would be able to
violate
that rule too. The AOP toolkits are a good example of pushing the limits,
eg
aspectwerkz @ codehaus.org.
The JVMS defines for java runtime that linking includes verification,
preparation and resolution. Conformat compiler generates valid code. The
preparation phase is memory allocation + check for AbstractMethodError. The
resolution phase include checks for IllegalAccessError, InstantiationError,
NoSuchFieldError and NoSuchMethodError. But compiler does all these 5 checks
so source compatibility include binary (for java).
Correct serialized form is not required for source/ binary compatibility (it
is not affect linking/ compilation), so harmony target may be extended to
"2-way-source compatibility and 2-way-serialized form compatibility".
As for reflection, seems, the linker does the same checks as compiler
(elements are mirrored to the wrappers like java.lang.reflect.Method and
both checks types of wrappers only). It will be very useful If your provide
code example to think how it can be eliminated.
=== What is our (Harmony) goal? ===
>
> In terms of these definitions, ideally, I suppose we want that Harmony
is
> 2-way source compatible with the conformant J2SE API implementation (RI
API)
> to make sure that any application compiled with RI API can be compiled
with
> Harmony and vice versa
yep, 2-way-source compatible and 2-way-binary compatible.
Agree.
2-way-source compatible and 2-way-serialized form compatible
=== Questions ===
> 2. What more checks should be added to JAPI to guarantee 2-way source
> compatibility for 1.5?
You know, I can't even think of a good way to do implement the checks for
the generics, let alone think of more!
Seems, it can be done for case with generic because all needed information
stored to the class file. For example, additional checks for source
compatibility may be implemented to convert information from the class file
'Signature' attribute to the textual representation of method's signature
(with parameters rename for generic names).
If we all agree that our target is "2-way source compatible and
2-way-serialized form compatible" it would be good to define the complete
list of checks and, for example, extend JAPI by implementing all these
checks to make complete 2 way source compatibility (with RI) testing tool.
Thanks,
Vladimir Ivanov
cheers!
Leo
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
