harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [heads up] the importance of 'reversed' API completion
Date Mon, 20 Nov 2006 12:04:34 GMT
Stefano Mazzocchi wrote:
> As shown in the graphical history of harmony at
> we are currently at 96.39% of API completion (if we don't count the
> SerialID differences and the final static values), and we are
> continuously growing there.
> But there is also another index, the "reversed" API completion that
> measures how much code the RI didn't implement that we did.
> Here, a 100% means that all that code that we have implemented in those
> public packages is available in the RI.
> In order to achieve WORA, the TCK mandates that both direct and reverse
> completion be 100%.
> I suggest we start to pay attention to both.
> Here is a reverse-japi report:
I'm looking at that report, and have fixed several modules like 
luni/archive/nio etc, most of them fell into some categories: lack of 
private default constructor, over-generific, non-final/final, etc, i.e., 
not a big deal, the most significant issue is ORB classes. Besides, I 
have some other issues:
1.  About the kernel classes in luni, not sure what classes in Harmony 
are used by JAPI, the luni-kernel stubs, or the real implementation in 
DRLVM/IBM VME, I've fixed the luni-kernel, but the VM guys may need also 
to pay attention on their real implementation, too.
2. Another interesting thing is concurrent module, there are trivial 
difference between the codes used by Harmony with RI, shouldn't they are 
same code base? and I've checked the Java 6 document, they are different 
with Harmony ones, too.[1]

[1] JAPI reversed report on concurrent
Bad: 2 classes, 2 methods. Abs.add: 1 method.

    * class java.util.concurrent.ConcurrentHashMap: implements 
java.lang.Cloneable in harmony, but doesn't implement 
java.lang.Cloneable in sun5
    * class java.util.concurrent.CopyOnWriteArraySet: implements 
java.lang.Cloneable in harmony, but doesn't implement 
java.lang.Cloneable in sun5
    * method java.util.concurrent.ConcurrentHashMap.clone(): doesn't 
throw java.lang.CloneNotSupportedException in harmony, but throws 
java.lang.CloneNotSupportedException in sun5
    * method java.util.concurrent.ConcurrentHashMap.clone(): public in 
harmony, but protected in sun5


    * method 
new interface method in sun5

Paulex Yang
China Software Development Lab

View raw message