Tuesday, January 15, 2008

Jini in the Skull

Now that I have my uber-huge project out the door, I'm trying to think smarter about development in general. I kept thinking that being smarter about development meant thinking bigger - so I initially tried to get more involved in the infrastructure of things. But it wasn't a good fit in my brain - you can't lose yourself in a PowerEdge like you can lose yourself in a stream of bytecode.

This hit home when I was talking to a previously C++ programmer at work. Because I'm a) lazy and b) often muddle explanations, I often tell new Java developers... whilst stammering and mealy-mouthed... that Java passes objects by reference. This quickly helps people understand(ish) why setting a value on an Object inside a method doesn't necessitate a return value. However, when I say that I'm perpetuating a distinctly wrong concept. One I should be ashamed about.

I try to avoid the long conversation that ensues, but I should tell developers the truth. Java always passes by value, never by reference. In fact, it passes references by value. Most people look at me like a Buick is growing out of my head when I say "passes references by value." But the fact is that variables only hold primitives and references, and are always passed by value.

Take a look at Java is Pass-By-Value, Dammit! It all boils down to this fact: C and Java always pass by value... that's why you can't do the standard "swap" function. For example, in C++ you might do:

Object hello = new("hello");
Object world = new("world");

swap(hello, world);

printf("%s", hello);
printf("%s", world);

void swap(Object obj1, Object obj2) {
Object swap = obj1;
obj1 = obj2;
obj2 = swap;
}

This transposes the value in obj1 with the one in obj2. You should see "world hello" from running this craptastic pseudocode. Try this same code in Java and nothing happens - you've locally overwritten some values, but you didn't swap your references:

Object hello = new Object("hello");
Object world = new Object("world");

swap(hello, world);

System.out.println(hello);
System.out.println(world);

void swap(Object obj1, Object obj2) {
Object swap = obj1;
obj1 = obj2;
obj2 = swap;
}

Here you'll just get "hello world" out - your references remained intact, because you passed by value.

This is ultimately a cleaner way to develop... so it's a major plus for both C and Java. And my New Year's resolution is to stop telling people that Java passes by reference just so I can end the conversation sooner.

On the flip side of the complexity coin, I've been reading the the Jini specification by the Jini community as well as Jini and JavaSpaces Application Development by Robert Flenner. Jini has evidently been around forever, but I've only recently become interested in it. Remember the old pre-turn-of-the-century adage that Java would be running on everything in your house, from your kitchen toaster to the fridge? Evidently around 2000 or so Jini was sold as becoming the premier way Jini could allow your toaster to auto-discover your refrigerator and... er... do... heating and cooling... stuff. Who the hell knows. The idea of automagically connected and integrated micro-device clusters communicating across a mesh network is cool, but practical consumer applications are pretty much nil. Then once EJB's started incorporating RMI, Jini came back to the forefront as an easy way to do the heavy lifting of RMI without the thick refried JavaBean layer.

Once you get Jini up and running, it is wicked cool. Start up your Jini registrar and then poof, services get published across a network. Look for a remote service and poof you can discover it and invoke it - no need for stubs or manual marshalling. Once you get the Jini infrastructure up, you don't have to teach developers how to use it... they just implement an interface and the rest is done for them. You can have a mesh network of peer-to-peer nodes up and running within seconds, and the actual node developers don't even know they've done it.

No crappy WSDL's. No UDDI. No thick & slow SOAP XML transport over HTTP. Bytecode and serialized objects all the way. We're not just talking a faster mode of transport, we're talking about delving down two entire network layers.

The application for such technology is mind-boggling... which maybe is why people aren't using it as much as they could. Damn shame, too.

No comments:

Post a Comment