harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ivanov" <ivavladi...@gmail.com>
Subject Re: [classlib] HARMONY vs. J2SE API source, binary compatibility: JAPI for 1.5 required
Date Mon, 15 May 2006 13:18:28 GMT
Thanks Leo for your input. It forces me to think about some aspects of
compatibility again.

On 5/6/06, Leo Simons <mail@leosimons.com> 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

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

> > 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.

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.

  Vladimir Ivanov

> Leo
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message