A couple of weekends ago I stepped into my Java developer shoes and attended No Fluff Just Stuff, think cf.Objective() in attendance size, cfUnited Express in local feeling, and cfUnited (or SOTR) for quality of speakers. I wrote up the majority of the entry during that conference. Instead of publishing it at that time I decided to sit on it for a bit before rereading my thoughts and posting this entry. At NFJS Neil Ford talked about polyglot programming, something I myself have joined in about in the past. If you will recall polyglot programming has morphed into this thought process of using the appropriate language to complete a task. The JVM has become a very powerful platform, now supporting some 200+ languages. Most of these languages can interact with one another at some level, if not directly then they can use the the Java level. While CFML happens to be my preferred language to write most of my applications in I have to wonder should frameworks be written in CFML?
Historically we were bound to strictly CFML, putting any part of a framework for CFML apps in Java would require putting the class on the classpath, not so shared hosting friendly. Well we have all progressed and learned a thing or 2 about Java and this traditional thought process needs to evolve some. Thanks to Mark Mandel and some of his crazy cool java class loader work, even if you don't know much about class loaders, we are not bound to our traditional thoughts about how we can load java classes. We can now easily load java classes after server start up from places other than the predefined classpaths. Armed with this knowledge I can now objectively ask, should Fusebox be written in CFML or should it be written in Java (or groovy or anything else that I could consume from CFML)? Even weeks later, presumably after all the Java Kool Aid has left me system, I still am leaning towards Fuseox should be written in Java. Maybe should is a bit too string of a word there, Fusebox could benefit from being implemented, at least in part, in Java. This is not a proclamation that I am going to rewrite Fusebox into Java, remember I said I was going to think out loud when it came to Fusebox development, but I really am leaning towards writing parts of Fusebox in Java.
Subscribe to:
Post Comments (Atom)
6 comments:
What are the advantages of this? Would the application perform better? Could it reduce the size of the community willing / able to contribute to the framework itself?
I had some of the advantages and what not in my post originally but they were so scatter brained I removed it all. I'll try to organize some of that in the future. In short, much of the framework itself is fairly rigid and is littered with things like "for performance reasons this is optional but it is really required." Not condemning it I understand, and appreciate the narrative but if performance tuning is such a concern maybe CFML is not the best idea. Serialization is also another consideration that I have looked at more and more. In the end yeah I will have some hefty requirements for a partial port to java to be consider acceptable. As for the second part of your question the size of the community willing to contribute to the framework itself is all of 1 at the moment, me, so if it is reduced much more we are in bad shape ;) I am confident that many folks could provide help/feedback for a Java written CFML framework. Lexicons and plugins would still maintain their CFMLness so the extension points would not change.
The one thing that I always come back to with moving things to the Java layer is this: Most shared hosting sites (GoDaddy, Sozo, some corporate IT folks...) disallow use of the createObject('java') and related tags. Yes, Java is an incredibly useful and powerful way to get stuff done in ColdFusion, but making it required is not a good idea. That's why Fusebox has an option to use java StringBuilder or the slower ColdFusion strings.
I appreciate the feedback Adam. It does bring up an interesting point and one I should digest a bit more before speaking more about it...
I say I should think more about it but my initial reaction is that quite frankly if a host is not allowing the use of Java then folks need to wise up and find a new host. I appreciate the the fact that some shared hosting do this for security but the fact is there are better ways to handle security for JEE applications.
Maybe forcing folks to find a better host is a bad move, maybe not. It certainly deserves more thought. At the end of the day the fact that some hosts won't allow something is not going to determine if I do it or not, it might influence how much support I provide to a pure CFML version though.
I would also ask "why"? Fusebox has a good reputation as a "fast" framework due to its parsed folder approach.
As I think you'll find with other CF/Java OS projects like CFEclipse, Open BlueDragon and Railo, the CF community is not well blessed with experienced Java developers willing/able to contribute to OS initiatives.
Also I would say that you risk marginalising Fusebox by your approach to shared hosting providers.
One other question, just so I can show my ignorance, would such a move be best handled using Java or could Groovy be a better use in this case?
Post a Comment