Thursday, January 16, 2003

Closure: performing asynchronous operations Closure. Today, I'm wishing for a way to do closures in .NET or Java. I have a bunch of SOAP calls and I'd like to save off, parameters and all, and invoke later, without writing any code, or very much. I've been itching to pick up Python again, but all this is sparked by a need to do some testing, and I've got a deadline. I'll probably end up doing this the hard way. [Gordon Weakliem's Radio Weblog] How about this ? e.g. final Whatever something = ...; final Foo foo = ...; workQueue.invokeLater(   new Runnable() {     public void runnable() {       something.doSomething(foo);     }    } );   4:42:58 PM    comment []

Where did that class come from, anyway?. Where did that class come from, anyway?. Tracing back through a few weblog referrer entries, I ended up at Clarkware Consulting, Inc, whose software page lists some useful utilities, including JWhich, a Java version of the "which" command under *nix operating systems. For those of you who never used which, it was a command that when passed the name of an executable file, would traverse the PATH to discover out of which directory the command would be executed--it was invaluable for tracking down PATH problems. In Java, PATH problems equate to CLASSPATH problems. If you've been doing Java for any length of time, you've run into the classic "Doh! No wonder my code's failing--a much earlier version is before the latest build on the CLASSPATH!" Or worse, "Doh! Two different versions of the same jar on the CLASSPATH!" This utility will scan the CLASSPATH and report the absolute filename of the class passed on the command line. Cool. All this really does, though, is help underscore how fundamentally broken the Java ClassLoader model really is. CLASSPATH is a gross hack and should be deprecated immediately (as in entirely absent from JDK 1.5 and up), and issues like verisoning and JAR-to-JAR dependencies resolved in a more sane and reasonable fashion. Anybody out there in bloggerland willing to go in with me on a new JSR? [The Mountain of Worthless Information] Classpaths and ClassLoaders can be very frustrating. The real problem isn't the design of the ClassLoader per se, its we need some packaging mechanism on top of it that can correctly (and automatically) load all the corrent jars for us. There's an interesting open source project called ClassWorlds which tries to provide a simple framework for doing this, using a simple text based config file to describe what jars a piece of software depends on so it can create the necessary tree of ClassLoaders to load (possibly conficting) things into the JVM. This is used right now inside Maven to load both Maven and the plugins and handle all kinds of class-loader issues you can get. Incidentally, ClassWorlds uses a text file, not XML, since loading XML parsers and JAXP is a common cause of ClassLoader problems, particularly with versions of JAXP and XML parsers sometimes being available inside JDKs. An interesting development of this is the uberjar mechanism, where a single, uber jar - containing all your code and all its dependencies, can be created. The neat thing is, you can create this automatically from your Maven build using the uberjar plugin, since Maven understands your projects dependencies. The effect of the uberjar mechanism is not unlike static linking in the C world. It'd be fairly easy to extend this concept of uberjar to have shared library linking. In other words to reuse a Maven's repository of jars so that the uberjar can use jars found in a local repository; if a certain version of a jar is not present on a particular machine it can be dynamically downloaded from one of a number of remote repositories automatically. Now that would totally rock. 2:49:55 PM    comment []

SOAP encoding: method in HTTP header? W3C Choreography Working Group Chartered. I did think that the initial move to accept them into the W3C was an excellent one, as there, they may actually be fixed enough to earn the right to call themselves Web services. Unfortunately, nobody seems to be officially assigned to the task to doing just that (though Hugo and David try to keep things in check, what most people know to be Web services (i.e. putting the method name in the SOAP envelope) is a fundamentally broken style for the Internet), which is why I've been doing it. [Mark Baker, Tech Curmudgeon] Dumb question of the day (and this could be that I'm a little hungover today and not had much coffee)... Is there anything that precludes having a SOAP transport for HTTP which also includes the method name in the HTTP header or URL? i.e. having a method name inside the SOAP envelope to keep the SOAP stack happy but also having this information in the HTTP header to keep the web/HTTP stacks happy too. 11:05:46 AM    comment []