Skip navigation
ANNOUNCEMENT: community.oracle.com is currently Read only due to planned upgrade until 28-Sep-2020 9:30 AM Pacific Time. Any changes made during Read only mode will be lost and will need to be re-entered when the application is back read/write.

This year was my first time attending JavaOne, and it was a busy week of sessions, keynotes, editing, blogging, and meeting people at the java.net booth and in the halls of Moscone Center.

But the conference I really like is coming up in two weeks.

ADHOC, which starts two weeks from today in Dearborn, MI, is a multi-platform evolution of the old "MacHack" conference. While Mac stuff will probably still dominate, it's now open to all interesting platforms... i.e., anything but Windows. :-)

And while it's nominally a "conference", it's not what you might expect. No 200 foot long video wall. No marketing pitches disguised as sessions. OK, there are still flying objects. And keynotes... except they're given at midnight. And the free food is mostly from Hostess, Little Debbie, and Hungry Howies.

Another big part of ADHOC is the idea of coding at the conference, preferably stuff that's crazy, clever, and useless, for a grand show Friday night. Last year's "hacks" included turning the desktop into a game of "Asteroids" (with the active windows as the asteroids to be shot up), and a progress bar that overflowed and spilled into its containing dialog, eventually drowning its contents in sloshing aqua.

There are sessions too. In fact, I'm presenting one on QuickTime for Java.

The approach of ADHOC curiously coincides with a number of info and help requests I've been receiving regarding programming QTJ — an average of one a day this week and all still needing replies from me — as if a sudden wave of developers has seized onto the technology and is now trying to work past the simple SDK demos and get into hard stuff. Much of it has to do with capture, the Mac version of which was partially broken in an API shuffle last year and has yet to be set right.

Of interest here is the openqtj project on java.net, which aims to provide better demos and documentation than are available from Apple, and to fix pieces that are broken. Sean Gilligan, who I met at the java.net booth at JavaOne, has been building a sample app that aims to be a QTJ equivalent theJMStudio demo of the Java Media Framework. Sean Van Every also has checked in a JNI piece to do image capture, partially alleviating the hole in the official distribution.

So, things are hopping. Hope to see you in Dearborn.

kfarnham

Jeri topples Stalin Blog

Posted by kfarnham Jul 1, 2004

At a previous job, we developed a Jini-based system to discover and expose whichever of our services were present on a customer's network. This led to a large Jini federation within the company's network, which led to problems as we hopped firewalls to remote points on the WAN.

Complicating the matter was the network admins' all-too-typical Stalinist network policies, preferring to lock down every port except for 80, with maybe a few known ports exposed if they could be held to an absolute minimum. This is deadly for most RMI applications, which prefer to communicate over whatever sockets appear to be available.

I asked about this in a Jini session on Tuesday, and was told the answer was coming Wednesday.

Sure enough, session TS-1054 covered Extending RMI with Firewall Traversal and Serialization Caching, with a solution to my problems.

The solution is Jini's new Jini Extensible Remote Interface, aka Jini ERI, or just "Jeri". This new approach to RMI allows for pluggable implementations, allowing you to run your remote calls over old-RMI-type socketry, http, https, even JXTA and in-memory RMI.

So how does Jeri get past Stalin? The solution is to put a remote box outside the firewall or in a DMZ. This "relay" box listens on known ports for the server (inside the firewall) to connect to it. Once connected, the relay can use that connection to the server. The clients see the relay as the service — whether it's the relay box or server box is irrelevant — so they can participate in discovery and remote method calling as normal. Perhaps more importantly, use of an outside box (presumably it could be the box hosting the relay) allows the client to download classes that Jini tells it are needed. This completes the pieces we need for Jini - discovery, dynamic downloading of needed code, and remote method invocation.

And all it costs to keep Stalin from purging our app is a cheep box in the DMZ.

Filter Blog

By date: