To me, queries like this give statistical research on code repositories a bad 
name.  You don't appear to have done the most basic research into your dataset. 
 For instance, tomee is the openejb project, renamed, so most of the class 
names are going to be identical.

If you had investigated the "conflicts" between harmony and felix you would 
have seen that these classes are compilation stubs without meaningful 
implementation.  I believe they were automatically generated from the 
appropriate jdk.

Clement has explained what they are for, except for emphasizing they don't 
implement anything and are only for compiling against.

david jencks

On Mar 23, 2014, at 9:46 PM, Pawel Slusarz <[email protected]> wrote:

> Greetings,
> 
> I am investigating duplicate class names across the Apache SF ecosystem.
> I have noticed that Felix features prominently on the matrix of class
> names that are also present in other projects. I would like to
> understand better whether this situation is intentional and whether
> developers are aware of it. For details, locate Felix in the following
> matrix:
> 
> http://pslusarz.github.io/archeology3d/research/apache/conflicting-classes/index.html
> 
> Also, majority (but not all) of the conflicting classes are actually
> standard JDK classes, like java.io.File (for instance:
> http://pslusarz.github.io/archeology3d/research/apache/conflicting-classes/felix_harmony-classlib.html)
> Can someone explain the implications and consequences of overriding JDK
> classes in Felix?
> 
> Thanks for your insight.
> Paul
> 
> PS: Who am I and what's my agenda? I am interested in studying large
> code ecosystems and I am currently looking at Apache SF Java projects.
> The issue of conflicting class names became apparent as I was
> investigating correlations and dependencies. You can find more about
> this approach on the blog: http://10kftcode.blogspot.com/

Reply via email to