Jesper, Michael, Stephen,
Great work guys.
* Is it an Ant task?
No.
The new compiler will have one for all modes (IDL->Java, Java->IDL, ...).
Cool.
Excellent again. In so doing it must be beanlike and I hope interface/impl separated :I think what Pete's getting at is the ability to generate stubs onHowever, light is at the end of the tunnel as Jesper from our team started a complete rewrite of the IdlCompiler which will be extended by JavaToIdl functionality once it has reached a certain kind of usable state...
* Does it have dynamic (on the fly) capability?
What exactly do you mean by that ?
the fly - i.e. imagine the compiler mounted as a service - provide
a class, a path, execute, stubs are ready to run ... and be able to
do that repeatedly on demand within a single VM session.
Yes -- that is what he is thinking of. And yes the compiler will support this.
The compiler will support both running as a command line program and as a service in f.ex. a J2EE application server.
IdlToJava itj = new DefaultIdlToJava(); itj.setThis(..); itj.setThat(..); itj.doIt();
Related question: The dynamic use creates Java source and bytecode classfiles?
What we are thinking is that AltRMI could, for CORBA mode, delagate to a bean from something you guys are writing. AltRMI is about the seamless Java-client to Java-server method transport. But by utilising standards such as CORBA (and one day SOAP too), We could have Java-client to C++ Server and C++ client to Java Server (more ususal).
How is this different to the CORBA vision? Well for AltRMI they are plain Java interfaces and plain Java implementing classes. You don't extend anything, implement anything or thorw anything from the transport technology (in the case or RMI that would be UnicastRemoteObject, Remote interface and RemoteException).
Or put it another way, AltRMI is about making it easy for the Java programmer. Do not, at an early stage, choose your transport. Develop and test everything in one VM, then at strategic interface boundaries, choose to client/server separate things. CORBA or SOAP or a native AltRMI transport could be a late choice. Or switching from AltRMI to CORBA after coding, would be a configuration issue.
We can already marshal AltRMI over RMI (hiding it completely), this CORBA step for us would the same thing, but with a twist -> full interoperation with Java languages the other side.
Fingers crossed that you folks are keeping things beanlike. Fingers crossed too that you like the sound of AltRMI, even though it detracts a little from your purist views on IIOP...
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/altrmi/
Regards,
- Paul
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
