Hello Alexey,

On 11/23/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:

Do we want to be Java5 compatible?

Yes, I understand that Yoko is CORBA 2.4 while Java5 and even 6 are
CORBA 2.3. This means that it is impossible to create fully compatible
version since it will require downgrading Yoko and this is not a
choice.

From the other hand we can try to achieve backward compatibility and
let applications designed for Java5 CORBA work with Yoko.
I believe that it would be good for Yoko. And yes, it is absolutely
required for Harmony :)

I've attached html with the latest JAPI results. Current JAPI score is
84.68%.
The main problems for now is missing functionality: 2 packages, 21
classes, 12 interfaces, 72 methods.

Is it possible to implement all this things?

Some of the classes seems to be renamed in Yoko. For example there is
org.omg.DynamicAny._DynAnyStub class in Java5 and
org.omg.DynamicAny.DynAnyStub in Yoko. Will it be OK to rename such
classes? Or it will be better to create a wrapper?

Another example of incompatibility: method
org.omg.CORBA.LocalObject._get_interface(): type org.omg.CORBA.Object
in jdk15.org.omg, but type org.omg.CORBA.InterfaceDef in
harmony.org.omg
InterfaceDef is subinterface of org.omg.CORBA.Object. Will it be OK to
change the return type in Yoko? It will probably require some code
refactoring...

And so on...

Thoughts? Objections?


I'm not sure I completely understand what you mean by making Yoko Java5
compatible but I would be a bit worried about changing class names and
method signitures so that Yoko matches the API presented in the JDK.
Couldn't
this lead us into a situation where we are moving backwards in terms of
CORBA
compliance?  As Andy mentions, sometimes the jump between one spec and
another results in a situation where compatibility is not achieved between
the
various CORBA specs.

I'd also confirm that the JDK implementation actually matches how things are

defined in the CORBA spec, as I've seen some issues in the past where things

defined in the JDK do not match the definition in the spec that Java claims
compliance with.

Cheers,
Darren

Reply via email to