As I mentioned last week, I’m currently doing some Java work with an investment banking client. This week I added JMock to their toolset.
JMock is a dynamic mock object generation tool that works with JUnit to allow you to create mock objects without writing code. Since most of my TDD work has been in C++, most of the mock objects that I’ve used in the past have been hand coded.
I started back with an investment banking client this week. I’m working with the team that brought us “the refactoring project” and another small team, and integrating the trade entry system with some “xll” excel addins and some back end server software. Pretty standard fare for investment banking work…
I’ve worked with this client quite a few times over the years and it’s interesting to go back and find that they’re still using the systems that I helped them to put in place back in 2001.
I’ve just finished posting some more reprints from back in 2001 when I was working on CORBA systems with C++ and Java.
The articles mostly compare CORBA to COM and show why providing a reference counted server object lifetime management system is harder than it appears.
1 - CORBA - Reference Counting. Adding reference counting to CORBA objects isn’t as easy as it first seems.
2 - CORBA - More Reference Counting.
A common way to improve the performance of Java code is to cache objects rather than repeatedly create and destroy them. This is especially true when you’re writing middle tier servers that service client requests and return results objects. Implementing a flexible caching scheme in Java is relatively easy, but there are a few things to watch for.
The problem Creating objects in the middle tier that live for only the length of a single client request can be inefficient.
When a CORBA server allows its clients to create and destroy objects one of the recommended ways to handle the object lifetime issues is using the Evictor Pattern. In The Evictor Pattern we solved the problem for C++ servers, here we do the same for Java servers.
The problem
Due to the way that CORBA deals with object lifetime issues you may find it necessary to have the server control the lifetime of objects created on the server by the client.
