classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a faster rmic


From: C. Brian Jones
Subject: Re: a faster rmic
Date: Tue, 15 Feb 2005 23:29:35 -0500

On Tue, 2005-02-15 at 15:25, Archit Shah wrote:
> Thanks for the reply. I have a few questions below.
> 
> C. Brian Jones wrote:
> >>If there is concern about the dependency on asm, I am open to 
> >>suggestions for an alternate bytecode generating facility. I understand 
> >>there is a gnu.bytecode in kawa [3]. I'm perfectly happy to switch from 
> >>asm to something else if it will ease adoption of my code.
> > 
> > 
> > Yes, that's available as well.  Per is open to improving (accepting
> > patches for) gnu.bytecode as needed.
> 
> I'm not sure I understand. Are you saying it is ok for me to use asm? 
> Are you saying it is preferable for me to switch to gnu.bytecode?

There are no issues with using asm.  I like asm as well and the license
is acceptable.  

> > I haven't added the code to cp-tools yet, but I've been writing junit
> > tests for javap.  You might consider doing the same for rmic.
> 
> Unit testing rmic is a bit problematic. I've been running end to end 
> tests that with a client that download stubs and invokes remote methods. 
> This is not trivially junit-able because it requires at least 2 separate 
> processes with separate classpaths. I'don't really have a good idea for 
> more lightweight testing of rmic. Any ideas on this front are appreciated.

End-to-end rmi testing would be more difficult but not impossible.  For
things like j2ee other unit testing frameworks were developed to make it
easier.  I don't know if there is anything for generic rmi testing.

> PS Any reason you've replied off-list?

Must have made a mistake and used reply instead of reply all.
-- 
Brian Jones <address@hidden>

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]