Hi everyone,

First of all a test to see if the new mailing lists work, and just an open question of what things if any all of you think should be interesting for a next spec release of JSF?

Kind regards,

Arjan Tijms

Hi Arjan,

I just had a look at the migrated issues: https://github.com/javaee/javaserverfaces-spec/issues

In my view we should flag the ones for the next version. Unfortunately it seems not possible to sort by priority as it's only a label or am I missing something?

Regards

Dennis

We could indeed start to flag potential candidates for the next version already. The idea of this thread was to gauge interest a little, see what people already know what they'd like to see.

Continuing the CDI migration/alignment would be a big one for me. There's much more to be done there still.

GitHub issues indeed does not have priority sorting, other than sorting on thumbs up. Compared to JIRA GitHub issue is as bare bones an issue tracker can be.

Pruning the native managed bean facility would take 2 major releases, and in Mojarra if I understood correctly it would never be truly removed. It's the RI, so after being pruned it's made optional, which means the RI still has to provide an example (reference) implementation for it.

MyFaces would be allowed to drop it totally then.

But yes, I like your idea of trying to extract the MBF into a separate jar. I think we can even do that already outside the spec cycle as an implementation detail.

Btw, what about the JSP view facility? Is it already deprecated? That could be another candidate to be moved to another module IMO.

It's certainly effectively deprecated. Many newer features are not supported when JSP is used, which is in a way a strategy to slowly phase it out.

But indeed, I love to move that one to a separate module/jar file too so that people can totally exclude it. Some things in JSF (Mojarra at least) are a bit more difficult to exclude as it's interwoven into the code at various places.

Some of the native EL resolvers would be another candidate to move to a legacy module. The pre-UEL support that's still there in JSF would be more difficult to completely remove, as it shows up as (interface) methods in a wide variety of types. Removing that would be a breaking change, which under Java EE rules is not that easy.

Regardinf pre-UEL, are there already alternative methods on thosw interfaces to use UEL?

There often are indeed, see for example this one:

https://docs.oracle.com/javaee/7/api/javax/faces/component/ActionSource.html#getAction--

getAction returns a MethodBinding, which is the deprecated pre-UEL type that everyone desperately wants to get rid off.

It has been replaced by:

https://docs.oracle.com/javaee/7/api/javax/faces/component/ActionSource2.html#getActionExpression--

Which in this case is in another interface. There are also cases (in abstract classes mostly) where the deprecated and replacement are in the same class.

Do you have a whole list of "legacy/deprecated" JSF features?

There's an initial list in the JSF spec document itself. At least those things would be a prime candidate to be actually removed, but as said that's not always easy because of Java EE's backward compatibility rules.

In some cases the deprecated methods just sit there and nothing would normally call them. In other cases, unfortunately, they are still called and chained to their replacements, again for backwards compatibility. Those show up in the stack traces and are really not so nice to have around. One example is the ResourceResolver and the ResourceHandler. The resolver is deprecated, but it's still called. See http://arjan-tijms.omnifaces.org/p/jsf-22.html#809

Kind regards,

Arjan Tijms