with the first execution

Adobe has some documentation https://helpx.adobe.com/uk/coldfusion/configuring-administering/deploying-coldfusion-applications.html

@aliaspooryorik So you are saying, when request for a specific cfm or cfc reaches to lucee servlet it just compiles only that and respond?

Lucee, BoxLang, and Adobe CF have their own peculiarities, but the servlet match is turned into a physical path to a template disk. There is a disk cache of class file and an in-memory cache as well. templates which have not been compiled yet, are JIT parsed and compiled into bytecode and loaded on the fly via a custom URL class loader, where they are then invoked. The plumbing of the servlet is abstracted via scopes, BIFs, and tags. Or, in the case of BoxLang, the servlet is completely optional and only present in specific web runtimes.

The servlet wrapper is quite simple, at least in BoxLang. I wrote it in an afternoon as it was just a matter of stubbing out the web.xml template that maps .cfm and .cfc files to the CF servlet https://github.com/ortus-boxlang/boxlang-servlet/blob/development/src/main/resources/boxlang-servlet/web.xml And then the servlet class (which is class loaded and invoked by the servlet container) simply maps the incoming URI to the physical template and sets up the request. https://github.com/ortus-boxlang/boxlang-servlet/blob/development/src/main/java/ortus/boxlang/servlet/BoxLangServlet.java#L109-L124 The logic in the

init()

runs once when the servlet context is created, and the

service()

method is run for every incoming request

Once the path to the template is resolved and we can calculate what the Java class name will/would be for the compiled template, then it's pretty easy to check the memory and disk caches for class files (which are loaded via the CL's

defineClass()

method. Lucee, BoxLang, and ACF vary quite a bit in their approach to generating bytecode, but generally speaking, a single CFM file translates to a single Java class where the logic in the template is represented in the bytecode of a method which is invoked via a shared interface or superclass. Lucee will compile UDFs (be it from CFMs or CFCs) into a single class. ACF and BoxLang will use inner classes for each UDF instance, but that's generally an implementation detail hidden from the developer.

All 3 CF engines use a "context" object that represents/wraps the underlying HTTP request details and contains the scopes of variables for that request (URL, form, CGI, etc) as well as references to the session and/or application contexts. BoxLang uses a series of contexts in a parent/child relationship to contain the scopes, making the language core small but modular and extensible whereas Lucee/Adobe mostly know all possible scopes ahead of time. Internally, this context is passed pretty much everywhere (and usually registered in the thread local) so the runtime always has access to the variables on the page.

Instead of compiling straight to the same Java constructs of the same name, all 3 CF engines provide their own implementation of • variable definition (via scopes) • classes and type checking • operators (string, math, binary, logical, etc) • flow control constructs (if, do, dowhile, for loop, index loop, switch, etc) So CFML code such as

// CFML code
if( foo && name == "brad" ) {}

will compile down to the bytecode equiv of a Java if statement, but the actual operators will be replaced with classes that implement the "and" and "equals" operator. e.g.

// Java code equivalent represented in bytecode
if( AndOperator.invoke( BooleanCaster.cast( foo ), EqualsOperator.invoke( context.getVariable( "name" ), "brad" ) ) ) {}

☝️ Pseudo code-- the CF engines differ a deal here, but accomplish the same thing at the end of the day. This allows them to enforce what can be cast to a Boolean, implicit type coercion, variable access, and logical operator behavior.

@eniac00 Let me know if you have further questions