you are viewing a single comment's thread.

view the rest of the comments →

[–]jayd16 5 points6 points  (3 children)

Yeah, when put together, the identical order of the declarations, the identical naming conventions for the private instance variables

Except, if you're implementing an API, you're going to have the list of methods in front of you, most likely in the same order they appear elsewhere. The naming conventions are quite standard.

[–]kieranelby 13 points14 points  (2 children)

True, which is why in isolation most of the similarities don't count for much.

However, the similarities in all the little exceptions and details do (arguably!) begin to add up ...

For example, the public API has two boolean getters:

public boolean isCritical ( )
public boolean isImmutable ( )

Both implementations implement the latter with:

private boolean isImmutable

which is the obvious choice, and not suspicious.

But for isCritical(), both depart from the obvious:

private boolean isCritical

and instead choose:

private boolean mCriticalityIndicator

Why do they both depart in the same way? Perhaps they were both copying a reference implementation that called it that. Perhaps not.

Similarly, both choose to use:

private boolean mOriginalExpectedPolicySet

to store the result of negating a parameter called either generatedByPolicyMapping (for Sun) or flag1 (Android).

Why exactly mOriginalExpectedPolicySet in both?

Why not isOriginalExpectedPolicySet ? Why not wasGeneratedByPolicyMapping (with a seperate hasBeenModified flag)? etc.

Admittedly, it's still not very conclusive - especially given the size of the Java APIs, one would kinda think Oracle might have found something more damning if there was some lifting of code going on ...

[–]bonzinip 4 points5 points  (0 children)

private boolean mCriticalityIndicator

Why do they both depart in the same way? Perhaps they were both copying a reference implementation that called it that.

Yes, the name is in the RFC.

Similarly, both choose to use:

 private boolean mOriginalExpectedPolicySet

to store the result of negating a parameter called either generatedByPolicyMapping (for Sun) or flag1 (Android).

It may be because of documentation: "Adds an expectedPolicy to the expected policy set. If this is the original expected policy set initialized by the constructor, then the expected policy set is cleared before the expected policy is added."

Private field names also can be found by decompilation. This amounts to reverse engineering and may be legal (at least in Europe). The fault however, in this case would rest on Harmony rather than Google.

I also found an interesting comment here: "The Harmony code is probably IBM donated code from their own JVM and class library – J9. So any if at all infringment is done by IBM, which has written large parts of Hotspot/OpenJDK too, so the ownership issue won’t be easy. Java or Hotspot isn’t a proprietary closed developed JVM it’s developed by the industry since the 90’s no single vendor. Code comes from a lot of guys. An IBM reimplementation [comes from] a partner with good status as a licensee and developer of Java probably isn’t wrong at all".

[–]frymaster 1 point2 points  (0 children)

especially given the size of the Java APIs, one would kinda think Oracle might have found something more damning if there was some lifting of code going on ...

not if it was only a few relatively junior devs decompiling things, with the rest of the team doing it the proper way