CFML: "It's alive!". Really now?

G'day:
Yesterday I was "helping" someone on the CFML Slack channel with some challenges they had with CFC serialisation. The conversation turned to ColdFusion's custom serialisers (see an earlier article: "ColdFusion 11: custom serialisers. More questions than answers"), and how pants I think the implementation & entire undertaking of that part of CF11 was. I'll just quote myself (full transcript of entire discussion here: Gist / adamcameron / slack.txt:

I did try to position the whole undertaking as "here be dragons"

On the face of it, it's a cool idea

But - as per most less-than-obvious things the Adobe CF Team tries to do - they completely cocked it up, having no real understanding of how ppl use CFML

[...]

What concerns me about Adobe's implementation is it seems to be very "not OO" which worries me when it's actually implemented by ppl who are supposedly Java devs.

[...]

I floated it "at the appropriate time" (nod to not speaking about the pre-release programme, but... well... f*** them), but the relevant parties just either didn't care or didn't get it or refused to get it.

It's the perpetual symptom that Adobe never consult the community before they blindly go and implement ill-conceived and poorly realised shite.

They ought to feel free to only consult with their major-client "IT stakeholders" for features like the API Manager and to a degree `<cfclient>` (hohoho), but when it comes to nuts 'n' bolts language implementation... they need to ask the ppl on the ground.

But based on that recent survey Adobe did... there won't be any more focus on the CFML language from them. They're only interested in buzzword-completion/box-ticking IT-Manager-pleasing platform features

In response to that someone observed they admired my sticking power with CFML (thanks for saying that), but my reaction was that Adobe finally "broke" me with CF2016 being such a waste of time for the CFML dev, as they did hardly anything in the language, instead of rolling something that's really nothing to do with ColdFusion: the API Manager into CF2016 and making it the marquee "feature".

At the same time Lucee 5 lost objective direction in that they indulged Micha's whim to re-write the thing to be OSGi capable (or whatever the correct term is), and mess around with the .lucee lang thing which ended up being both stillborn and evidence that LAS is out of their depth when they're not just copying what Adobe does. Harsh, sorry LAS, but that's my opinion.

I have given up on both the vendors when it comes to CFML, and personally I've moved from CFML to PHP now, but I'm still there in the CFML community helping people where I can. So - as far as the community goes - I'm suffering from "just when I thought I was out... they pull me back in", as it were. Apologies to Al Pacino there. But theatrics aside, that's my choice, so no worries.

Patrick came back with a reasonable riposte to my comments about being let down by the vendors:

Yeah, those sorts of public "divorces" (Railo-->Lucee) are never pretty, but it was really necessary. Kudos to the core of the Railo peeps who held it together. LAS is quite strong now, and I believe we're the future of CFML as a platform. I'm especially excited to see what the community can do with the extensible framework in place now. What say we all co-create a really vibrant ecosystem of products? With Adam as our cheerleader (I don't see it as cynical, mate!), I have no doubt we'll get it done.

Good on him, but I disagreed with one thing he said, and this lead to a bit of a diatribe from me:

You can't just say "What say we all co-create a really vibrant ecosystem of products?" and have it happen. The CFML community have demonstrated that they're - for the most part - takers rather than givers. Even with ppl asking for help from the community I see a sense of (misplaced) entitlement from them.

That said there's a minority of good worker bees, and a bunch of people who are good people but they're still just in CFML 9-5 (which is fine), but will not grow or strengthen the community.

Most of the stalwarts of the community are companies who have in the past invested a lot of effort into CFML (not the community necessarily, but for themselves), and it'd be a large $$$ cost for them to move. That's going to be why some of them continue to persist with CFML, and also encourage Lucee[:] as LAS is more likely to work with those small to mid-level companies to provide what they want out of CFML. Same as with Adobe and larger corporates.

The likes of Daemon and MSO.Net and Ortus and Pixl8 aren't going away when it comes to CFML due to how they've stacked their egg baskets, and I reckon they're more likely to stick with CFML than [it is that] LAS will [continue to] exist. Although one of them might consider "buying" Micha to perpetuate CFML for them if LAS founders. At which point Lucee will become kinda like OpenBD is for Alan Williamson's outfit

Sean was reading this and "emoting" with thumbs-ups in agreement and the like, then we got to chatting about OSS & CFML and that sort of thing. I'll spare you that.

But I stand by what I say above. I've been in the CFML community since 2001, and been active in the community all that time, and have been watching the ebb and flow of the CFML tide, be it ColdFusion or BlueDragon or Railo or Lucee. So I think my opinion is possibly an informed one. And I always offer it for the sake of informing, rather than posturing. People are quite welcome to disagree with me and to put a case forward as to why I'm mistaken. I like finding out I'm wrong, and I like debating (or arguing ;-) a topic with people. Provided they actually make a case.

Geoff Bowers (of afore-mentioned Daemon fame: he's the boss; and I think he's El Presidente of LAS) joined the conversation and suggested we should not be having such conversations, as they hurt the CFML community. And Geoff's position is that "The CFML Community" is a meaningful entity.

I disagree.

I disagree with a few points or inferences here:

• Any conversation by experienced members of a given community will possibly have merit, even if they suggest that the best course of action for the community members is to prepare themselves for the time when "the community" doesn't really mean anything any more.
• Even if the points being discussed have no merit, I disagree with the notion that the discussion should not be had because one member of the community doesn't like the sound of it, or it doesn't match their agenda.
• I don't actually think "The CFML Community" is a thing in and of itself which automatically deserves preservation. This might seem odd, but I'm interested in the welfare of the members of the community, not some completely intangible label "The CFML Community". That's meaningless. I will help the individual people in the CFML community whenever I can (or, realistically, when I feel like it, but that's quite often ;-), and I think helpful advice to people who rely on CFML for their crust these days is: plan an exit strategy. It's convenient for Geoff to deny this (I'll get to that), but CFML as a language has had its day. It had a unique selling point a decade ago: it made making dynamic websites quite easy compared to where Perl or PHP or JSPs were at the time. It does not have that USP any more. CFML does a bunch of things really well, but not that much better than any number of more popular (and easy!) languages do these days. The thing is the other languages bring their own participatory communities with them, and with those communities come rich OSS efforts which ensure whatever one wants to do that might be off-piste for a language: there'll be a third-party module for that.

But I digress: no, I don't think "The CFML Community" is worth protecting. The community members are, and my best (-quality and -intentioned) advice is to start planning an exit strategy. You'd have to be an arsehole to place the preservation of "The CFML Community" ahead of the welfare of its members.

CFML has precisely one remaining relevant purpose: to keep CFML devs in work if they can't do anything else. CFML is not going places. It's staying where it is. But the ice floe where it's positioned itself is melting away, growing smaller and smaller, and nothing's gonna reverse this.

Geoff disagrees. That's cool, but other than "I disagree" and a few half-hearted ad hominems ("none taken", btw), he didn't actually refute a single thing I said. I'd be dead f***in' keen to hear what he has to say though, to demonstrate how CFML is still alive in any meaningful way though. And how it's a good prospect for uptake, and how CFMLers shouldn't be planning an exit strategy.

My cynicism suggests to me that Geoff is mostly concerned about "The CFML Community" because it's commercially prudent for him to do so: he's built a company and a livelihood on CFML. So it's beneficial to him for there to be "The CFML Community" out there, as they're potential revenue opportunities. That's completely fine and I see where he's coming from. But it seems disingenuous to me for him to be suggesting myself or others don't have the community's best interests at heart when we offer advice that is not convenient for his business model.

Another issue I'll touch on in this increasingly rambling diatribe is Geoff's assertion that my observations have an actual deleterious impact on the community. This is seemingly based on the notion that any negative comment is intrinsically deleterious, and for "names" such as myself to me making these negative comments is more deleterious still. I guess cos ppl might be inclined to listen to my advice. Heaven f***in' forbid.

He's probably right. But let's get things in perspective here. Things that are deleterious to "The CFML Community":

1. ColdFusion being a paid-for product in 2016;
2. Adobe's lack of interest or lack of ability to keep the language contemporary;
3. every other bloody language being more contemporary and compelling;
4. and free.
5. The apathy of most CFML dev resulting in an under-represented community to engender momentum; 
6. Adobe's lack of ability to market ColdFusion;
7. Railo v Lucee schism;
8. Lucee 5 taking an inordinate amount of time to see light of day, for what seems like developer-self-indulgence;
9. LAS dithering about the place and seeming very incoherent when it comes to what they're doing;
10. [daylight]
11. [more frickin' daylight]
12. Me saying stuff Geoff doesn't like.

One could quibble about some of those items there, but it's the scale of things that is significant. Almost all of CFML users don't know who the f*** I am. A decent subset of those that do can think for themselves and will take what I say with a grain of salt, or already be (dis-)agreeing with me. And the others could do worse than consider what I have to say, and weigh it up for themselves.

But no CFMLer who cannot form their own opinions will have any idea who I am, and will never see any of my written opinions.

I hasten to add that the list above is "things that are deleterious to the CFML community". I see Lucee as a net force for good in the community. But if we're assessing what is unhelpful in the community, then they're a more significant player in all this than I am. And even Lucee's influence one way or the other is completely inconsequential compared to Adobe's.

But go on then, Geoff and others who think CFML is alive and well and is something that should be suggested for new adopters. Tell me why it is. Tell us... "The CFML Community"... why that's the case. Don't just call me an uppity dick or a big meany or whatever the f*** personal attack is easier for you to make. Do something.

Why is CFML still relevant?
Why should new people adopt it?
Why should people stick with it instead of perhaps protecting their future by examining other options?
Why should people not at least suggest that might be something to do?

Go on then...

--
Adam

Lucee 5: Platform modularity in CFML

G'day:
I had a long (and often protracted) conversation with Denny - who seems to do some work on the Lucee project, but I really don't quite get where he fits into things - and later in the piece Geoff, who we all know as Daemon's representative on the LAS "board", currently holding the role of President. The topic was "WTF is OSGi, what does it mean to Lucee, why the hell is causing such delays in Lucee 5's release and why do I - as a CFML developer - care?". It wasn't a formal topic, but it just happened to be what we were yapping about.

It was a very frustrating conversation at times because Denny - nice bloke that he is - doesn't seem to be able to empathise with other people: everything he says is always positioned from his own perspective, and he struggles to "get" that other people have different perspectives which are not the same as his. So the conversation always crept back to how it would benefit him, or someone identical to him. Irrelevant.

Geoff came along later in the piece and made a lot more sense.

Sean came in at the very end and had his own commentary to make, most of which was over night for my perspective so I've just caught up with it now.

The challenge here is it's easy to "get" what OSGi is all about... and as one researches I think even more questions about it - especially in the context of Lucee - arise, but... yeah... bottom line it compartmentalises packages so they can have different dependencies, which has been a bit of a blight in the Java world in the past. OSGi is one of the ways to work around that. I am taking a very high level position on this cos I ain't a Java dev, don't want to be one, and dependency management is all a bit yawn-inducing. It's an important consideration, sure, but not terribly interesting. But we all get it, yeah? Say Lucee's using one module that requires SomeDependency v1.0.0; for my code, I need to use SomeDependency v1.2.0 because it introduces a new feature I want to leverage. This is currently a bit of a challenge given the way the JVM loads its libraries: one can have version v1.0.0 of SomeDependency, or v1.2.0, but not both. And what if something in 1.2.0 happens to break something Lucee needs? Splat. There are ways around all this, but they're not streamlined. Oh... and the way OSGi manages modules means they can be (un)loaded on the fly. Yep... lovely... impacts almost no-one in the course of their day-to-day work.

Lucee 5 is being rewritten to follow / implement the OSGi specification, which will solve all this. Lovely. It's not - on the face of it - hugely exciting for most CFML developers. Most CFML developers don't use Java modules, and even ones like me who do occasionally... this version clash situation has simply never been much of a problem. Obviously it'll be more of a problem for people who do this stuff more often, but that is not most Lucee users. So I've always been asking "why do I care about this in the context of Lucee? Who's the target audience? How big is the target audience? Is it really worth all these bloody delays with Lucee 5 to accommodate a very niche audience?" Up until last night I never got a satisfactory explanation, and it really just seemed like something Micha decided to do because Micha felt like doing it. Or maybe an self-indulgence so that it can be claimed Lucee is OSGi compliant, even if it's mostly an unhelpful exercise to almost all users of Lucee. None of the messaging from LAS justified the effort to me. They don't need to justify themselves to me, sure, but I'm part of the community, and I'm sure I'm not the only person wondering.

And then Geoff explained it: modularisation of the platform.

You know how for years we've been asking Adobe to modularise ColdFusion? Obviously the same applies to Lucee, except in a smaller way. ColdFusion's got a huge footprint, most of which one doesn't need most of the time, so why should one need to install it? Lucee's footprint is much smaller, but the same still applies.

That's interesting-ish in itself, but it has a very compelling knock-on effect. If everything is a module, then enhancements and bugfixes become a lot easier to deal with. One can mess around within the scope of the module's codebase, and provided one doesn't do anything daft, it won't impact the outside world (it needs to maintain its touchpoints to the outside world, obviously: its API). This means the testing and footprint for work on a given module is much smaller. And it makes the job just... easier. And whre things are easier, things progress faster, and more smoothly.

It will also mean that organisations that like to stay up to date and can implement changes expediently can do so. And it means that organisations which need to move more slowly with such things can probably round out their checks and balances a lot faster. It's less bureaucratic overhead to say "we're updating Lucee's PDF module" than it is to say "we're updating our Lucee installation". This in turn means that there doesn't need to be as much hesitation on the part of LAS if they do want to make breaking changes to modules... organisations who aren't ready for the breaking changes don't need to implement them. This means there can be a more dynamic attitude to moving things forward, as the "no person left behind" idea isn't so entrenched in whatever work is done. This goes back to Adobe's glacial approach to doing anything: the whole system is implemented and released as one huge blob, and everything has backwards compatibility issues, and even the smallest backwards compat challenge in one distant corner of the ColdFusion system will prevent the rest of it moving forward at a pace appropriate to 2016.

Update:

Another good example where this sort of thing pays off is detailed in Mary Jo's comment below: she needed to run an up-to-date version of Solr cos CF's one is so woefully out of date, but it wasn't really doable on CF due to its monolithic approach to packaging, and dependency spaghetti. This sort of thing will be much easier with Lucee 5 (not that they'd be so slack at keeping their libs up to date anyhow, but you know what I mean).

This is bloody great news for Lucee. I'm quite sure why they're not messaging it this way. Here's what they say about the OSGI work on their website (this is the page promoting it):

OSGi

Lucee 5 is completely OSGi based, OSGi is the defacto standard in most Java enterprise environments, to manage bundles (jar libraries) used by the environment.

This means all libraries used are managed by Lucee itself as OSGi bundles, but this does not end with 3rd party libraries. Lucee handles it's own core as an OSGi bundle, Lucee archives (.lar files) and even our Java based extensions are all OSGi based.

So Lucee 5 is an OSGi engine that manages all libraries used.

What is the benefit?

OSGi is a framework used in most major enterprise environments, it is well tested and stable.

OSGi allows for the running of different versions of the same library at the same time. Lucee for example is not using internally the latest version of the HSQLDB data source, but this does not stop you from using whichever version of this data source you like. OSGi allows you to use whichever version of a library you like, independent of what version of the same library Lucee itself is using or any other applications in the same environment.

We can update every library Lucee is using at any time without issue and without the need to restart the JVM. This means that Lucee patches can include updated libraries, making Lucee a lot more flexible than it was in the past.

Can I benefit from OSGi somehow?

Yes you can, Lucee 5.0 also comes with some new build in functions to use OSGi features directly.

Today you use createObject('java',"my.class.Path") to create Java Objects, but with the power of OSGi under the hood we can do more!

Lucee 5 introduces the function javaProxy() to load Java objects, this functions interface is optimized to OSGi, so you can do something like this:

dtf=javaProxy("org.joda.time.format.DateTimeFormat", "org-joda-time", "2.1.0");

The function syntax is:

javaProxy(string className [, string bundleName, string bundleVersion]);

Only the class name is required all other arguments are optional. Lucee will also download the bundles from the update provider automatically if they are not available locally.

The Lucee update provider already provides a wide range of bundles in various versions and this will be added to continuously overtime.

You can therefore load a certain class in a specific version, even, for example, if the Lucee core is using the same class with a different version.

OSGi is the biggest change in the Lucee 5.0 release that brings Lucee to a completely new level. Whilst it maybe not a dazzling new feature, it is a necessary one for an engine to be used in the enterprise segment.

Zzzzzzzzz. Oh sorry, you got to the end of that did you? Well done. I mean one can perhaps infer the bigger picture there if one takes the time, but - even as a reasonable adept technical person - I read that, my eyes glaze over, and I'm going "so the f*** what?". Sorry, but I am.

But if one frames it in the context of real world CFML devs/admins, dispense with the buzzwords and start it with "we've listened to the community and Lucee 5's platform is now completely modular [etc]", then you would have kept my interest all along.

I think the issue is that these docs are written by people so far up the Jefferies Tubes of Lucee they have lost sight of the fact they're not the core audience of Lucee. This was where I was struggling with Denny last night, and where I struggle in general with a bunch of the messaging from Lucee. In short, I guess, the technical people shouldn't be writing it or presenting it.

Now Geoff didsay he pointed out all this at the keynote of Dev.Objective(), and - yeah - he's the sort of person to understand how to message these things, but a presentation at Dev.Objective() is no use to most people, because most people weren't there. And to message didn't seem to trickle back out anyhow, so I wonder if it hit home anyway?

I really think this is a potentially excellent feature of Lucee, but not in the way they are currently positioning it. The message should not be about OSGi, it should be about modularity of the Lucee platform, and what immediate benefit it brings to Lucee's CFML community. Not to the few engineers behind the scenes who care about the implementation (we shouldn't need to care about the implementation for one thing), but how it's going to impact my life, as a Lucee CFML developer. It's not that OSGi has anything to do with it. It's that it modularises the platform.

I think there's a better story for LAS to be telling here.

Also in closing: thanks Denny, Geoff and Sean for the interesting discussion last night.

Righto. Time for breakfast and - more importantly - coffee.

--
Adam

CFML/Lucee/Railo: Geoff Bowers does a good job of presenting Lucee's position on things

G'day:
Kai and Mark (with guest Geoff Bowers) have released a fascinating 2DDU today (depending on which timezone you're in). 'ere 'tis: "Episode 38 - Lucee, the fork and open-source licenses".

If you're interested in the whole Railo v Lucee thing ("Railo speaks at long last", "A message from the majority shareholder of The Railo Company", and all manner of other conversations about the place), or have concerns - I fall into the latter group - Geoff does a very good job of presenting Lucee's situation. It's certainly restored a lot of my confidence in the situation (from Lucee's perspective), which given how cynical I am, represents a pretty good effort on his part.

Nice one.

Anyway, go listen to it.

--
Adam