Outstanding ClassDep issues

[Mark Brouwer <ma...@cheiron.org>]

Hi all,

Looking into other issues for ClassDep I noticed
https://issues.apache.org/jira/browse/RIVER-82, RIVER-203, RIVER-163 and
RIVER-272.

With regard to RIVER-82 Fred's comments indicate something strange is
going on, I wonder what would be against using a Set for the found
classes instead of a List to filter out any duplicates, that will hide
the underlying problem?

With regard to RIVER-230 I'm wondering whether the request for
improvement is "a good thing", given the fact that ClassDep specifies
Platform specific classpaths and file paths. I don't think we should
take 'advantage' of the fact Java also accepts the wrong file separator
for the Windows platform. I believe that Ant can provide the proper
abstraction layer so you won't run into any problems as the build files
of the River project show, or that other Ant tasks on top of ClassDep
provide. Personally I would like to close RIVER-203 as "Won't fix", but
maybe I'm missing something, so please shoot if my reasoning is wrong.

I'm also curious to find out whether RIVER-163 can be fixed. From the
bugparade I get the impression that the sun.tools.* API will be removed
in time (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4633413)
and given RIVER-272 I think it might be interesting to start looking for
an alternative. From a quick scan it seems that ASM might do the trick
and given the fact it is BSD licensed I see no reason not to depend on
it. If there are opinions about a JRE vendor independent ClassDep and
solution to RIVER-163 please let me know.

Regards,
-- 
Mark

Re: Outstanding ClassDep issues

[Mark Brouwer <ma...@cheiron.org>]

Hi Patrick,

Patrick Wright wrote:
> Hi Mark
> 
> The main problem I've seen with ASM (as an end-user of libraries in
> which it is used) is that the ASM team makes breaking API changes even
> within minor releases. This causes no end of heartache if you inherit
> an ASM dependency, at runtime, from two different libraries. The
> workaround in that case is to use something like JarJar, which munges
> package names to produce unique versions of the library. If you're
> using ASM standalone it shouldn't be an issue, unless, again, other
> dependencies cause a different version to land in your classpath. I've
> run into this issue with ASM more than once just in the last
> half-year. OTOH, it's a well-regarded library for what it does.

Thanks for mentioning and warning. This is certainly something to 
consider if ClassDep would depend on ASM. I expect the usage of ClassDep 
mainly to be at build time but in case of Ant you never know what people 
put in the Ant lib directory.
-- 
Mark

Re: Outstanding ClassDep issues

[Patrick Wright <pd...@gmail.com>]

Hi Mark

The main problem I've seen with ASM (as an end-user of libraries in
which it is used) is that the ASM team makes breaking API changes even
within minor releases. This causes no end of heartache if you inherit
an ASM dependency, at runtime, from two different libraries. The
workaround in that case is to use something like JarJar, which munges
package names to produce unique versions of the library. If you're
using ASM standalone it shouldn't be an issue, unless, again, other
dependencies cause a different version to land in your classpath. I've
run into this issue with ASM more than once just in the last
half-year. OTOH, it's a well-regarded library for what it does.


Regards
Patrick

Re: Outstanding ClassDep issues

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:
> Mark Brouwer wrote:
>> I currently have some sort of prototype based on the ASM core (only 42
>> KBytes) and it seems to tackle generics, annotations, instanceof and
>> maybe some other things that were missed by ClassDep.
> 
> Cool.
> 
>> I would like to have some
>> opinions on dragging in a third party library for this purpose, more 
>> information about ASM such as the license is here 
>> http://asm.objectweb.org/
> 
> Fine by me.  Are you thinking to include it in the River distribution,
> or require users to download it themselves?

Inclusion would be my preferred way as people shouldn't be chasing (the
right) depedencies themselves.
-- 
Mark

Re: Outstanding ClassDep issues

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> I currently have some sort of prototype based on the ASM core (only 42
> KBytes) and it seems to tackle generics, annotations, instanceof and
> maybe some other things that were missed by ClassDep.

Cool.

> I would like to have some
> opinions on dragging in a third party library for this purpose, more 
> information about ASM such as the license is here http://asm.objectweb.org/

Fine by me.  Are you thinking to include it in the River distribution,
or require users to download it themselves?

- Bob

Re: Outstanding ClassDep issues

[Mark Brouwer <ma...@cheiron.org>]

Mark Brouwer wrote:

> I'm also curious to find out whether RIVER-163 can be fixed. From the
> bugparade I get the impression that the sun.tools.* API will be removed
> in time (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4633413)
> and given RIVER-272 I think it might be interesting to start looking for
> an alternative. From a quick scan it seems that ASM might do the trick
> and given the fact it is BSD licensed I see no reason not to depend on
> it. If there are opinions about a JRE vendor independent ClassDep and
> solution to RIVER-163 please let me know.

I currently have some sort of prototype based on the ASM core (only 42
KBytes) and it seems to tackle generics, annotations, instanceof and
maybe some other things that were missed by ClassDep.

While doing byte code analysis I'm also thinking of solving some other
issues with ClassDep, namely the fact that it can't find property files,
classes obtained through reflection, inclusion of icons. I realize that
not everything will be possible e.g. those cases where the 'resources'
are dynamically assembled instead of being referred by a constant.
Although it is my guess that it covers most cases.

I think for a full working version of ClassDep based on ASM there is
still a lot of work involved, something I don't envision for the next
release, but before spending more time on this I would like to have some
opinions on dragging in a third party library for this purpose, more 
information about ASM such as the license is here http://asm.objectweb.org/
-- 
Mark