Lucee Manifesto

Lucee Association Switzerland (LAS) is a collective of Member companies that act as the custodian for Lucee Server and it’s related code bases. While LAS Members don’t always agree on all things, the manifesto is an effort to declare our overall intentions for the code base, and help guide in community and technical decisions.

The manifesto will no doubt evolve overtime as it weathers community opinion and more importantly the scrutiny of those people most motivated to effect change.

Lucee Server

lucee server is easy to contribute to

Lucee server must be easy to build. Every effort should be made to make Lucee accessible to developers who want to contribute to the project.

lucee server is everywhere

Lucee server must support as many modern installation methods as possible. For example, Lucee should deploy applications as WAR files, Heroku-like build packs, Docker images, via the CommandBox CLI and more.

lucee server leverages the JVM

Lucee exposes the most advanced features of the underlying JVM with performance, class loading, OSGi and JSR-223 support at its core.

lucee server is servlet engine neutral

Lucee is not tied to any specific servlet engine. Nothing should be implemented in the core that prohibits the use of a standards based servlet container.

Note, LAS has standardised on Apache Tomcat for distribution as we can’t suppport installers for all engines.

CFML Compatibility

CFML is a light-weight dynamic scripting and tag language for the JVM that enables the rapid development of simple to highly sophisticated web applications.

Lucee supports Adobe CFML

Lucee server supports ColdFusion Markup Language (CFML) as defined by the Adobe ColdFusion platform. The most popular CFML frameworks and open source solutions are fully supported by Lucee including FW/1, ColdBox (and family), Mura, Preside, FarCry Core and others.

Lucee will actively improve CFML support

Continuing to support CFML and making improvements in CFML compatibility will remain the highest priority for the CFML dialect of Lucee server.

“Supporting CFML” means providing compatibility to Adobe ColdFusion (ACF) and the Lucee Association Switzerland (LAS) are committed to the following:

  • if you find a compatibility issue between Lucee’s CFML implementation and ACF please raise a bug report and it will be reviewed and responded to
  • if Adobe develop something new that is seen as a popular enhancement then Lucee will add it to the roadmap; features with the most interest are added as a matter of priority
  • CFML applications will continue to run on Lucee

Lucee will not create incompatible CFML

Lucee, like Railo before it, has been trying to propel the CFML language forward. However, the more we advance the language the more we muddy the water of what CFML is. In addition to the compatibility layer for CFML applications, Lucee server has its own Lucee Language alternative.

Lucee Language is a modern alternative to CFML, embodying the same approach, familiar syntax and an even richer set of language features.

Lucee Language

Lucee Language is a light-weight dynamic scripting and tag language for the JVM that enables the rapid development of simple to highly sophisticated web applications.

Lucee Language has its roots in the ColdFusion Markup Language (CFML) but Lucee Language is not CFML.

The Lucee language is a modern alternative that is both familiar to existing CF developers while providing the freedom to grow in a more ambitious direction.

lucee language is open source

Lucee Language and its underpinning server technology are open source. While its happy to play nice with commercial products, Lucee itself will never be commercialised.

lucee language is the focus of future language development

Engineering efforts will focus on taking lucee language forward. Continuous improvement of CFML compatibility will remain a high priority, but future additions to CFML that are not officially supported by Adobe should be avoided.

lucee language is faster

Any evolution of the language must be weighed up against its impact on performance. Performance is critical, but not at the expense of good abstraction.

lucee language will support both scripting and tags

Both script and tag based development should be considered first class citizens.

lucee language will interoperate seamlessly with CFML

Lucee language should be able to include CFML code templates and vice versa. Where possible lucee language should facilitate the transition of developers from CFML to Lucee Language.

The Manifesto is something I started working on back in June, after the “fundamental philosophical decision” thread. It turns out a manifesto is a hard thing to write and even harder to get consensus on :wink:

The Manifesto doesn’t have the depth of something like the Python PEP guides, but you have to start somewhere. Mostly it is a series of fundamental statements, with general consensus amongst existing Members, about how LAS views Lucee Server.

With luck the Lucee Manifesto will generate some discussion around the fundamental nature of the future of the Lucee server. I’ll make every effort to curate this topic to keep it on track; branching any major discussions and updating the Manifesto like a WIKI entry.

Interesting read.

Will this find its way onto the web site?

Also… is the lower-casing of “lucee” a purposeful thing (ie: is that how LAS has decided to write it), or is that just a bunch of typos?

I think it’s really good to have a positioning document like this, btw.

2 posts were split to a new topic: Lucee language is faster

FYI, I’ve proposed that the TAG make their own review of the manifesto in relation to Sean’s post on what kind of language we want Lucee Lang to be. Hoping to discuss it in upcoming TAG meeting.

I note this is linked to on Lucee’s Github repo. Does this still accurately reflect the current “mission statement” (for lack of a better term?) Particularly that related to “Lucee Language alternative” etc.

The Lucee Language concept is a way of breaking free of the shackles of de-facto Adobe CFML governance. It remains an ambition but we’re not yet in a position to take it out of a conceptual phase. Certainly Lucee Language is not on our near-term roadmap.

CFML Compatibility is in conflict with our ongoing improvements to areas of the Lucee ecosystem that we had hoped to constrain to the Lucee Language. In the main, these are enhancements that are specific to Lucee but do not have a corresponding feature in ACF, so it becomes easier to program Lucee specific CFML that will not run in ACF. However, we’re still very focused on the portability of Adobe CFML to Lucee server for obvious reasons.

Given our resourcing constraints our current focus is on:

  • lucee server is easy to contribute to
  • lucee server is everywhere
  • lucee server leverages the JVM

While we’ve made incredible improvements in the last 2 years in product management and the regularity and robustness of our releases, we still have a long way to go.


PS. Any financial support is much appreciated and has an immediate impact on our resourcing.

1 Like