Posts

Showing posts from September 14, 2014

Jakarta EE Survey 2020

At OmniFaces we poll the community from time to time about Java EE (now Jakarta EE) and related technologies. With the transfer of Java EE to Jakarta EE now almost completed, people are now starting to think about Jakarta EE 10 , the first Jakarta EE release after Java EE 8 having new featues. As such it's a good time to poll the community again. In the 2020 edition, there are 4 categories of questions again: Current usage of Java EE / Jakarta EE Servlet containers APIs related to Java EE / Jakarta EE The future of Jakarta EE Compared to 2018, we simplified some of the questions somewhat, omitting some of the less popular options to make it more manageable. We added questions about the future of Jakarta EE and MP together, the preferred Jakarta EE cadence, and generally updated the choices (such as adding Quarkus , which wasn't quite on the radar in 2018 and our own Piranha Cloud ). Jakarta EE provides the opportunity to revitalise and modernise Java EE, but i

Getting the target of value expressions

In the Java EE platform programmers have a way to reference values in beans via textual expressions. These textual expressions are then compiled by the implementation (via the Expression Language, AKA EL spec ) to instances of ValueExpression . E.g. the following EL expression can be used to refer to the named bean "foo" and its property "bar": #{foo.bar} Expressions can be chains of arbitrary length, and can include method calls as well. E.g.: #{foo.bar(1).kaz.zak(test)} An important aspect of these expressions is that they are highly contextual, specifically where it concerns the top level variables. These consists of the object that starts the chain ("foo" here) and any EL variables used as method arguments ("test" here). Because of this, it's not a totally unknown requirement for wanting to resolve the expression when it's still in context in order to obtain the so-called final base and the final property/method , the las