More info on Lucee 5

G'day:
The Lucee Association seems to have jumped on its comms recently, with Andrew working on the Lucee blog, and Micha has also now created a page on the wiki page detailing some stuff on what's coming in Lucee 5.

A lot of this stuff is what was being thrown around for Railo 5, which should come as no surprise. But this does mean that back in the Railo days Gert has taken us through it all. Still: it's worth repeating because unlike Railo 5... Lucee 5 will be with us (at least in alpha/beta) in a coupla weeks. And I expect it to be released at dev.objective().



Here are my thoughts on what's been posted on that wiki page.

Language features:

• Abstract & final modifiers for components and methods (see "Abstract/Final components/functions"). These are common in other languages, and CFML is kinda playing catch-up here. It's the sort of thing one might have expected to be added to the language in CFMX 6.0. Still: better to have than not have.  It looks like final has only been added to components, not methods or properties, which is a bit odd if that's the case? Perhaps it's a shortfall in the docs, not the implementation?
• Static methods and variables (see "Static support for components"). Whilst a bit cool about having abstract and final, I'm quite pleased CFML will finally have static methods. This is an oversight in the language which has always struck me as odd & annoying. I think the need for static variables is limited, and I can't say I like their mooted syntax:
  
  

  static {
      susi=1; // written to the static scope
      static.sorglos=2; // again written to the static scope
  }
  

  
  That seems clumsy. I'd much rather just have a static modifier on a variable declaration:
  
  

  static susi=1;
  

  
  I also think that it's a mishit to have a static scope. Because one should be able to have both public (this-scope) and private (variables-scope) variables. Still: the static method implementation seems to be solid, so that's good.
• Lambda expressions. This is just an alternative syntax for long-hand function expressions, eg:
  
  

  bolder = function(s){
      return "<strong>#s#</strong>";
  }
  

  
  Would be expressed as:
  
  

  bolder = (s) -> {
      return "<strong>#s#</strong>";
  }
  

  
  Shrug. IMO this brings nothing to the language, and I don't know why they decided to do it.
• times loops. This is a waste of time too:
  
  

  <cfloop times="5"> 
      Hi There
  </cfloop>
  

  
  Why'd they bother? Where did the need for this arise from? It looks like work for the sake of doing work to me.
• "New and modified functions / tags". There's not much listed here. Hopefully a documentation omission rather than a paucity of new stuff:
  • javaProxy() - a replacement for createObject("java") apparently. The description makes it sound like underlying implementation detail has bled out into the language. The syntax is going to be like this:
    
    

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

    
    Those three arguments are:
    • class
    • version
    • package
    That seems rather an odd argument order. Aren't we used to going package.Class (eg: java.lang.String)? I also don't know that specifying the version number within source code is a good idea. Why? Not sure, but it just seems "wrong" somehow. It could just be me.
    
    What I'd like to be able to do is simply go new java.lang.String("") (silly example I know). Hopefully there's good reason for adding a new function here. Also the function should be called createJavaProxy(). As it stands, it sounds like an actual class, not a method.
  • webserviceProxy(): as above, except for web services.
  I do think they should have more info up about this sort of thing by now. The beta is due out in a week or two!
• The last entry on this list is "cachedwithin", but the link just 404s. I dunno what this is all about.

I'll pause here. Those are the new language features. As you can probably tell I'm underwhelmed. There's only one thing there I think is actually good (static stuff), but even that is let down by its implementation. Had you asked me a year or so ago, I'd probably also have thought abstract and final are good, but, really... now I think they're mostly unnecessary. They'd've made sense if they went into the language from the outset, but I don't see the point of adding them in a decade later (ie: after CFCs were introduced).

All is not bad though. Those were the language enhancements, but there's also some good architectural enhancements too. And some of these actually do seem good.

• OSGi: the underlying engine has been reimplemented to use OSGi. This will make everyone's life easier as it'll make packaging and deploying apps more "natural". Even if yer not in the business of packaging and deploying stuff, you probably use third-party packages that you need to install. This'll help that.
• JSR 223 (the link to this on their wiki is 404ing at the moment). JSR 223 is a standard for implementing scripting languages on the JVM. I don't see that this really brings much to the plate as far as CFML goes, but it could mean one is more easily able to run other languages atop of the Lucee engine, and perhaps it gives some integration options, eg: embedding server-side JS (or Groovy, JRuby, etc) into one's CFML files. Not that I see that sort of mishmash as a good thing, but if it means I can create my views with CFML and do my middle-tier processing with Groovy or Clojure (etc) instead of CFML, then that opens some possibilities for Lucee as a JVM platform. I think this is "interesting" if not "excellent". But I also think once we see it in action, it might end up being pretty bloody good.

All in all... hmmm. I will freely admit the architectural stuff isn't ever as interesting to me as language features are, and language features seem a bit thin on the ground here. Especially for something that is apparently a full very release (ie: 4 to 5).

I'm hoping this is a case of subpar documentation (this has always been a problem for Railo and Lucee; and it's also in the process of being remedied), and things like "times loops" aren't actually intended to be marquee features here.

Currently this seems less interesting that ColdFusion 11 did (that is not some loosely veiled joke about <cfclient>: there was a lot of other good stuff in there). I do have a growing concern that the decision-makers at Lucee are out of their depth as far as language design goes. There was a rumour that they were going to be forming a language committee or something like that... I dunno whether that's happened or is still going to happen, but I think the language decisions need to be made... um... differently than they are now.

As soon as I get my hands on a release, I'll have an open-minded look at it, and write up the interesting stuff.

--
Adam