Asked  7 Months ago    Answers:  5   Viewed   27 times

I would like to know the detailed difference between the Expression Languages (EL). There is JSP EL, JSF EL and Unified EL.

I would like to know the history behind the EL and what the latest EL is that is used in Java EE applications. Is it the EL common for all view technologies in the latest versions?


  • Jun 2002: JSTL 1.0 was introduced with EL for first time. It were those ${} things which works in JSTL tags only. It is designed to call Javabean get methods.

  • Nov 2003: JSP 2.0 was introduced and EL was moved from JSTL 1.0 to JSP 2.0 in javax.servlet.jsp.el package and it became standard EL as part of J2EE 1.4 standard. JSTL 1.1 was shipped without EL. Now ${} works outside JSTL tags in JSP template text as well.

  • Mar 2004: JSF 1.0 was introduced with deferred EL in javax.faces.el package. It were those #{} things which works inside JSF tags only. The difference with standard JSP EL ${} is that it doesn't only do get, but can also do set. This was mandatory for managed bean auto-creation and setting the values of input components. The standard EL ${} works in JSF output tags as well, but they won't auto-create beans if they don't exist in scope yet and they won't set input values.

  • May 2005: While still preparing for new JSP 2.1 which should be released May 2006, deferred EL #{} was extracted from JSF and combined with standard EL ${} in the javax.el package. At that point, it became unified EL which was introduced with JSF 1.2 and became later part of JSP 2.1 and Java EE 5 standard. The #{} can now also be used in JSP tags to get values, but not to set values. The ${} can now in JSP also auto-create managed beans, but not set values.

  • Nov 2006: Facelets was introduced as successor of JSP. It allowed for use of #{} in template text outside JSF tags, as substitute for <h:outputText> without any attributes. It also treats ${} as #{}, so they both behave the same in Facelets.

  • Dec 2009: EL was extracted from JSP specification and became a standalone specification which will be maintained independently from JSP, the first version being EL 2.2 (JSR-245), analogous with JSP 2.2. Main new feature is calling parameterized methods instead of only calling Javabean getters/setters inside #{} syntax, e.g. #{bean.method(argument)}. Furthermore, Facelets became part of Java EE 6 standard.

  • Jun 2013: EL 3.0 was introduced which comes with a standalone EL processor, allowing usage in a plain Java SE application. Other main new features are the new string concatenation operator +=, new operations for collection objects, including streams and Lambda expressions -> (even on Java 6/7!) and importing constants into EL scope.

Tuesday, June 1, 2021
answered 7 Months ago

Ok, here is the final way: - Register the standard enum converter in faces-config.xml (optional):


Add a function for example to a managed bean which converts the Enum values to an array of SelectItems:

public class GenderBean {
  public SelectItem[] getGenderValues() {
    SelectItem[] items = new SelectItem[Gender.values().length];
    int i = 0;
    for(Gender g: Gender.values()) {
      items[i++] = new SelectItem(g, g.getLabel());
    return items;

Then bind this function to the selectOneMenu in JSF:

<h:selectOneMenu id="gender" value="#{person.gender}">
  <!-- use property name not method name -->
  <f:selectItems value="#{genderBean.genderValues}" />

That's it! Not the first explanation for this problem on the net. But i think it's the easiest & shortest one ;)

Sunday, August 1, 2021
answered 4 Months ago

Starting from androidx source files, I've migrated custom classes based on old DialogPreference to new androidx.preference.DialogPreference with the following procedure:

Step 1

The old custom dialog class (e.g. CustomDialogPreference) based on legacy DialogPreference should be split into two separate classes:

  1. One class (e.g. CustomPreference) should extend androidx.preference.DialogPreference and will contain only the code related to preference handling (data management).
  2. Another class (e.g. CustomDialog) should extend androidx.preference.PreferenceDialogFragmentCompat and will contain only the code related to dialog handling (user interface), including onDialogClosed. This class should expose a static method newInstance to return an instance of this class.

Step 2

In the main fragment handling preferences based on PreferenceFragmentCompat the onDisplayPreferenceDialog method should be overridden to show the custom dialog, e.g.:

    private static final String DIALOG_FRAGMENT_TAG = "CustomPreference";

    public void onDisplayPreferenceDialog(Preference preference) {
        if (getParentFragmentManager().findFragmentByTag(DIALOG_FRAGMENT_TAG) != null) {

        if (preference instanceof CustomPreference) {
            final DialogFragment f = CustomDialog.newInstance(preference.getKey());
            f.setTargetFragment(this, 0);
        } else {
Monday, August 2, 2021
answered 4 Months ago

They have exactly the same meaning. The dot style is often easier to read. You need the bracket style if the index is going to be given by an expression (e.g. mc[name] instead of mc["name"]).

Thursday, August 5, 2021
answered 4 Months ago

Thanks to the suggestion by @Al-Mothafar, I have finally solved my issue in the following way:


    <script type="text/javascript" src="resources/Javascript/jquery/jquery-1.7.2.js" />
    <script type="text/javascript" src="resources/Javascript/MyJS.js" />
    <script type="text/javascript" >
        var myBeanProperty = '#{myBean.myProperty}';


$(document).ready(function() {
Friday, August 20, 2021
answered 4 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :