Link Details

Interesting... There seems to be roughly two camps of people: the first who want to have compile time security and the other who wants to have anything dynamically happening at run-time.

Java actually supports both camps. EL is as dynamic as can be and with reflection the sky is the limit, but if you don't use either EL or reflection, Java is a pretty strong typed and statically checked language.

It depends on what the programmer wants, although in a team or when using other one's code, you can never actually rely on Java being pure statically checked.

Henk,

>> "EL is as dynamic as can be and with reflection the sky is the limit, but if you don't use either EL or reflection"

EL and reflection have nothing to do with the dynamic nature of a language.

The problem with both EL and reflection is that they both still operate on the static representation of a class at runtime. There are tools that can generate classes at runtime, and make it accessible via reflection, but that's still not dynamic.

A perfect example in practice is a SOAP client. In Java (and any statically compiled language) there are only really two options for binding to the wsdl. Generate code (a LOT of code), or access it using a Map like interface mapped to a DOM (which I've never even seen, but would perhaps like to). The latter is more dynamic, but it's not a language feature, it's simply making use of a data structure. The problem isn't what happens at runtime, it's what happens at code time. You simply have nothing to compile against if you don't have a stub or interface generated (unless you just use the Map).

With a dynamic language, like Ruby or Groovy, you could bind the wsdl and its types (request, response, params etc) to an actual rich type -- without code generation or having to resort to a map. So the Employee parameter of some wsdl for example could actually map to an Employee type that has a .first_name and a .last_name... without generating any code whatsoever (at code or build time).

These fully dynamic classes and their properties are also accessible via reflection and/or EL like syntax within strings or frameworks (e.g. "Hello #{employee.firs_name}").

The key is the ability to code against types that may not yet exist at "compile" time. This makes SOAP clients (for example) reasonable to work with, whereas a static language will always require code generation or a type-mangled data structure to represent the interface.

See GroovyWS vs. any JAX-WS or similar framework.

Cheers,
Clinton

>The problem with both EL and reflection is that they both still operate on the static representation of a class at runtime.

Well, EL is dynamic in the sense that it's completely run-time interpreted. I can write something like #{currentUser.invoice.order.articleNumber} without any compiler ever looking at it, or trying to resolve any of the 4 types involved in that expression. At run-time, it completely doesn't matter what the actual type of currentUser is. It may a bean, it even may appear to be a map, or it may be something else entirely.

For a Java programmer this is both a blessing and a curse. It's a blessing since it can work at run time with any thing that can logically support the given -names- in the expression. Types are completely irrelevant. At the same it's a curse since Java programmers tend to depend on the type safety offered by their compiler. An expression like the one given above is undeniably powerful, but it may actually blow up during run-time.

That's why in Java one tends to see EL mainly used in the web layer, even though it's technically possible to use EL in any context, so also in business code. Web guys are sort of used to a dynamic / little guarantees environment, while the business guys more prefer the predictability and guarantees of traditional Java code.

Also I'm not sure whether your comment about operating on the statically structure is entirely correct. I can on-the-fly compile a class and hand this over to my code that knows nothing about it's type other than that it inherits from Object. Using reflection or EL I can access its fields and call its methods.

Sure, Java -is not- a dynamic language itself, but via EL, reflection and the compiler API one can do a lot of dynamic stuff. (I won't comment on the fact whether this is good or bad, just that it's possible and actually in wide use)

"The problem with both EL and reflection is that they both still operate on the static representation of a class at runtime. There are tools that can generate classes at runtime, and make it accessible via reflection, but that's still not dynamic."

Er, that's the very definition of dynamic.

You're correct about Groovy. It's much nicer to use a dynamic language for things like web services. Groovy, Ruby, Python, JavaScript all run under the JVM so you can have your cake and eat it too. ;)

Is amazing how far Java is going... This JavaOne was special for many reasons