Will we ever get an API for ColdFusion’s Java Code?

This was one question I was hitting myself for not asking after the recent MXDU in Sydney.

Point: ColdFusion sits on top of a J2EE engine

Point: This is very neat, because it means we have the power of Java at our hands to do low level work we would not otherwise be able to do in CF.

Point: Any time you want to do Java code that integrates with already existing ColdFusion code, there is a whole lot of guesswork and introspection into undocumented features of CF so that we can leverage it’s power in ways that we need. (i.e like my post on attempting to add a HttpSessionBindingListener to a CF Session).

Question: Why doesn’t CF ship with Javadoc API documentation of the Java classes it is built on? It would make all of our lives a helleva lot easier.

It’s not like I’m asking for CF to become open source (which I don’t even want), but simply make available the information we can already get through Java Reflection in an easy to use format.

I recently unzipped the cfusion.war archive from the J2EE deployment and made it so I could compile a copy in my Jave IDE (which was a tad trickier than it seemed).  I did this so I could compile some servlets against the already existing codebase, and make sure there were no conflicts.  Admitedly I also did it so that I could grasp a much finer notion of the underpinnings of what ColdFusion really is, and get to put my hands in as many of its internals as I could.  For those of you who do Java/J2EE work as well, I would say try this out, it gives you a whole slew of new ideas in terms of extending ColdFusion.

There is a small part of me (and for the record, I am in no way advocating this) that is tempted to take a decompiler to the codebase of CF, just to see what makes it tick.  Just to be clear on this point – I am quite aware this would be quite illegal, and I have not done so.  That being said, the only reason I would do so, is simply so that I can understand CF at a much lower level, and simply become a better ColdFusion Programmer.  The purpose of this discussion is not for whether or not decompilation is ethically/legally good or bad.

So to end on a positive note – while this does sound like a gripe at heart, really I’m just asking for something that in some ways already exists, and I think would be a very large resource for all the developers who work with ColdFusion today.  It would mean we would all stop grasping at things we think are there in the code base, and can concentrate on really building on what we know is there.

So in case any MM guys happen to read this – Can we have it?

Leave a Comment

Comments

  • dave ross | June 22, 2004

    There are a few things that definently should be doucmented, like session tracking, datasource service, and mappings. I think MM feels like these implementations will change so it would be foolish to make them public.

    I’m not sure documenting the entire application would be worthwhile for them or us.

  • Mark | June 23, 2004

    I have read that alot of this stuff will be documented in Blackstone.

    Definatley a step in the right direction.

    As per ‘if it would change’ – that’s fair enough. However people are already building on undocumented ‘features’, and if they were given the documentation, I’m sure it would have large red warnings stating that the implementation is liable to change between versions.

    People are always going to dig deeper than you expect – but said people also know they are taking a risk by doing so.

    I’d love the documentation.

    But maybe that’s just me.