jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Enable new features by default or via configuration?

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Tue, 16 Jun 2015 00:11:32 +0200

Hi,

In thread 1078-DataModelRegistrable the issue came up about configuration
to enable new features/behavior in JSF 2.3.

Perhaps it's a good idea to discuss this separately in a new thread.

The issue at hand is that from JSF 2.3 m03 on there's an explicit context
parameter needed to activate a major new behavior; letting CDI resolve
named beans, aka the EL implicit objects (see eg
http://javaevangelist.blogspot.nl/2013/04/jsf-2x-tip-of-day-jsf-expression.html).
E.g. things like "application", "facesContext", etc. Due to the way CDI
works all these things are simultaneously available for injection by the
same mechanism.

Now there are basically two options:

1. By default JSF 2.3 does things in the latest and best way. If the old
behavior is required this can be configured.

2. By default JSF 2.3 does things in the old and not best way. If the new
behavior is desired this can be configured.

Each option has pros and cons.

With option 1, someone who starts with JSF and that version happens to be
version 2.3 likely does not care about (for this person) obscure behavior
from an old JSF version. So for this use case in particular it's best that
the latest way is the default way.

With option 2, someone who already uses JSF 2.2 or older has a higher
chance to run an older JSF 2.2 application unchanged on JSF 2.3. So for
this use case it's best that the old way is the default way.

There's historical precedent for option 1. E.g.

* JSF 1.1/1.2 com.sun.faces.enableRestoreView11Compatibility (default was
the new behavior; throwing ViewExpiredException, old behavior could be
configured)
* JSF 1.2/2.0 javax.faces.PARTIAL_STATE_SAVING (default was the new
behavior; saving state partially; old behavior (full state saving) could be
configured).

A particular disadvantage of option 2 would be that if you kept doing this,
then 5 versions later you may potentially have to start a brand new JSF
application by a mandatory configuration of 5 options for all the things
that were introduced since JSF 2.2, which is somehow a "blessed" base
version that's always the default no matter what the actual JSF version is
(2.3, 2.4, 3.0, 4.1, etc).

In a way there's a third option as well; have the old behavior be the
default for one version, then make the new behavior the default in a later
version.

Thoughts?

Kind regards,
Arjan Tijms