Letters to the Editor

1 2 Page 2
Page 2 of 2

, and developers might forget to call


-- also, from what part of their code would they call that method (most likely, the constructor)? To sum up, every interface represents a contract, whether or not that interface declares methods. Jeff Friesen

'Master Merlin's new I/O classes'

Michael T. Nygard

Will the new I/O classes improve RMI performance?


Do you think these new I/O classes can increase RMI (Remote Method Invocation) performance? If yes, do you know if some plans exist?

Tony Reix

Tony, That's an interesting idea. I haven't given it any thought before this, but at first glance, it would seem that buffer pooling would be the first place to start optimizing RMI. Preconstructing buffers for common Ramp operations would be a good start. Reusing a pool of fixed-size buffers would also be an excellent approach. I don't think the asynchronous I/O would buy much, since RMI has strict blocking-call semantics. Michael T. Nygard

'Test infect your Enterprise JavaBeans'

Michael T. Nygard and Tracie Karsjens

How does unit testing differ from Cactus?


What is the main difference between your framework and Cactus? It seems that in Cactus, you cannot test EJBs (Enterprise JavaBeans) that use container services (which is a big limitation). Does your framework feature this problem too (it doesn't seem to)? The main advantage I see with Cactus is that you can run it from the command line.


Navjeet, The biggest difference between the technique demonstrated in the article and Cactus is its scope. The servlet we developed in the article is limited in its intent. Cactus aims to provide a much more complete framework for unit testing Java 2 Platform, Enterprise Edition (J2EE) services. It will ultimately allow for in-container or mock object testing. I like the direction that Cactus is going. In fact, if you are looking for the more complete framework, I would say Cactus is the way to go. Michael T. Nygard

1 2 Page 2
Page 2 of 2