techMusings

Mike nails Prevalyer to the tree. Quite amusing really.

Debug builds.

Once upon a time I used to write systems in C. Back then we used to compile most of the time with debug switches on to make the symbol info available in the debugger. Of course this bloated the exes quite a bit so we used to strip the binaries for UAT and production once tested. A little side effect was that a bunch of times the systems stopped working when stripped since the extra debug packing "forgave" the odd minor memory allocation error. Nice.

In Java land, I never compile any other way - of course, since I don't work for a software vendor anymore so the extra symbol info doesn't matter in terms of leaking implementation details.

When trying to find a hard-to-reproduce bug, having lots of extra debug info is great -- which made me think, is there a sane way to provide builds modded with this old chestnut without the side effects noted above? Having that level of info would be worth it's weight in gold - especially if the performance impact can be mitigated.

Bil has now GPL'd Omni, but last time I spoke to him, he wasn't particularly keen on building a community around it. It seems he's now working on Eclipse integration -- good move. I mentioned that some time ago, it's really the best route I reckon.

Jini meeting, part 2.

Brian Murphy
Brian presented on how advancement in any area requires people to break away from the established norms and do things differently. In the end it was a pretty good talk, a relief at last. It certainly explains why Jini is interesting to a lot of people and also why the academic bias in a lot of projects is there -- it's almost the anti-thesis of what corporate IT is all about.

Simplicity

In my day job (technical architect for a bank) I'm always interested in novel design solutions from projet teams. However, the general path I try to guide them on is the one of simplicity. I'm afraid Jini just doesn't satisfy this yet. While the concepts are remarkably simple, the current implementations, infrastructure and other complexities, as far as I can see, fail the KISS tests.

The other problem with Jini is the lack of body of knowledge, both documented on jini.org and in the form of examples. To illustrate, take the one example supplied with the starter kit. OK, so it's quite clever to have 4 classes or so illustrate many combinations of startup configs (network protocols, authentication/activation schemes per service type etc), but that's not really a great way to introduce a newbie.

On installing the starter kit, where'd you expect to find the examples?

./examples?
./demo? (as per the jdk)
./docs?
./samples?

Err, no.

./source/vob/jive/src/com/sun/jini/example/hello/

Right. Though, I have to say, it's almost refreshing to see a Jini/Javaspace example to actually use a package name -- most seem to live in the default namespace. This is presumably done to make compiling from the command line easier. However, Makefiles, yes, Makefiles are used to compile Jini in the starter kit. Not Ant. Not Maven. Makefiles. One of the great strengths of the makefiles is that they run really nicely on any platforn just like the Java code. Err, sorry, no. Unix only please. Not even under cygwin (until after some liberal sprinkling of vi/ex commands and the odd hack).

The Sun guys seemed genuinely keen to find out why jini isn't taking on. Which is nice, but I have to say there are some pretty obvious problems. I'll list a few. I know a bunch of good stuff is coming in 2.1 but wanted to empty my head ...

1. Licence -- BSD/Apache please, otherwise make it a product. I don't want to spend time on something that I can't do what I want with unless there's a low barrier to entry.
2. Productise Jini. Define a spec, not an implementation. Allow decent competition against the standardised interfaces.
3. Evolve. Jini has been around for years. Not much has changed. OK 2.0 gave us Jeri etc, but one of the big changes coming is iterators for a Javaspace. Woo. Can I pass a predicate instance to the space to match entries? Err, no. Not yet. Why not?
   
4. Dogfood -- where are the Sun products? Is Jini baked into the app server? The directory server? Solaris? Jini seems to be almost the perfect way, ostensibly, to build a J2EE app server -- dynamic instance regstration, code deployment, persistent messaging / sessions etc) -- if not, why not?
   
5. Accounting. This is one of the last barriers to trusting code -- I may be able to stop it hitting the filesystem, can I sensibly stop it doing while(true) {} ? If I'm going to host code, I need to be able to stop it without killing the whole process.
   
6. Join thy brethern. Java is huge. J2EE is huge. Get on that bandwagon.
   
   • Is there a standard, supported JCA adapter to call an EJB? No. Yes, there are some thread issues etc to think about, but it can't be that hard, especially since you can push much of it back into the client -- it's then just like any other remote call.
   • Standard JNDI / regie bridge / helpers. Why is reggie not just a DirContext? Waldo was saying to me that he didn't think reggie was a good option for enterprise wide service lookup -- a model is needed.
     
   • Unify the transaction models. OK, so you can generally live without XA/2PC but it makes a lot of projects simpler. I bet outrigger (Javaspace impl) probably doesn't do full recovery - including rolling forward. JTA/XA has momentum -- can I get an Oracle JDBC driver that uses Jini 2PC? I know I can plumb it myself probably, but that's an engineering task -- that's what I want to buy from Sun. Charge me, really. Better yet, make adapters for all sane components (Sybase,Oracle,JMS,Javaspace impls).
     
   • Provide a way to go JMS <--> javaspace.
7. Fix the web site. Where're the docs? It's not clear that Rio is a major project, almost part of the starter kit, it seems. Why are there 10+ container projects? The must be some serious synergy. The new container spec -- is this distinct from Rio? how? Get away from the template site from CollabNet -- why not more like java.sun.com? Much nicer / easier to use.
   
8. Make the experience great.
   I love the stuff codehaus has on some projects: the 1 minute, 5 minute, 10 minute guides to the project (linked as well).
   
   • Get people excited as quickly as possible.
     
   • Then make the download / install / helloWorld a no brainer. All I want is a build.xml, or a shell script -- don't make me compile before running (or make it seemless).
     
   • First example should be a sanity check, minimal stuff. Are the services running? If not why not start them, or tell the user, not a stack trace / barf.
   • Separate examples to show different things. Don't provide multiple classes (hidden as inner classes too) to make things look hyper flexible. There's loads of code in those classes.
   • Supply helpers -- most examples I see supply helper classes. Why aren't these standardised, a la Jakarta commons-jini, say?
   • Get rid of makefiles.
   • Show stuff you can't do easily without Jini.
9. Find a bridge with WebStart -- where's the overlap between this and Jini ServiceUI? Is it just caching? Or versioning of jars too? Can I launch a non-applet from a browser (perhaps via an applet bridge).
10. Just to make it 10 -- Isolation API, how does that work with Jini? Should proxies be different isolates?
    
    Doh! More have popped into my head...
    
    
11. Resolve the non-Java issue. JNI is evil, don't rely on it (or fix it - zero C code). You HAVE to play nice with .NET and others. Surrogate is OK for a subset, but why can't I use discovery and lookup directly from C#? They're based on wire protocols, so should be do-able. Can the implementation requirements of the proxy (ie JVM/CLR) not just be part of the entry's properties? If a CLR gets a Java proxy -- it should be able to bridge across the process.
12. Talk about more than HelloWorld. There seems to be a dearth of intermediate to advence documentation (it's probably only found in email chains). For example, what are the design strategies -- should you pass complex objects, with behaviour, into a proxy? Or should the API's be fairly data centric? That's certainly the impression I've gotten from previous RMI projects. If behaviourly complex objects are passed around, then you REALLY need to make sure they only know about a fixed API. The whole separation of concerns is very important, otherwise you'll end up with a ball of mud -- re-write time!
13. Err, Web Services -- define a sane JAX-RPC bridge, both client and server side. If you want to push to boat, you could define a protocol negotiation based on SOAP headers that allow you to drop to Jini as a pure Java optimisation. Since this can actually be a per-service protocol, massive gains are possible in performance, all without reducing the compatibility with other clients.
    
    I posted the next two on a JINI-USERS posting, but it seems to have died on the moderators cutting room floor.
    
    
14. IoC. The rest of the Java world, including EJB3 are looking to IoC containers to do much of the donkey work of wiring apps together -- this is ideal for Jini. Sorry, can I say that again - Jini plugins for Spring/HiveMind/Pico will increase adoption. In the current trend, everybody is using interfaces and wiring objects with config -- a perfect fit for the nastiness of exporters/SDMs/preparers etc.
15. AOP. The other big trend. Dynamic class loading -- time to instrument those classloaders with aspects. Work with the Aspect* teams to get hooks. This will increase exposure and get Jini into the hands of lots of other early adopter communities -- aspects will also help debug/build these things.
16. Wiki. Trawl the mailing lists and build a wiki FAW with the info -- all the answers are here, get them into the users' hands.
17. Roadmap -- what is it? I hear there's a 2.1, how about 2.2? 3.0?
    

Ok, so a few more things than I expected. I'm sure a few more will appear eventually.

Right, back to the conference.

RFID
An OK session about the use of jini in a customer solution. Like most sessions, I didn't really get into this one. The technical details about the project seemed a bit sparse.

Gary Kendall
Gary's written a mini-calculation grid using Jini. Excel calls a web service which distributes slices of calculations amongst a number of user PCs. This is probably the sweet-spot for simple Jini apps, I think.

F1 Telemetry
Probably the best session of the meeting, imho. Interesting subject, good level of detail of what they did, problems solved, plans for new stuff. Just the structure of this was better than everything else. The single biggest thing, though was the discussion of issues and solutions, also it was a REAL project, not just a university project (not to diss students, but most projects are not worthy of a commercial technology presentation, most are also disturbingly naive).

Mike Warres
Another good session (actually enjoyed this afternoon compared to the paucity of previous sessions). I was getting worried at the start when Mike was suggesting the opaque:

md:314159627

while it would work, can you imagine debugging this? You definitely need the filename, if only for sanity. Good depth, a project to watch.

Community Lessons
A pretty good session about how to break and then fix a Javaspace impl by throwing fairly ambitious (aka silly) problems at it; a whole video stream; each frame of a stream; each pixel?!


Conclusion

Well the Meeting has certainly re-kindled my interest in the Jini world, though after the first day, I was starting to think it was not it good shape. I obviously have a few opinions on what they need to do to increase adoption / mature the offering. I've a couple of other thoughts on Jini ideas, but will use a separate posting, since this one is already too big.

Jini Community Meeting

Actually, I started at the Kickstart session on the Monday before. This was a high level view of Jini and Javaspaces. I suppose I should have read the description in a bit more detail, since the session was very high level and more of an introduction for those who'd never read up or used either technology. The best part was a (unfortunately) brief discussion on when to use Jini/spaces over the more established J2EE based products. The feeling was that compute farms and workflow are the sweet spots, classic client server or pub/sub or even queuing systems should go down the normal roads (eg web/web services).

Pub session (who me?)
Chatted to John ___ , about the continuous bleeding edge nature of Jini/spaces. For example, if Sun believe in the technology, why don't they use it? Where are the products? I get the feeling Jini is pretty much a toy system (in terms of usage rather than potential or capability) -- ie most people pick it up, turn it over then decide that the effort needed to fully understand it, due to lack of overall mindshare / knowledge / experience is too high, and that either a much simpler home grown approach is sufficient or that using J2EE apis instead is the best route.

jini.org
I've just taken another look at the jini.org website, and I have to say it's not very inviting. It doesn't provide (that I can see at first glance) a list of tutorials, list of docs, a list of samples etc. It has a number of links to lots of projects in various states of decay / liveliness. There seems to be x (10, 20+ ?) service container projects --- why so many? Can people not agree on features? I don't want to learn loads of different containers just to get some simple services running without writing my own container.

While I'm ranting, thought I'd complain about the use of project names for all the support services -- reggie (ok I can guess this is something to do with registration), outrigger (err, does what?), mahalo (hmm, not much to give it away), etc, etc. This just raises the barrier to entry since you have to remember the different names for each service. I don't understand why something like registryd, lookupd, javaspaced, transactiond couldn't be used -- at least I'd have a chance of guessing what each one does.

I seem to remember an old Jini distribution by JPower (i think) - this was basically a jboss instance which launch all the services you needed, preconfigured to talk to each other - all you needed was to start a client or service vm. tada. thankyou. goodnight. This is what we need. Talking to Dan Creswell he says his blitz project provides a much nicer experience -- this should be referenced on the jini.org home page instead of the non-starter kit (grr, reg to download...).

Jim Waldo
Arrived a bit late to this one, but Jim was espousing on topic of keeping object models simple and pure, distinct from non-object identity responsibilities like QoS etc. In particular versioning / type evolution is an area that is often fudged creating more problems down the road than solving it upfront. Unfortunately, as Jim stated, no real solutions, best practices or real suggestions for approaches were put forward -- pretty disappointing.

Dave Sag
Dave explains exactly why you shouldn't trust external firms to design systems when the motivation for the supplier is cv-agmentation. He described a bunch of projects that failed to impress, I have to say the lack of positive outcome (or insightful conclusions), didn't encourage me to ever hire his current firm. The self deprecating humour was a bit over done given the lack of depth. Again a bit disappointing.

Mood Ring
Could have been good, but the demo barely worked (I couldn't get on, but that's probs my ancient 98 laptop being daft). Overall, :o/ .

Tom White
An overview on building a (trivial) compute farm using Jini/spaces. Err, isn't this just the Artima intro slides? The system looked very prototypical - no management, worker reloads all classes for each unit of work(!). Not a great presentation, and not much depth, are you starting to see a trend here?

I'll finish this posting here cos a can't be bothered to write up the lightning session... I'll let you draw your own conclusion.