[Top][All Lists]
[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>
signature.asc
Description: This is a digitally signed message part
- a faster rmic, Archit Shah, 2005/02/14
- Message not available
- Message not available
- Re: a faster rmic,
C. Brian Jones <=