what do I know

So today I noticed that my blog got way too many hits from being listed on the Blog section of TheServerSide.com. I even got a comment on the post from the project lead for Grails, which was pretty cool. So needless to say, I had Groovy on the brain on my drive home from work.

I started to think about the use of remote objects in Flex. We use Java to integrate with Flex at the office and I know it’s use with ColdFusion has been a big hit too. This got me to thinking, if Flex can support Java classes, what’s to say that it can’t support Groovy or JRuby or Jython or Rhino or whatever language that falls under the scope of JSR 223? I know Groovy and JRuby can be compiled to Java byte code so why can’t these classes be used as remote objects by Flex? I’m still new to Groovy and JRuby, but I’d assume the only obstacle to integrating the these technologies would be the Java interface exposed by these languages after compilation. Then it clicked in my head, the new javax.script package would normalize this interface to make it easier for developers to integrate. Also, if someone didn’t have Java 6 available, the bean scripting framework (BSF) could just as easily accomplish this goal. Additionally, if remote objects are possible, I have to wonder about how possible it may be to use the RemoteClass metadata to trigger the AMF gateway to play nice.

All of this being said, I’m excited about the possibility of integrating other languages, based on the JVM, into Flex. I know WebOrb has a few options available for .NET, PHP, and RoR apps but my (very limited) understanding is that those integrations are somewhat native to each language. It seems like a very simple layer of abstraction could be written to allow these compiled Java classes to be made available as remote objects in Flex. I can, however, understand why there hasn’t been that much written about the use of classes from scripting languages, based on the JVM, being used as remote objects. Lifecycle Data Services or CF server are required to use remote objects in Flex, from what I understand. I would assume that web services, SOAP and REST-based, are the preferred choice for users of open-source Flex in terms of integration.

Maybe there will be some interest in this topic; maybe Adobe already has adapter built (I didn’t Google that much about the topic as of yet) to address these concerns. Who knows, maybe I’ll get off my tail and actually write some sample code that solves this problem. In any case, out of the box support for any of the scripting languages supported on the JVM would definitely be a cool feature in Flex.

Well, no sooner do I finish blogging about the new scripting integration in Java 6 then did Sean Corfield start to play around with it in the context of CF8. His examples have given me a better understanding of the capabilities of the Invocable interface as it applies to JSR 223 compliant languages. Looks like he had some issues initially going from PHP to CF but the transition to JRuby seemed to have gone pretty smoothly.

From the little I can tell, a CFML engine implementing JSR 223 would open up tons of possibilities for Java containers (possibly even integration of JEE specifications — JTA). ColdFusion application servers could be built using the same scripting engine but provide different features. I could see Smith and possibly Railo benefiting from this initially so I guess I can understand why Adobe was against complying. Adobe has such a monopoly on the CF app server market, even creating the CFML engine to be JSR 223 compliant might cause a demand for it to be open-sourced.

Man, wouldn’t that be awesome?!? An open source CFML engine based on Java. I wonder what types of performance hits we’d have to take, if any? I guess that’d be the great thing, we could choose our implementation at that point. I can’t see BlueDragon, Railo, and Smith not jumping right onto that band wagon and evening the app server playing ground. From some of the review’s Sean’s done on alternative CF servers (also here), I could see this as being that factor that makes people stand up and take notice. Right now, only Adobe can truly say they are 100% CFML compliant because they control the language and the direction of the language, not to mention the audience. An Adobe endorsed CFML engine would mean such great things for our community. I could really see a lot of innovation from tool makers and app server creators alike. Imagine if Mark Drew could create a local context to execute CFML code w/o needing hooks for server to be configured?

Ok, so I’m ranting now, but some cool stuff none the less. Nice intro to the CF community on these technologies Sean.