You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Stefano Mazzocchi <st...@apache.org> on 2006/11/05 08:24:20 UTC
[general] Interesting discoveries playing around with japitools
Being a sucker for statistics and charts, I've decided to look into
japitools myself and regenerate the graph of API coverage progress of
harmony.
In doing so, I started to familiarize myself with the Japitools and I
found a few interesting discoveries: the latest version of the three
freely available certified java 5 implementations (Sun's, BEA's and
IBM's) are *NOT* 100% compatible.
So, here's what I did:
1) download the three JVMs
2) download japitools, "tar xzf" it and "cd japitools"
3) type:
./bin/japize as $name packages \
/path/to/jvms/$name/jre/lib/*.jar \
+java +javax +org -org.apache -org.ietf
and substitute $name with the JVM name
4) you'll obtain three $name.japi.gz files (the binary representation
of your API footprint)
5) then type "japicompat -s $original.japi.gz $test.japi.gz"
where "original" is the JVM that you consider the reference and $test is
the one that you want to test.
Here are the (a little surprising, I must say) results:
-- sun 1.5 vs. bea1.5 ---------------------------------------
99.99% good, 0% missing
java.awt.peer:
method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
/home/stefano/data/japi/ibm1.5
-- sun 1.5 vs. ibm1.5 ---------------------------------------
Total: 99.93% good, 0% bad, 0.06% missing
java.awt.peer:
Missing
method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
/home/stefano/data/japi/ibm1.5
javax.xml.datatype:
Bad
field
javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
constant
[com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
in /home/stefano/data/japi/sun1.5, but constant
[org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
/home/stefano/data/japi/ibm1.5
org.omg.stub.javax.management.remote.rmi:
Missing
class org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie:
missing in /home/stefano/data/japi/ibm1.5
class org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie:
missing in /home/stefano/data/japi/ibm1.5
org.w3c.dom.html:
Missing
method org.w3c.dom.html.HTMLFrameElement.getContentDocument(): missing
in /home/stefano/data/japi/ibm1.5
method org.w3c.dom.html.HTMLIFrameElement.getContentDocument(): missing
in /home/stefano/data/japi/ibm1.5
method org.w3c.dom.html.HTMLObjectElement.getContentDocument(): missing
in /home/stefano/data/japi/ibm1.5
method org.w3c.dom.html.HTMLOptionElement.setSelected(boolean): missing
in /home/stefano/data/japi/ibm1.5
- o -
There is one method that both Bea and IBM don't implement in
awt.peer.WindowPeer and apparently, Sun doesn't implement it either..
it's just a stub! Weird.
[see more at http://forums.java.net/jive/thread.jspa?messageID=167137]
the differences in datatype factory is plausible and the fact that a
stub RMI class is missing is not that big of a deal. It's weird though,
that the DOM in IBM's is different than the DOM in Sun's... I guess not
that many people use the HTML DOM in java or they would have got that ;-)
The really crazy things start to happen if you flip things around and
you consider the 'clean room rewrites' as the reference implementations:
-- bea1.5 vs. sun1.5 --------------------------------------------
Total: 99.98% good, 0.01% missing
javax.xml.namespace:
Missing
class javax.xml.namespace.QName: missing in /home/stefano/data/japi/sun1.5
Uh? Sun forgot to ship the QName class or this is a japitools bug?
googling up shows the class in the java1.5 docs so it's more likely it's
a bug in japitools
http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/namespace/QName.html
Gets more interesting with IBM:
-- ibm1.5 vs. sun1.5 --------------------------------------------
Total: 99.77% good, 0% bad, 0.22% missing
java.lang:
Missing
method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
in /home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.capacity(): missing in
/home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.charAt(int): missing in
/home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.codePointAt(int): missing in
/home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.codePointBefore(int): missing in
/home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.codePointCount(int, int): missing in
/home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.ensureCapacity(int): missing in
/home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.getChars(int, int, char[], int): missing
in /home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.length(): missing in
/home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.offsetByCodePoints(int, int): missing in
/home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.setCharAt(int, char): missing in
/home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.setLength(int): missing in
/home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.subSequence(int, int): missing in
/home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.substring(int): missing in
/home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.substring(int, int): missing in
/home/stefano/data/japi/sun1.5
method java.lang.StringBuilder.trimToSize(): missing in
/home/stefano/data/japi/sun1.5
javax.management.remote.rmi:
Missing
class javax.management.remote.rmi._RMIConnectionImpl_Tie: missing in
/home/stefano/data/japi/sun1.5
class javax.management.remote.rmi._RMIServerImpl_Tie: missing in
/home/stefano/data/japi/sun1.5
javax.xml.datatype:
Bad
field
javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
/home/stefano/data/japi/ibm1.5, but constant
[com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
in /home/stefano/data/japi/sun1.5
org.omg.stub.java.lang:
Missing
package org.omg.stub.java.lang: missing in /home/stefano/data/japi/sun1.5
org.omg.stub.java.security:
Missing
package org.omg.stub.java.security: missing in
/home/stefano/data/japi/sun1.5
org.omg.stub.java.util:
Missing
package org.omg.stub.java.util: missing in /home/stefano/data/japi/sun1.5
org.w3c.dom.html:
Missing
method org.w3c.dom.html.HTMLOptionElement.setIndex(int): missing in
/home/stefano/data/japi/sun1.5
method org.w3c.dom.html.HTMLTableCellElement.setCellIndex(int): missing
in /home/stefano/data/japi/sun1.5
method
org.w3c.dom.html.HTMLTableRowElement.setCells(org.w3c.dom.html.HTMLCollection):
missing in /home/stefano/data/japi/sun1.5
method org.w3c.dom.html.HTMLTableRowElement.setRowIndex(int): missing in
/home/stefano/data/japi/sun1.5
method org.w3c.dom.html.HTMLTableRowElement.setSectionRowIndex(int):
missing in /home/stefano/data/japi/sun1.5
org.w3c.dom.xpath:
Missing
package org.w3c.dom.xpath: missing in /home/stefano/data/japi/sun1.5
- o -
First the not-so-shocking things:
1) IBM ships with xpath support with DOM, while Sun does not. Is this
true of it's a bug?
2) IBM has a 'stub' subpackage of org.omg that Sun does not have
but the real shocker is that japitools reports that IBM has *modified*
the java.lang.StringBuilder class and added *15* new methods to it!
If this is true, how is it possible for this JVM to pass the TCK if you
add methods to a java.lang class? Isn't this the kind of stuff that TCKs
are supposed to prevent? Can anybody explain to me if this is true or if
this is a japi bug?
Also, I found out that Japitools triggers some NullPointerExceptions
here and there, so it needs some tuning. I'll investigate more.
Stay tuned.
--
Stefano.
Re: [general] Interesting discoveries playing around with japitools
Posted by Tim Ellison <t....@gmail.com>.
Stefano Mazzocchi wrote:
> Tim Ellison wrote:
>> Thanks for doing this Stefano. I'll investigate the Sun/IBM findings
>> and let you know.
>
> My pleasure, really.
>
> Oh, and before anybody thinks there is something malicious about this,
> let me state that I do *NOT* think there was anything intentional in the
> various JVM about breaking WORA or things like that.
>
> It's obviously just a bug somewhere, in japitools, in the TCK coverage
> tests, in the IBM JVM class library or (more likely) in a weird
> combination of all of the above.
>
> What I want to emphasize (especially to the Sun officials that watch us)
> is that not only open source is not about breaking compatibility, but
> it's able to catch incompatibilities that not even Sun did. ;-)
Understood, but thanks for making it clear. I always prefer the
'cock-up' theory to the 'conspiracy' theory for such things ;-)
I can't see the Sun-based code delivered in IBM 1.5, so had to go
through other people who can to get some answers. Here's what I found
out, slightly reformatted from your original listing:
== sun 1.5 vs. ibm1.5 ==
java.awt.peer:
Method java.awt.peer.WindowPeer.updateFocusableWindowState() is missing
in IBM1.5
The claim is that this method doesn't exist in Sun code either (as I
said above, I can't check directly). This package isn't listed in the
JSE5.0 javadoc.
javax.xml.datatype:
Field
javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS
has value
“com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl”
in Sun1.5, but value
“org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl” in IBM1.5
This is deliberate, since IBM doesn't do the 'com.sun' package renaming,
so this field has the name of the actual type that is to be used as the
factory impl.
org.omg.stub.javax.management.remote.rmi:
Class org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie
missing in IBM1.5
Class org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie
missing in IBM1.5
This package is not part of the JSE API (but the inconsistency is being
checked).
org.w3c.dom.html:
method org.w3c.dom.html.HTMLFrameElement.getContentDocument() missing
in IBM1.5
method org.w3c.dom.html.HTMLIFrameElement.getContentDocument() missing
in IBM1.5
method org.w3c.dom.html.HTMLObjectElement.getContentDocument(): missing
in IBM1.5
method org.w3c.dom.html.HTMLOptionElement.setSelected(boolean): missing
in IBM1.5
This package is also not part of the JSE API (but the inconsistency is being
checked).
- o -
== ibm1.5 vs. sun1.5 ==
java.lang:
method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
in Sun1.5
This is a bug in the IBM impl. you can expect that method to disappear.
javax.management.remote.rmi:
Class javax.management.remote.rmi._RMIConnectionImpl_Tie missing in Sun1.5
Class javax.management.remote.rmi._RMIServerImpl_Tie missing in Sun1.5
This also looks like a bug in the IBM impl (and looking at how the type
names match those listed above as missing in org.omg.stub... it looks to
me like the Ties were somehow created in the wrong package).
javax.xml.datatype:
Field
javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS
has value "org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl” in
IBM1.5, but value
“com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl”
in Sun1.5
This is the same String const case as listed above.
... and the remainder of these are non-JSE-API packages. Again, the
difference is being checked.
org.omg.stub.java.lang:
Package org.omg.stub.java.lang: missing in Sun1.5
org.omg.stub.java.security:
Package org.omg.stub.java.security: missing in Sun1.5
org.omg.stub.java.util:
Package org.omg.stub.java.util: missing in Sun1.5
org.w3c.dom.html:
Method org.w3c.dom.html.HTMLOptionElement.setIndex(int) missing in Sun1.5
Method org.w3c.dom.html.HTMLTableCellElement.setCellIndex(int) missing
in Sun1.5
Method
org.w3c.dom.html.HTMLTableRowElement.setCells(org.w3c.dom.html.HTMLCollection)
missing in Sun1.5
Method org.w3c.dom.html.HTMLTableRowElement.setRowIndex(int) missing in
Sun1.5
Method org.w3c.dom.html.HTMLTableRowElement.setSectionRowIndex(int)
missing in Sun1.5
org.w3c.dom.xpath:
Package org.w3c.dom.xpath: missing in Sun1.5
- o -
Thanks again for pointing these out. Of course, the IBM Java SDKs all
pass the JCK, so it may be that we require additional signature tests to
catch some of these.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [general] Interesting discoveries playing around with japitools
Posted by Stefano Mazzocchi <st...@apache.org>.
Tim Ellison wrote:
> Thanks for doing this Stefano. I'll investigate the Sun/IBM findings
> and let you know.
My pleasure, really.
Oh, and before anybody thinks there is something malicious about this,
let me state that I do *NOT* think there was anything intentional in the
various JVM about breaking WORA or things like that.
It's obviously just a bug somewhere, in japitools, in the TCK coverage
tests, in the IBM JVM class library or (more likely) in a weird
combination of all of the above.
What I want to emphasize (especially to the Sun officials that watch us)
is that not only open source is not about breaking compatibility, but
it's able to catch incompatibilities that not even Sun did. ;-)
> Regards,
> Tim
>
> Stefano Mazzocchi wrote:
>> Being a sucker for statistics and charts, I've decided to look into
>> japitools myself and regenerate the graph of API coverage progress of
>> harmony.
>>
>> In doing so, I started to familiarize myself with the Japitools and I
>> found a few interesting discoveries: the latest version of the three
>> freely available certified java 5 implementations (Sun's, BEA's and
>> IBM's) are *NOT* 100% compatible.
>>
>> So, here's what I did:
>>
>> 1) download the three JVMs
>> 2) download japitools, "tar xzf" it and "cd japitools"
>> 3) type:
>>
>> ./bin/japize as $name packages \
>> /path/to/jvms/$name/jre/lib/*.jar \
>> +java +javax +org -org.apache -org.ietf
>>
>> and substitute $name with the JVM name
>>
>> 4) you'll obtain three $name.japi.gz files (the binary representation
>> of your API footprint)
>>
>> 5) then type "japicompat -s $original.japi.gz $test.japi.gz"
>>
>> where "original" is the JVM that you consider the reference and $test is
>> the one that you want to test.
>>
>> Here are the (a little surprising, I must say) results:
>>
>> -- sun 1.5 vs. bea1.5 ---------------------------------------
>>
>> 99.99% good, 0% missing
>>
>> java.awt.peer:
>> method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
>> /home/stefano/data/japi/ibm1.5
>>
>> -- sun 1.5 vs. ibm1.5 ---------------------------------------
>>
>> Total: 99.93% good, 0% bad, 0.06% missing
>>
>> java.awt.peer:
>> Missing
>> method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
>> /home/stefano/data/japi/ibm1.5
>>
>> javax.xml.datatype:
>> Bad
>> field
>> javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
>> constant
>> [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
>> in /home/stefano/data/japi/sun1.5, but constant
>> [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
>> /home/stefano/data/japi/ibm1.5
>>
>> org.omg.stub.javax.management.remote.rmi:
>> Missing
>> class org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie:
>> missing in /home/stefano/data/japi/ibm1.5
>> class org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie:
>> missing in /home/stefano/data/japi/ibm1.5
>>
>> org.w3c.dom.html:
>> Missing
>> method org.w3c.dom.html.HTMLFrameElement.getContentDocument(): missing
>> in /home/stefano/data/japi/ibm1.5
>> method org.w3c.dom.html.HTMLIFrameElement.getContentDocument(): missing
>> in /home/stefano/data/japi/ibm1.5
>> method org.w3c.dom.html.HTMLObjectElement.getContentDocument(): missing
>> in /home/stefano/data/japi/ibm1.5
>> method org.w3c.dom.html.HTMLOptionElement.setSelected(boolean): missing
>> in /home/stefano/data/japi/ibm1.5
>>
>> - o -
>>
>> There is one method that both Bea and IBM don't implement in
>> awt.peer.WindowPeer and apparently, Sun doesn't implement it either..
>> it's just a stub! Weird.
>>
>> [see more at http://forums.java.net/jive/thread.jspa?messageID=167137]
>>
>> the differences in datatype factory is plausible and the fact that a
>> stub RMI class is missing is not that big of a deal. It's weird though,
>> that the DOM in IBM's is different than the DOM in Sun's... I guess not
>> that many people use the HTML DOM in java or they would have got that ;-)
>>
>> The really crazy things start to happen if you flip things around and
>> you consider the 'clean room rewrites' as the reference implementations:
>>
>> -- bea1.5 vs. sun1.5 --------------------------------------------
>>
>> Total: 99.98% good, 0.01% missing
>>
>> javax.xml.namespace:
>> Missing
>> class javax.xml.namespace.QName: missing in /home/stefano/data/japi/sun1.5
>>
>> Uh? Sun forgot to ship the QName class or this is a japitools bug?
>>
>> googling up shows the class in the java1.5 docs so it's more likely it's
>> a bug in japitools
>>
>> http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/namespace/QName.html
>>
>> Gets more interesting with IBM:
>>
>> -- ibm1.5 vs. sun1.5 --------------------------------------------
>>
>> Total: 99.77% good, 0% bad, 0.22% missing
>>
>> java.lang:
>> Missing
>> method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
>> in /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.capacity(): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.charAt(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.codePointAt(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.codePointBefore(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.codePointCount(int, int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.ensureCapacity(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.getChars(int, int, char[], int): missing
>> in /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.length(): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.offsetByCodePoints(int, int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.setCharAt(int, char): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.setLength(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.subSequence(int, int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.substring(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.substring(int, int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.trimToSize(): missing in
>> /home/stefano/data/japi/sun1.5
>>
>> javax.management.remote.rmi:
>> Missing
>> class javax.management.remote.rmi._RMIConnectionImpl_Tie: missing in
>> /home/stefano/data/japi/sun1.5
>> class javax.management.remote.rmi._RMIServerImpl_Tie: missing in
>> /home/stefano/data/japi/sun1.5
>>
>> javax.xml.datatype:
>> Bad
>> field
>> javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
>> constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
>> /home/stefano/data/japi/ibm1.5, but constant
>> [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
>> in /home/stefano/data/japi/sun1.5
>>
>> org.omg.stub.java.lang:
>> Missing
>> package org.omg.stub.java.lang: missing in /home/stefano/data/japi/sun1.5
>>
>> org.omg.stub.java.security:
>> Missing
>> package org.omg.stub.java.security: missing in
>> /home/stefano/data/japi/sun1.5
>>
>> org.omg.stub.java.util:
>> Missing
>> package org.omg.stub.java.util: missing in /home/stefano/data/japi/sun1.5
>>
>> org.w3c.dom.html:
>> Missing
>> method org.w3c.dom.html.HTMLOptionElement.setIndex(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method org.w3c.dom.html.HTMLTableCellElement.setCellIndex(int): missing
>> in /home/stefano/data/japi/sun1.5
>> method
>> org.w3c.dom.html.HTMLTableRowElement.setCells(org.w3c.dom.html.HTMLCollection):
>> missing in /home/stefano/data/japi/sun1.5
>> method org.w3c.dom.html.HTMLTableRowElement.setRowIndex(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method org.w3c.dom.html.HTMLTableRowElement.setSectionRowIndex(int):
>> missing in /home/stefano/data/japi/sun1.5
>>
>> org.w3c.dom.xpath:
>> Missing
>> package org.w3c.dom.xpath: missing in /home/stefano/data/japi/sun1.5
>>
>> - o -
>>
>> First the not-so-shocking things:
>>
>> 1) IBM ships with xpath support with DOM, while Sun does not. Is this
>> true of it's a bug?
>>
>> 2) IBM has a 'stub' subpackage of org.omg that Sun does not have
>>
>> but the real shocker is that japitools reports that IBM has *modified*
>> the java.lang.StringBuilder class and added *15* new methods to it!
>>
>> If this is true, how is it possible for this JVM to pass the TCK if you
>> add methods to a java.lang class? Isn't this the kind of stuff that TCKs
>> are supposed to prevent? Can anybody explain to me if this is true or if
>> this is a japi bug?
>>
>> Also, I found out that Japitools triggers some NullPointerExceptions
>> here and there, so it needs some tuning. I'll investigate more.
>>
>> Stay tuned.
>>
>
--
Stefano.
Re: [general] Interesting discoveries playing around with japitools
Posted by Tim Ellison <t....@gmail.com>.
Thanks for doing this Stefano. I'll investigate the Sun/IBM findings
and let you know.
Regards,
Tim
Stefano Mazzocchi wrote:
> Being a sucker for statistics and charts, I've decided to look into
> japitools myself and regenerate the graph of API coverage progress of
> harmony.
>
> In doing so, I started to familiarize myself with the Japitools and I
> found a few interesting discoveries: the latest version of the three
> freely available certified java 5 implementations (Sun's, BEA's and
> IBM's) are *NOT* 100% compatible.
>
> So, here's what I did:
>
> 1) download the three JVMs
> 2) download japitools, "tar xzf" it and "cd japitools"
> 3) type:
>
> ./bin/japize as $name packages \
> /path/to/jvms/$name/jre/lib/*.jar \
> +java +javax +org -org.apache -org.ietf
>
> and substitute $name with the JVM name
>
> 4) you'll obtain three $name.japi.gz files (the binary representation
> of your API footprint)
>
> 5) then type "japicompat -s $original.japi.gz $test.japi.gz"
>
> where "original" is the JVM that you consider the reference and $test is
> the one that you want to test.
>
> Here are the (a little surprising, I must say) results:
>
> -- sun 1.5 vs. bea1.5 ---------------------------------------
>
> 99.99% good, 0% missing
>
> java.awt.peer:
> method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
> /home/stefano/data/japi/ibm1.5
>
> -- sun 1.5 vs. ibm1.5 ---------------------------------------
>
> Total: 99.93% good, 0% bad, 0.06% missing
>
> java.awt.peer:
> Missing
> method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
> /home/stefano/data/japi/ibm1.5
>
> javax.xml.datatype:
> Bad
> field
> javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
> constant
> [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
> in /home/stefano/data/japi/sun1.5, but constant
> [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
> /home/stefano/data/japi/ibm1.5
>
> org.omg.stub.javax.management.remote.rmi:
> Missing
> class org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie:
> missing in /home/stefano/data/japi/ibm1.5
> class org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie:
> missing in /home/stefano/data/japi/ibm1.5
>
> org.w3c.dom.html:
> Missing
> method org.w3c.dom.html.HTMLFrameElement.getContentDocument(): missing
> in /home/stefano/data/japi/ibm1.5
> method org.w3c.dom.html.HTMLIFrameElement.getContentDocument(): missing
> in /home/stefano/data/japi/ibm1.5
> method org.w3c.dom.html.HTMLObjectElement.getContentDocument(): missing
> in /home/stefano/data/japi/ibm1.5
> method org.w3c.dom.html.HTMLOptionElement.setSelected(boolean): missing
> in /home/stefano/data/japi/ibm1.5
>
> - o -
>
> There is one method that both Bea and IBM don't implement in
> awt.peer.WindowPeer and apparently, Sun doesn't implement it either..
> it's just a stub! Weird.
>
> [see more at http://forums.java.net/jive/thread.jspa?messageID=167137]
>
> the differences in datatype factory is plausible and the fact that a
> stub RMI class is missing is not that big of a deal. It's weird though,
> that the DOM in IBM's is different than the DOM in Sun's... I guess not
> that many people use the HTML DOM in java or they would have got that ;-)
>
> The really crazy things start to happen if you flip things around and
> you consider the 'clean room rewrites' as the reference implementations:
>
> -- bea1.5 vs. sun1.5 --------------------------------------------
>
> Total: 99.98% good, 0.01% missing
>
> javax.xml.namespace:
> Missing
> class javax.xml.namespace.QName: missing in /home/stefano/data/japi/sun1.5
>
> Uh? Sun forgot to ship the QName class or this is a japitools bug?
>
> googling up shows the class in the java1.5 docs so it's more likely it's
> a bug in japitools
>
> http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/namespace/QName.html
>
> Gets more interesting with IBM:
>
> -- ibm1.5 vs. sun1.5 --------------------------------------------
>
> Total: 99.77% good, 0% bad, 0.22% missing
>
> java.lang:
> Missing
> method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
> in /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.capacity(): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.charAt(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.codePointAt(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.codePointBefore(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.codePointCount(int, int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.ensureCapacity(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.getChars(int, int, char[], int): missing
> in /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.length(): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.offsetByCodePoints(int, int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.setCharAt(int, char): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.setLength(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.subSequence(int, int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.substring(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.substring(int, int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.trimToSize(): missing in
> /home/stefano/data/japi/sun1.5
>
> javax.management.remote.rmi:
> Missing
> class javax.management.remote.rmi._RMIConnectionImpl_Tie: missing in
> /home/stefano/data/japi/sun1.5
> class javax.management.remote.rmi._RMIServerImpl_Tie: missing in
> /home/stefano/data/japi/sun1.5
>
> javax.xml.datatype:
> Bad
> field
> javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
> constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
> /home/stefano/data/japi/ibm1.5, but constant
> [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
> in /home/stefano/data/japi/sun1.5
>
> org.omg.stub.java.lang:
> Missing
> package org.omg.stub.java.lang: missing in /home/stefano/data/japi/sun1.5
>
> org.omg.stub.java.security:
> Missing
> package org.omg.stub.java.security: missing in
> /home/stefano/data/japi/sun1.5
>
> org.omg.stub.java.util:
> Missing
> package org.omg.stub.java.util: missing in /home/stefano/data/japi/sun1.5
>
> org.w3c.dom.html:
> Missing
> method org.w3c.dom.html.HTMLOptionElement.setIndex(int): missing in
> /home/stefano/data/japi/sun1.5
> method org.w3c.dom.html.HTMLTableCellElement.setCellIndex(int): missing
> in /home/stefano/data/japi/sun1.5
> method
> org.w3c.dom.html.HTMLTableRowElement.setCells(org.w3c.dom.html.HTMLCollection):
> missing in /home/stefano/data/japi/sun1.5
> method org.w3c.dom.html.HTMLTableRowElement.setRowIndex(int): missing in
> /home/stefano/data/japi/sun1.5
> method org.w3c.dom.html.HTMLTableRowElement.setSectionRowIndex(int):
> missing in /home/stefano/data/japi/sun1.5
>
> org.w3c.dom.xpath:
> Missing
> package org.w3c.dom.xpath: missing in /home/stefano/data/japi/sun1.5
>
> - o -
>
> First the not-so-shocking things:
>
> 1) IBM ships with xpath support with DOM, while Sun does not. Is this
> true of it's a bug?
>
> 2) IBM has a 'stub' subpackage of org.omg that Sun does not have
>
> but the real shocker is that japitools reports that IBM has *modified*
> the java.lang.StringBuilder class and added *15* new methods to it!
>
> If this is true, how is it possible for this JVM to pass the TCK if you
> add methods to a java.lang class? Isn't this the kind of stuff that TCKs
> are supposed to prevent? Can anybody explain to me if this is true or if
> this is a japi bug?
>
> Also, I found out that Japitools triggers some NullPointerExceptions
> here and there, so it needs some tuning. I'll investigate more.
>
> Stay tuned.
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [general] Interesting discoveries playing around with japitools
Posted by Paulex Yang <pa...@gmail.com>.
Stefano Mazzocchi wrote:
> Paulex Yang wrote:
>
>> Gets more interesting with IBM:
>>
>>> -- ibm1.5 vs. sun1.5 --------------------------------------------
>>>
>>> Total: 99.77% good, 0% bad, 0.22% missing
>>>
>>> java.lang:
>>> Missing
>>> method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
>>> in /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.capacity(): missing in
>>> /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.charAt(int): missing in
>>> /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.codePointAt(int): missing in
>>> /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.codePointBefore(int): missing in
>>> /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.codePointCount(int, int): missing in
>>> /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.ensureCapacity(int): missing in
>>> /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.getChars(int, int, char[], int): missing
>>> in /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.length(): missing in
>>> /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.offsetByCodePoints(int, int): missing in
>>> /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.setCharAt(int, char): missing in
>>> /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.setLength(int): missing in
>>> /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.subSequence(int, int): missing in
>>> /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.substring(int): missing in
>>> /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.substring(int, int): missing in
>>> /home/stefano/data/japi/sun1.5
>>> method java.lang.StringBuilder.trimToSize(): missing in
>>> /home/stefano/data/japi/sun1.5
>>>
>>>
>> It IS more interesting, because there methods are included in Java 5 API
>> Doc (except the first one)!...there may be some problem happened to JAPI
>> or the Sun JDK' rt.jar...;-)
>>
>
> Paulex, good catch!
>
> It might well be a japitools bug, then. I did look into the javadoc and
> stopped after I realized that the first method wasn't there... but I
> should have continued.
>
> Anyway, even a single method should be enough to trigger a TCK reaction
> (since this is clearly against Sun WORA policies).
>
Indeed.
--
Paulex Yang
China Software Development Lab
IBM
Re: [general] Interesting discoveries playing around with japitools
Posted by Stefano Mazzocchi <st...@apache.org>.
Paulex Yang wrote:
> Gets more interesting with IBM:
>> -- ibm1.5 vs. sun1.5 --------------------------------------------
>>
>> Total: 99.77% good, 0% bad, 0.22% missing
>>
>> java.lang:
>> Missing
>> method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
>> in /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.capacity(): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.charAt(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.codePointAt(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.codePointBefore(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.codePointCount(int, int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.ensureCapacity(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.getChars(int, int, char[], int): missing
>> in /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.length(): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.offsetByCodePoints(int, int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.setCharAt(int, char): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.setLength(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.subSequence(int, int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.substring(int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.substring(int, int): missing in
>> /home/stefano/data/japi/sun1.5
>> method java.lang.StringBuilder.trimToSize(): missing in
>> /home/stefano/data/japi/sun1.5
>>
> It IS more interesting, because there methods are included in Java 5 API
> Doc (except the first one)!...there may be some problem happened to JAPI
> or the Sun JDK' rt.jar...;-)
Paulex, good catch!
It might well be a japitools bug, then. I did look into the javadoc and
stopped after I realized that the first method wasn't there... but I
should have continued.
Anyway, even a single method should be enough to trigger a TCK reaction
(since this is clearly against Sun WORA policies).
--
Stefano.
Re: [general] Interesting discoveries playing around with japitools
Posted by Paulex Yang <pa...@gmail.com>.
Gets more interesting with IBM:
> -- ibm1.5 vs. sun1.5 --------------------------------------------
>
> Total: 99.77% good, 0% bad, 0.22% missing
>
> java.lang:
> Missing
> method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
> in /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.capacity(): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.charAt(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.codePointAt(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.codePointBefore(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.codePointCount(int, int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.ensureCapacity(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.getChars(int, int, char[], int): missing
> in /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.length(): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.offsetByCodePoints(int, int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.setCharAt(int, char): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.setLength(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.subSequence(int, int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.substring(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.substring(int, int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.trimToSize(): missing in
> /home/stefano/data/japi/sun1.5
>
It IS more interesting, because there methods are included in Java 5 API
Doc (except the first one)!...there may be some problem happened to JAPI
or the Sun JDK' rt.jar...;-)
> javax.management.remote.rmi:
> Missing
> class javax.management.remote.rmi._RMIConnectionImpl_Tie: missing in
> /home/stefano/data/japi/sun1.5
> class javax.management.remote.rmi._RMIServerImpl_Tie: missing in
> /home/stefano/data/japi/sun1.5
>
> javax.xml.datatype:
> Bad
> field
> javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
> constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
> /home/stefano/data/japi/ibm1.5, but constant
> [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
> in /home/stefano/data/japi/sun1.5
>
> org.omg.stub.java.lang:
> Missing
> package org.omg.stub.java.lang: missing in /home/stefano/data/japi/sun1.5
>
> org.omg.stub.java.security:
> Missing
> package org.omg.stub.java.security: missing in
> /home/stefano/data/japi/sun1.5
>
> org.omg.stub.java.util:
> Missing
> package org.omg.stub.java.util: missing in /home/stefano/data/japi/sun1.5
>
> org.w3c.dom.html:
> Missing
> method org.w3c.dom.html.HTMLOptionElement.setIndex(int): missing in
> /home/stefano/data/japi/sun1.5
> method org.w3c.dom.html.HTMLTableCellElement.setCellIndex(int): missing
> in /home/stefano/data/japi/sun1.5
> method
> org.w3c.dom.html.HTMLTableRowElement.setCells(org.w3c.dom.html.HTMLCollection):
> missing in /home/stefano/data/japi/sun1.5
> method org.w3c.dom.html.HTMLTableRowElement.setRowIndex(int): missing in
> /home/stefano/data/japi/sun1.5
> method org.w3c.dom.html.HTMLTableRowElement.setSectionRowIndex(int):
> missing in /home/stefano/data/japi/sun1.5
>
> org.w3c.dom.xpath:
> Missing
> package org.w3c.dom.xpath: missing in /home/stefano/data/japi/sun1.5
>
> - o -
>
> First the not-so-shocking things:
>
> 1) IBM ships with xpath support with DOM, while Sun does not. Is this
> true of it's a bug?
>
> 2) IBM has a 'stub' subpackage of org.omg that Sun does not have
>
> but the real shocker is that japitools reports that IBM has *modified*
> the java.lang.StringBuilder class and added *15* new methods to it!
> If this is true, how is it possible for this JVM to pass the TCK if you
> add methods to a java.lang class? Isn't this the kind of stuff that TCKs
> are supposed to prevent? Can anybody explain to me if this is true or if
> this is a japi bug?
>
> Also, I found out that Japitools triggers some NullPointerExceptions
> here and there, so it needs some tuning. I'll investigate more.
>
> Stay tuned.
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: [general] Interesting discoveries playing around with japitools
Posted by Alexey Petrenko <al...@gmail.com>.
So it looks like I was wrong :)
SY, Alexey
2006/11/6, Alexei Fedotov <al...@gmail.com>:
> Alexey wrote,
> > As far as I remember TCK does not check for signature compatibility.
>
> http://jcp.org/en/resources/tdk reads:
>
> Signature Test tool
>
> The Signature Test tool verifies that a Java technology implementation
> undergoing compatibility testing and its reference APIs are mutually
> compatible as defined in Chapter 13, Binary Compatibility, of The Java
> Language Specification. The tool automates this verification process
> with a signature test algorithm that compares the API under test with
> a reference API.
>
>
> On 11/5/06, Alexey Petrenko <al...@gmail.com> wrote:
> > Really interesting results! :)
> >
> > It seems that japitools are not used for certification :)
> > As far as I remember TCK does not check for signature compatibility.
> > It's just a number (huge number) of tests...
> >
> > SY, Alexey
> >
> > 2006/11/5, Stefano Mazzocchi <st...@apache.org>:
> > > Being a sucker for statistics and charts, I've decided to look into
> > > japitools myself and regenerate the graph of API coverage progress of
> > > harmony.
> > >
> > > In doing so, I started to familiarize myself with the Japitools and I
> > > found a few interesting discoveries: the latest version of the three
> > > freely available certified java 5 implementations (Sun's, BEA's and
> > > IBM's) are *NOT* 100% compatible.
> > >
> > > So, here's what I did:
> > >
> > > 1) download the three JVMs
> > > 2) download japitools, "tar xzf" it and "cd japitools"
> > > 3) type:
> > >
> > > ./bin/japize as $name packages \
> > > /path/to/jvms/$name/jre/lib/*.jar \
> > > +java +javax +org -org.apache -org.ietf
> > >
> > > and substitute $name with the JVM name
> > >
> > > 4) you'll obtain three $name.japi.gz files (the binary representation
> > > of your API footprint)
> > >
> > > 5) then type "japicompat -s $original.japi.gz $test.japi.gz"
> > >
> > > where "original" is the JVM that you consider the reference and $test is
> > > the one that you want to test.
> > >
> > > Here are the (a little surprising, I must say) results:
> > >
> > > -- sun 1.5 vs. bea1.5 ---------------------------------------
> > >
> > > 99.99% good, 0% missing
> > >
> > > java.awt.peer:
> > > method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
> > > /home/stefano/data/japi/ibm1.5
> > >
> > > -- sun 1.5 vs. ibm1.5 ---------------------------------------
> > >
> > > Total: 99.93% good, 0% bad, 0.06% missing
> > >
> > > java.awt.peer:
> > > Missing
> > > method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
> > > /home/stefano/data/japi/ibm1.5
> > >
> > > javax.xml.datatype:
> > > Bad
> > > field
> > > javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
> > > constant
> > > [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
> > > in /home/stefano/data/japi/sun1.5, but constant
> > > [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
> > > /home/stefano/data/japi/ibm1.5
> > >
> > > org.omg.stub.javax.management.remote.rmi:
> > > Missing
> > > class org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie:
> > > missing in /home/stefano/data/japi/ibm1.5
> > > class org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie:
> > > missing in /home/stefano/data/japi/ibm1.5
> > >
> > > org.w3c.dom.html:
> > > Missing
> > > method org.w3c.dom.html.HTMLFrameElement.getContentDocument(): missing
> > > in /home/stefano/data/japi/ibm1.5
> > > method org.w3c.dom.html.HTMLIFrameElement.getContentDocument(): missing
> > > in /home/stefano/data/japi/ibm1.5
> > > method org.w3c.dom.html.HTMLObjectElement.getContentDocument(): missing
> > > in /home/stefano/data/japi/ibm1.5
> > > method org.w3c.dom.html.HTMLOptionElement.setSelected(boolean): missing
> > > in /home/stefano/data/japi/ibm1.5
> > >
> > > - o -
> > >
> > > There is one method that both Bea and IBM don't implement in
> > > awt.peer.WindowPeer and apparently, Sun doesn't implement it either..
> > > it's just a stub! Weird.
> > >
> > > [see more at http://forums.java.net/jive/thread.jspa?messageID=167137]
> > >
> > > the differences in datatype factory is plausible and the fact that a
> > > stub RMI class is missing is not that big of a deal. It's weird though,
> > > that the DOM in IBM's is different than the DOM in Sun's... I guess not
> > > that many people use the HTML DOM in java or they would have got that ;-)
> > >
> > > The really crazy things start to happen if you flip things around and
> > > you consider the 'clean room rewrites' as the reference implementations:
> > >
> > > -- bea1.5 vs. sun1.5 --------------------------------------------
> > >
> > > Total: 99.98% good, 0.01% missing
> > >
> > > javax.xml.namespace:
> > > Missing
> > > class javax.xml.namespace.QName: missing in /home/stefano/data/japi/sun1.5
> > >
> > > Uh? Sun forgot to ship the QName class or this is a japitools bug?
> > >
> > > googling up shows the class in the java1.5 docs so it's more likely it's
> > > a bug in japitools
> > >
> > > http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/namespace/QName.html
> > >
> > > Gets more interesting with IBM:
> > >
> > > -- ibm1.5 vs. sun1.5 --------------------------------------------
> > >
> > > Total: 99.77% good, 0% bad, 0.22% missing
> > >
> > > java.lang:
> > > Missing
> > > method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
> > > in /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.capacity(): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.charAt(int): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.codePointAt(int): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.codePointBefore(int): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.codePointCount(int, int): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.ensureCapacity(int): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.getChars(int, int, char[], int): missing
> > > in /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.length(): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.offsetByCodePoints(int, int): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.setCharAt(int, char): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.setLength(int): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.subSequence(int, int): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.substring(int): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.substring(int, int): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method java.lang.StringBuilder.trimToSize(): missing in
> > > /home/stefano/data/japi/sun1.5
> > >
> > > javax.management.remote.rmi:
> > > Missing
> > > class javax.management.remote.rmi._RMIConnectionImpl_Tie: missing in
> > > /home/stefano/data/japi/sun1.5
> > > class javax.management.remote.rmi._RMIServerImpl_Tie: missing in
> > > /home/stefano/data/japi/sun1.5
> > >
> > > javax.xml.datatype:
> > > Bad
> > > field
> > > javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
> > > constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
> > > /home/stefano/data/japi/ibm1.5, but constant
> > > [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
> > > in /home/stefano/data/japi/sun1.5
> > >
> > > org.omg.stub.java.lang:
> > > Missing
> > > package org.omg.stub.java.lang: missing in /home/stefano/data/japi/sun1.5
> > >
> > > org.omg.stub.java.security:
> > > Missing
> > > package org.omg.stub.java.security: missing in
> > > /home/stefano/data/japi/sun1.5
> > >
> > > org.omg.stub.java.util:
> > > Missing
> > > package org.omg.stub.java.util: missing in /home/stefano/data/japi/sun1.5
> > >
> > > org.w3c.dom.html:
> > > Missing
> > > method org.w3c.dom.html.HTMLOptionElement.setIndex(int): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method org.w3c.dom.html.HTMLTableCellElement.setCellIndex(int): missing
> > > in /home/stefano/data/japi/sun1.5
> > > method
> > > org.w3c.dom.html.HTMLTableRowElement.setCells(org.w3c.dom.html.HTMLCollection):
> > > missing in /home/stefano/data/japi/sun1.5
> > > method org.w3c.dom.html.HTMLTableRowElement.setRowIndex(int): missing in
> > > /home/stefano/data/japi/sun1.5
> > > method org.w3c.dom.html.HTMLTableRowElement.setSectionRowIndex(int):
> > > missing in /home/stefano/data/japi/sun1.5
> > >
> > > org.w3c.dom.xpath:
> > > Missing
> > > package org.w3c.dom.xpath: missing in /home/stefano/data/japi/sun1.5
> > >
> > > - o -
> > >
> > > First the not-so-shocking things:
> > >
> > > 1) IBM ships with xpath support with DOM, while Sun does not. Is this
> > > true of it's a bug?
> > >
> > > 2) IBM has a 'stub' subpackage of org.omg that Sun does not have
> > >
> > > but the real shocker is that japitools reports that IBM has *modified*
> > > the java.lang.StringBuilder class and added *15* new methods to it!
> > >
> > > If this is true, how is it possible for this JVM to pass the TCK if you
> > > add methods to a java.lang class? Isn't this the kind of stuff that TCKs
> > > are supposed to prevent? Can anybody explain to me if this is true or if
> > > this is a japi bug?
> > >
> > > Also, I found out that Japitools triggers some NullPointerExceptions
> > > here and there, so it needs some tuning. I'll investigate more.
> > >
> > > Stay tuned.
> > >
> > > --
> > > Stefano.
> > >
> > >
> >
>
>
> --
> Thank you,
> Alexei
>
Re: [general] Interesting discoveries playing around with japitools
Posted by Alexei Fedotov <al...@gmail.com>.
Alexey wrote,
> As far as I remember TCK does not check for signature compatibility.
http://jcp.org/en/resources/tdk reads:
Signature Test tool
The Signature Test tool verifies that a Java technology implementation
undergoing compatibility testing and its reference APIs are mutually
compatible as defined in Chapter 13, Binary Compatibility, of The Java
Language Specification. The tool automates this verification process
with a signature test algorithm that compares the API under test with
a reference API.
On 11/5/06, Alexey Petrenko <al...@gmail.com> wrote:
> Really interesting results! :)
>
> It seems that japitools are not used for certification :)
> As far as I remember TCK does not check for signature compatibility.
> It's just a number (huge number) of tests...
>
> SY, Alexey
>
> 2006/11/5, Stefano Mazzocchi <st...@apache.org>:
> > Being a sucker for statistics and charts, I've decided to look into
> > japitools myself and regenerate the graph of API coverage progress of
> > harmony.
> >
> > In doing so, I started to familiarize myself with the Japitools and I
> > found a few interesting discoveries: the latest version of the three
> > freely available certified java 5 implementations (Sun's, BEA's and
> > IBM's) are *NOT* 100% compatible.
> >
> > So, here's what I did:
> >
> > 1) download the three JVMs
> > 2) download japitools, "tar xzf" it and "cd japitools"
> > 3) type:
> >
> > ./bin/japize as $name packages \
> > /path/to/jvms/$name/jre/lib/*.jar \
> > +java +javax +org -org.apache -org.ietf
> >
> > and substitute $name with the JVM name
> >
> > 4) you'll obtain three $name.japi.gz files (the binary representation
> > of your API footprint)
> >
> > 5) then type "japicompat -s $original.japi.gz $test.japi.gz"
> >
> > where "original" is the JVM that you consider the reference and $test is
> > the one that you want to test.
> >
> > Here are the (a little surprising, I must say) results:
> >
> > -- sun 1.5 vs. bea1.5 ---------------------------------------
> >
> > 99.99% good, 0% missing
> >
> > java.awt.peer:
> > method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
> > /home/stefano/data/japi/ibm1.5
> >
> > -- sun 1.5 vs. ibm1.5 ---------------------------------------
> >
> > Total: 99.93% good, 0% bad, 0.06% missing
> >
> > java.awt.peer:
> > Missing
> > method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
> > /home/stefano/data/japi/ibm1.5
> >
> > javax.xml.datatype:
> > Bad
> > field
> > javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
> > constant
> > [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
> > in /home/stefano/data/japi/sun1.5, but constant
> > [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
> > /home/stefano/data/japi/ibm1.5
> >
> > org.omg.stub.javax.management.remote.rmi:
> > Missing
> > class org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie:
> > missing in /home/stefano/data/japi/ibm1.5
> > class org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie:
> > missing in /home/stefano/data/japi/ibm1.5
> >
> > org.w3c.dom.html:
> > Missing
> > method org.w3c.dom.html.HTMLFrameElement.getContentDocument(): missing
> > in /home/stefano/data/japi/ibm1.5
> > method org.w3c.dom.html.HTMLIFrameElement.getContentDocument(): missing
> > in /home/stefano/data/japi/ibm1.5
> > method org.w3c.dom.html.HTMLObjectElement.getContentDocument(): missing
> > in /home/stefano/data/japi/ibm1.5
> > method org.w3c.dom.html.HTMLOptionElement.setSelected(boolean): missing
> > in /home/stefano/data/japi/ibm1.5
> >
> > - o -
> >
> > There is one method that both Bea and IBM don't implement in
> > awt.peer.WindowPeer and apparently, Sun doesn't implement it either..
> > it's just a stub! Weird.
> >
> > [see more at http://forums.java.net/jive/thread.jspa?messageID=167137]
> >
> > the differences in datatype factory is plausible and the fact that a
> > stub RMI class is missing is not that big of a deal. It's weird though,
> > that the DOM in IBM's is different than the DOM in Sun's... I guess not
> > that many people use the HTML DOM in java or they would have got that ;-)
> >
> > The really crazy things start to happen if you flip things around and
> > you consider the 'clean room rewrites' as the reference implementations:
> >
> > -- bea1.5 vs. sun1.5 --------------------------------------------
> >
> > Total: 99.98% good, 0.01% missing
> >
> > javax.xml.namespace:
> > Missing
> > class javax.xml.namespace.QName: missing in /home/stefano/data/japi/sun1.5
> >
> > Uh? Sun forgot to ship the QName class or this is a japitools bug?
> >
> > googling up shows the class in the java1.5 docs so it's more likely it's
> > a bug in japitools
> >
> > http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/namespace/QName.html
> >
> > Gets more interesting with IBM:
> >
> > -- ibm1.5 vs. sun1.5 --------------------------------------------
> >
> > Total: 99.77% good, 0% bad, 0.22% missing
> >
> > java.lang:
> > Missing
> > method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
> > in /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.capacity(): missing in
> > /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.charAt(int): missing in
> > /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.codePointAt(int): missing in
> > /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.codePointBefore(int): missing in
> > /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.codePointCount(int, int): missing in
> > /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.ensureCapacity(int): missing in
> > /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.getChars(int, int, char[], int): missing
> > in /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.length(): missing in
> > /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.offsetByCodePoints(int, int): missing in
> > /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.setCharAt(int, char): missing in
> > /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.setLength(int): missing in
> > /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.subSequence(int, int): missing in
> > /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.substring(int): missing in
> > /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.substring(int, int): missing in
> > /home/stefano/data/japi/sun1.5
> > method java.lang.StringBuilder.trimToSize(): missing in
> > /home/stefano/data/japi/sun1.5
> >
> > javax.management.remote.rmi:
> > Missing
> > class javax.management.remote.rmi._RMIConnectionImpl_Tie: missing in
> > /home/stefano/data/japi/sun1.5
> > class javax.management.remote.rmi._RMIServerImpl_Tie: missing in
> > /home/stefano/data/japi/sun1.5
> >
> > javax.xml.datatype:
> > Bad
> > field
> > javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
> > constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
> > /home/stefano/data/japi/ibm1.5, but constant
> > [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
> > in /home/stefano/data/japi/sun1.5
> >
> > org.omg.stub.java.lang:
> > Missing
> > package org.omg.stub.java.lang: missing in /home/stefano/data/japi/sun1.5
> >
> > org.omg.stub.java.security:
> > Missing
> > package org.omg.stub.java.security: missing in
> > /home/stefano/data/japi/sun1.5
> >
> > org.omg.stub.java.util:
> > Missing
> > package org.omg.stub.java.util: missing in /home/stefano/data/japi/sun1.5
> >
> > org.w3c.dom.html:
> > Missing
> > method org.w3c.dom.html.HTMLOptionElement.setIndex(int): missing in
> > /home/stefano/data/japi/sun1.5
> > method org.w3c.dom.html.HTMLTableCellElement.setCellIndex(int): missing
> > in /home/stefano/data/japi/sun1.5
> > method
> > org.w3c.dom.html.HTMLTableRowElement.setCells(org.w3c.dom.html.HTMLCollection):
> > missing in /home/stefano/data/japi/sun1.5
> > method org.w3c.dom.html.HTMLTableRowElement.setRowIndex(int): missing in
> > /home/stefano/data/japi/sun1.5
> > method org.w3c.dom.html.HTMLTableRowElement.setSectionRowIndex(int):
> > missing in /home/stefano/data/japi/sun1.5
> >
> > org.w3c.dom.xpath:
> > Missing
> > package org.w3c.dom.xpath: missing in /home/stefano/data/japi/sun1.5
> >
> > - o -
> >
> > First the not-so-shocking things:
> >
> > 1) IBM ships with xpath support with DOM, while Sun does not. Is this
> > true of it's a bug?
> >
> > 2) IBM has a 'stub' subpackage of org.omg that Sun does not have
> >
> > but the real shocker is that japitools reports that IBM has *modified*
> > the java.lang.StringBuilder class and added *15* new methods to it!
> >
> > If this is true, how is it possible for this JVM to pass the TCK if you
> > add methods to a java.lang class? Isn't this the kind of stuff that TCKs
> > are supposed to prevent? Can anybody explain to me if this is true or if
> > this is a japi bug?
> >
> > Also, I found out that Japitools triggers some NullPointerExceptions
> > here and there, so it needs some tuning. I'll investigate more.
> >
> > Stay tuned.
> >
> > --
> > Stefano.
> >
> >
>
--
Thank you,
Alexei
Re: [general] Interesting discoveries playing around with japitools
Posted by Alexey Petrenko <al...@gmail.com>.
Really interesting results! :)
It seems that japitools are not used for certification :)
As far as I remember TCK does not check for signature compatibility.
It's just a number (huge number) of tests...
SY, Alexey
2006/11/5, Stefano Mazzocchi <st...@apache.org>:
> Being a sucker for statistics and charts, I've decided to look into
> japitools myself and regenerate the graph of API coverage progress of
> harmony.
>
> In doing so, I started to familiarize myself with the Japitools and I
> found a few interesting discoveries: the latest version of the three
> freely available certified java 5 implementations (Sun's, BEA's and
> IBM's) are *NOT* 100% compatible.
>
> So, here's what I did:
>
> 1) download the three JVMs
> 2) download japitools, "tar xzf" it and "cd japitools"
> 3) type:
>
> ./bin/japize as $name packages \
> /path/to/jvms/$name/jre/lib/*.jar \
> +java +javax +org -org.apache -org.ietf
>
> and substitute $name with the JVM name
>
> 4) you'll obtain three $name.japi.gz files (the binary representation
> of your API footprint)
>
> 5) then type "japicompat -s $original.japi.gz $test.japi.gz"
>
> where "original" is the JVM that you consider the reference and $test is
> the one that you want to test.
>
> Here are the (a little surprising, I must say) results:
>
> -- sun 1.5 vs. bea1.5 ---------------------------------------
>
> 99.99% good, 0% missing
>
> java.awt.peer:
> method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
> /home/stefano/data/japi/ibm1.5
>
> -- sun 1.5 vs. ibm1.5 ---------------------------------------
>
> Total: 99.93% good, 0% bad, 0.06% missing
>
> java.awt.peer:
> Missing
> method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
> /home/stefano/data/japi/ibm1.5
>
> javax.xml.datatype:
> Bad
> field
> javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
> constant
> [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
> in /home/stefano/data/japi/sun1.5, but constant
> [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
> /home/stefano/data/japi/ibm1.5
>
> org.omg.stub.javax.management.remote.rmi:
> Missing
> class org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie:
> missing in /home/stefano/data/japi/ibm1.5
> class org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie:
> missing in /home/stefano/data/japi/ibm1.5
>
> org.w3c.dom.html:
> Missing
> method org.w3c.dom.html.HTMLFrameElement.getContentDocument(): missing
> in /home/stefano/data/japi/ibm1.5
> method org.w3c.dom.html.HTMLIFrameElement.getContentDocument(): missing
> in /home/stefano/data/japi/ibm1.5
> method org.w3c.dom.html.HTMLObjectElement.getContentDocument(): missing
> in /home/stefano/data/japi/ibm1.5
> method org.w3c.dom.html.HTMLOptionElement.setSelected(boolean): missing
> in /home/stefano/data/japi/ibm1.5
>
> - o -
>
> There is one method that both Bea and IBM don't implement in
> awt.peer.WindowPeer and apparently, Sun doesn't implement it either..
> it's just a stub! Weird.
>
> [see more at http://forums.java.net/jive/thread.jspa?messageID=167137]
>
> the differences in datatype factory is plausible and the fact that a
> stub RMI class is missing is not that big of a deal. It's weird though,
> that the DOM in IBM's is different than the DOM in Sun's... I guess not
> that many people use the HTML DOM in java or they would have got that ;-)
>
> The really crazy things start to happen if you flip things around and
> you consider the 'clean room rewrites' as the reference implementations:
>
> -- bea1.5 vs. sun1.5 --------------------------------------------
>
> Total: 99.98% good, 0.01% missing
>
> javax.xml.namespace:
> Missing
> class javax.xml.namespace.QName: missing in /home/stefano/data/japi/sun1.5
>
> Uh? Sun forgot to ship the QName class or this is a japitools bug?
>
> googling up shows the class in the java1.5 docs so it's more likely it's
> a bug in japitools
>
> http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/namespace/QName.html
>
> Gets more interesting with IBM:
>
> -- ibm1.5 vs. sun1.5 --------------------------------------------
>
> Total: 99.77% good, 0% bad, 0.22% missing
>
> java.lang:
> Missing
> method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
> in /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.capacity(): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.charAt(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.codePointAt(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.codePointBefore(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.codePointCount(int, int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.ensureCapacity(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.getChars(int, int, char[], int): missing
> in /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.length(): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.offsetByCodePoints(int, int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.setCharAt(int, char): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.setLength(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.subSequence(int, int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.substring(int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.substring(int, int): missing in
> /home/stefano/data/japi/sun1.5
> method java.lang.StringBuilder.trimToSize(): missing in
> /home/stefano/data/japi/sun1.5
>
> javax.management.remote.rmi:
> Missing
> class javax.management.remote.rmi._RMIConnectionImpl_Tie: missing in
> /home/stefano/data/japi/sun1.5
> class javax.management.remote.rmi._RMIServerImpl_Tie: missing in
> /home/stefano/data/japi/sun1.5
>
> javax.xml.datatype:
> Bad
> field
> javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
> constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
> /home/stefano/data/japi/ibm1.5, but constant
> [com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
> in /home/stefano/data/japi/sun1.5
>
> org.omg.stub.java.lang:
> Missing
> package org.omg.stub.java.lang: missing in /home/stefano/data/japi/sun1.5
>
> org.omg.stub.java.security:
> Missing
> package org.omg.stub.java.security: missing in
> /home/stefano/data/japi/sun1.5
>
> org.omg.stub.java.util:
> Missing
> package org.omg.stub.java.util: missing in /home/stefano/data/japi/sun1.5
>
> org.w3c.dom.html:
> Missing
> method org.w3c.dom.html.HTMLOptionElement.setIndex(int): missing in
> /home/stefano/data/japi/sun1.5
> method org.w3c.dom.html.HTMLTableCellElement.setCellIndex(int): missing
> in /home/stefano/data/japi/sun1.5
> method
> org.w3c.dom.html.HTMLTableRowElement.setCells(org.w3c.dom.html.HTMLCollection):
> missing in /home/stefano/data/japi/sun1.5
> method org.w3c.dom.html.HTMLTableRowElement.setRowIndex(int): missing in
> /home/stefano/data/japi/sun1.5
> method org.w3c.dom.html.HTMLTableRowElement.setSectionRowIndex(int):
> missing in /home/stefano/data/japi/sun1.5
>
> org.w3c.dom.xpath:
> Missing
> package org.w3c.dom.xpath: missing in /home/stefano/data/japi/sun1.5
>
> - o -
>
> First the not-so-shocking things:
>
> 1) IBM ships with xpath support with DOM, while Sun does not. Is this
> true of it's a bug?
>
> 2) IBM has a 'stub' subpackage of org.omg that Sun does not have
>
> but the real shocker is that japitools reports that IBM has *modified*
> the java.lang.StringBuilder class and added *15* new methods to it!
>
> If this is true, how is it possible for this JVM to pass the TCK if you
> add methods to a java.lang class? Isn't this the kind of stuff that TCKs
> are supposed to prevent? Can anybody explain to me if this is true or if
> this is a japi bug?
>
> Also, I found out that Japitools triggers some NullPointerExceptions
> here and there, so it needs some tuning. I'll investigate more.
>
> Stay tuned.
>
> --
> Stefano.
>
>
Re: [general] Interesting discoveries playing around with japitools
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Stefano Mazzocchi wrote:
> Being a sucker for statistics and charts, I've decided to look into
> japitools myself and regenerate the graph of API coverage progress of
> harmony.
>
> In doing so, I started to familiarize myself with the Japitools and I
> found a few interesting discoveries: the latest version of the three
> freely available certified java 5 implementations (Sun's, BEA's and
> IBM's) are *NOT* 100% compatible.
This is interesting..
[SNIP]
> - o -
>
> First the not-so-shocking things:
>
> 1) IBM ships with xpath support with DOM, while Sun does not. Is this
> true of it's a bug?
>
> 2) IBM has a 'stub' subpackage of org.omg that Sun does not have
>
> but the real shocker is that japitools reports that IBM has *modified*
> the java.lang.StringBuilder class and added *15* new methods to it!
>
> If this is true, how is it possible for this JVM to pass the TCK if you
> add methods to a java.lang class? Isn't this the kind of stuff that TCKs
> are supposed to prevent? Can anybody explain to me if this is true or if
> this is a japi bug?
I was under the impression as well that there are signature tests to
ensure that APIs are complete and don't extend. Very interesting.
IIRC, there were in the other TCKs I've used.
geir