Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ivavladimir@gmail.com designates
 66.249.82.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=ndQrwEBulGrvY8/ZzS5RDghflD/hkuZokSOsL4bNP2rCt4kD7sSdqS+1PXRSbaFUbSSkqTYYtCS9yiAOqvt21iOtNZmaUS+uGF7UeBHbnzV2j7m44zVwlJG8/K1oUPiClP8Z8tbCjBZjHUGIh5E6qqx/CDjJQapk4sfy79IUxN0=
Message-ID: <7273946b0605310431h1b6376boa2dc20fed2849303@mail.gmail.com>
Date: Wed, 31 May 2006 18:31:25 +0700
From: "Vladimir Ivanov" <ivavladimir@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] HARMONY vs. J2SE API source,
 binary compatibility: JAPI for 1.5 required
In-Reply-To: <7273946b0605150618i4d7461a0q80e8e5efe4b8aaca@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_18291_21495048.1149075085393"
References: <7273946b0605052233i3f99b57dg122cbd1c09872034@mail.gmail.com>
	 <20060506103236.GG2348@bali.sjc.webweaving.org>
	 <7273946b0605150618i4d7461a0q80e8e5efe4b8aaca@mail.gmail.com>

------=_Part_18291_21495048.1149075085393
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Looking through the mail thread:

[classlib] JAPI data to drive packages to completion


and following the link I found that looks like JAPI somehow supports part of
1.5 features (at least generics). It would be interesting to know for sure
which of 1.5 features JAPI supports and which not, to understand what JAPI
lacks (or be sure it has everything) to test 1.5 source compatibility of HY
vs. conformant APIs.


Mark, could your please point me to the document (if know any) that
describes what of 1.5 features JAPI supports or provide a link to the tool's
binaries to try.

 Thanks for your help,
  Vladimir


On 5/15/06, Vladimir Ivanov <ivavladimir@gmail.com > wrote:
>
> 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
> 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>

------=_Part_18291_21495048.1149075085393--