Wed, 07 Jan 2004

Things I Wish I Had Time to Code in 2004

I have a lot of itches, and I try scratch a lot of them, but I don't have time for all of them. There are a number of really cool ideas I would love to have time to work on in 2004 but cannot see even the remote possibility of finding that time =/

• JarFu -- Initially just a static dependency analyzer for Java for which you can feed in a list of classes and have it build a jar with all of their dependencies -- and that is it. It should be able to extract class files from the filesystem and jars. Second version might scan for strings and check for availability of classes matching values of string constants and in text files to build a second har with possible reflective dependencies. This would be really nice for working with oddly coupled libraries like many of the jakarta-commons libraries.
• Wicked -- Continuations in Groovy and a Cocoon block so that I can use Groovy for FlowScript. I have gushed enough about Cocoon and FlowScript, but... adding first rate Groovy scripting in place of JavaScript would rock for so many reasons. JavaScript works, but i really miss Ruby-isms and Groovy lets me use most of them in Java (JRuby support for Kernel.callcc would be almost as cool, but Groovy has better Java integration).
• Spool -- Continuations in Java without running a modified JVM or massive compile-time bytecode munging. I don't think it could be done using the current java.lang.Thread so there is the distinct possibility that a lightweigth thread model on top of the current threading support would be needed. Ugh. The other ugly parts with that include capturing the local context and handling thread local variables. I like to think that doing some unpleasent things via ASM or BCEL would allow creating a library to pull off some type of useful continuation support without having to do the munging on client code -- but I don't know without a lot more playing.
• Peel -- Peel is a tool to you to pull apart and recombine objects while correctly maintaining method invocation semantics. You could take an object, pull off part of it as an interface (possibly defined on the fly, or via some anonymous inner class mechanism) and recombine these slices into new objects with the actual invocations going back to the original unsliced object. The anonymous inner class mechanism for defining which methods to peel off would probably have to work with an interception tool in order to intercept calls going to the anonymous class and invoke them on the original instead. I am not sure how useful this would be, but the idea is so cool it makes me shake. Sort of runtime refactoring.
• Magic -- XQuery type munging of Java objects in combination with OJB and a good mixin library. For those not familiar with XQuery -- it is like XPath + XSLT + Methamphetamines. You can specify a query into a set of xml documents and transform the data in situ for further querying and/or use let bindings to create new documents in the context of the query. Magic is built around/into the OR Mapping layer to munge the query and the data returned into the final form requested by the magic query. It would almost definately have to be built on top of something like Peel. The closest example I can try to give might look like

  
  select 
      [ interface Employee { 
          [ public User user : u ] 
          [ public Title title : r.title ] 
          [ public void do(Action) : u.doSomethingSpecificToADomain(Action) ] 
      } ] 
  from 
      org.skife.kendra.User u, org.skife.kendra.Role r 
  where 
      r.title like $1;
  

  This would generate an object (previously undefined), Employee, with two properties (would actually generate the setters/getters, not the fields, the spec in the query is just shorthand) and a method called "do" which takes an Action argument. The query would have to materialize both the User and Role in order to provide these, would map calls to everything to the right place, and would map calls to do(Action) to the User.doSomethingSpecificToADomain(Action) method. James would probaby write a MagicBuilder in Groovy to make building queries easier ;-)

I like all these ideas, but most of them are a bit bigger than I can hope to bite off in the time I don't already have committed (hah). In practice I will probably get to work on:

• OJB -- full JDO support without the JDORI (I want, though don't know how the vote will go, to support a JDO-lite where the bytecode munging isn't required. OJB doesn't need it but the JDO spec requires it. The only place it matters to library clients is if they cheat and try to access the JDO SPI side), better distributed object-space transactions, non-relational backends, clearer and easier support for specifying new query/criteria systems (Magic?), maybe (maybe) I'll work on putting together a plugin to use JDK 1.5 attributes for mapping (optionally) instead of XML configuration.
• Some Intercepted Call K??? library -- Serialization support, factory-ize the broker and provide plugin support for other interception implementations like Nanning, Spring, and ???, maybe provide an AOP Alliance API adapter (I dislike the AOP Alliance naming conventions for an interception-only library as the AOP jargon is just bloody awful -- we know what methods, signatures, and arguments are; we don't all know what pointcuts, advice, and woobledings are)
• Interception and Mixin Stuff -- Various tools built around SICK like the actor-invocation level security rules, a possible entity/domain-model space validation system (if Keith bites on this one it'll be a go, but I am not going to tackle it on my own, I think), expanding the database transaction support, possibly taking a stab at an object-space transaction system, and adding hooks for the various IoC containers.

Maybe come fall I'll get to work on a really smart http proxy in C. If I get really bored maybe I'll start writing javadocs for cglib and bribe Chris to check them in.

Who am I kidding, at least one or two on my wish list will probably^H^H^H^H^H^H^H^H hopefully be tackled =) Magic may be pushing it though.

9 writebacks [/src] permanent link

© 2003-2008 Brian McCallister