Regarless of what my CFML code is (struct.myKey, struct["myKey"], or struct.get("key")), it seems the bytecode should be equivalent. That's what compilers are for, no? However, I wasn't talking about a CFML reference, I was talking about using a Railo struct within a "pure" Java context. Within Groovy, Maps have special syntax-level support which doesn't quite work with Railo structs, because they're not Maps. They were Map-like enough to support the syntax constructs, but because they throw an error on a missing key instead of null, it basically make it moot (no "elvis" operator, have to add a bunch of try..catch, etc.). Both oBD and CFMX use Maps to implement CF structs, so it's not a CFMX-specific feature, it seems to be a Railo-specific non-feature.

RE the include, this line was the offender:

pageContext.getServletContext().getRequestDispatcher(path).include(pageContext.request, pageContext.response)

The 'pageContext' variable is the result of calling getPageContext() within CFML, though that line was actually executed from within Groovy/Java, not Railo. The 'path' variable was set to "/cfgroovy/sample_include.cfm". It ended up with infinite recursion, trying to include "index.cfm" over and over again, rather than "sample_include.cfm". I didn't dig in too deeply, I just saw repeated includes of "index.cfm" until I killed the JVM, and so added a conditional so it didn't run on Railo in the demo.

you are absolutly right, a railo struct does not extends java.util.Map.
that's because railo's struct is optimized for the railo enviroment, it neeeds no interpetation, like a map in cfmx needs.
why you access a struct via reflection (struct.get(key)) instead of native cf access (struct[key]), every refection access is 1000 times slower than a native access! reflection access on coldfusion object is always the worst decision.

on java level railo can't be 100% similar to cfmx, only cfmx can this.

what is exactly the problems with include?

greetings michael

I'm not sure. As it stands right now, it's a viable way to embed groovy right inside your apps. As for turning it into an whole-app framework, I'm not sure about that. The real goal was to deal with some classloader issues so that I can use Groovy direct from the URL (via GroovyServlet), and built entire applications in Groovy with no CF dependencies. CF could still be used for the views, of course, but that's a secondary decision.

For the direct embedding, it has some potential for storing groovy scripts in the DB and executing them dynamically for business rule configuration. I.e. you can change certain business rules without having to change the CF code, you just update the Groovy script in the DB. That sort of arrangement is difficult with CF (less so on BD), and the CF syntax is less friendly. I'll probably end up using it for that in a couple apps.