Monthly Archive for July, 2008

If you've been designing software for any length of time, you've probably run into the concept of a "deep copy," usually contrasted with a "shallow copy." Wikipedia has a nice explanation.

Shallow copies are pretty straightforward. Most programming languages have a mechanism to make a shallow copy of an arbitrary object without any help from the implementor of the class. In C#, Object.MemberwiseClone does the trick.

Deep copies are a bit trickier. The usual approach in languages like C++, C#, and Java is for the class implementor to write a public Clone method which calls a protected copy constructor. The protected copy constructor recurses the copy operation on any reference or pointer fields in the class. This approach has two main problems. One of the problems has to do with copying graphs of objects. The problem (and an elegant solution) is described nicely here.

The other problem is it is often difficult for the class implementor to decide whether a referenced object should be copied (deep copy) or if that particular object should be shared between the old instance and the new (shallow copy). Sure, this object is being deep copied, but that doesn't mean that every referenced object should be copied as well. Imagine making a copy of a Satellite object where the satellite has a reference to two other objects: one representing its solar panels and the other representing the central body (or planet) that it is orbiting. When copying the satellite, you probably do want to copy its solar panels, but you don't want to copy Mars.

Worse, the choice of which sub-objects to copy and which to share sometimes depends on the intended use of the copy. In other words, the class implementor has no idea what to do. Only the caller of the Clone method knows just how deep the deep copy should be.

Dynamic Geometry Library (DGL) uses a novel (?) approach to object copying that solves both of the usual deep copying problems. I like to think of the pattern as 'copy ballast' because it allows the depth of a copy to be controlled by the user of the class rather than exclusively by its implementor. Even better, it does so without violating encapsulation.

Read on for more information about how this works.

Continue reading 'Copy Ballast: Deep copy or shallow copy? Let the user decide!'

Hello Blogosphere! My name is Zac - this is my second summer interning for the DGL team here at AGI (and taking advantage of the awesome food). While I've come to really appreciate C# and the .Net APIs in my time working on DGL, I started out programming in Java. Lately I've been putting some work into getting DGL to work with Java. One of the easiest ways to do this turned out to be a product called JNBridge. It allows you to call .Net code from Java and vice-versa via automatically generated proxy classes. Feed it a .Net assembly and it'll churn out a .jar file with java classes and methods that have the same names as your .Net originals. Once you reference this .jar and the JNBridge runtime libraries in your Java project, you can instantiate, and call methods on, the proxy classes, as if they were the originals. JNBridge handles all the interop and marshaling for you, either via network sockets or shared memory in the same process.

My experience getting JNBridge up and running wasn't without hiccups - their documentation could have been a little more explicit and I uncovered a bug in their generated proxies - but, after a few support emails, they had a patch for me in under 24 hours (the fix is now included in the normal download on their site).  The other gotcha I ran into was that JNBridge requires the Microsoft .Net implementation - no Mono - so shared memory interop is a Windows-only affair.

Now for some code! To try out JNBridge (and make something that would look cool) I made a demo application that leverages DGL's satellite propagating abilities and the Java SDK from NASA's WorldWind 3D globe. The app is a simple Swing JFrame with a 3D globe control and a text box for entering TLEs. Several TLEs can be entered and their ground tracks will be drawn on the globe. Check it out at the Code Exchange on the AGI Developer Network to see the source.

If you need interoperability between DGL (or anything else .Net) and Java code in a desktop application and you are only deploying on Windows, JNBridge provides a pretty painless solution that requires no extra coding on your part. It may also provide a good solution if you want to deploy a Java-based web application that leverages DGL (though I have yet to explore that). After the initial setup steps, you can pretend you're using native Java objects.