On Mar 2, 2015, at 5:21 AM, Konstantin Kolinko <knst.koli...@gmail.com> wrote: > > 2015-03-01 1:04 GMT+03:00 Jeremy Boynes <jboy...@apache.org>: ... >> - Put Standard 1.2.x in maintenance mode for bug fixes only >> - Start a tree/branch for new work without the limitations of the >> now-ancient 1.2 spec >> - Plan to release new work early & often > > I do not see a reason for branching. The library implements > specification. In what direction is "trunk" supposed to go? > > Possible directions: > a) Improve it for newer versions of Java, while still maintaining the same > API?
We had talked previously about dropping Java5 support and decided not to do that in 1.2.x release. I was thinking of a 2.x trunk that would allow us to baseline on a newer version, specifically Java8 given the public version of Java7 reaches EOL next month (April 2015). It was thinking about the lambda support that led me to the straw man I posted earlier today. Which leads to ... > b) Extend the library outside of specification? > c) Update it to newer versions of specification? I think there is no > new specification version now, but maybe there is some > development/plans? JSP is included in the list of technologies “expected to be updated” in Java EE 8 but as the JSR is still closed we won’t see anything until the PFD phase. Given recent history I would not expect to see any major changes. Since JSTL 1.0 came out we’ve see many changes in its space: * EL became a standalone thing * EL can call Java functions directly eliminating the need for function definitions in TLDs * Script-free JSP pages became best-practice * Pooling became less important leading to the SimpleTag model * Annotation, introspection and injection became commonplace * MVC meant JSPs became primarily a View component rather than playing the Controller role With the introduction of pruning abilities in EE6 some things that could go might include: * EL 1.0 and the legacy JSP APIs that support it * JSTL’s XML and SQL tags Rather than wait for the spec we could start to simplify the the model for people working at the JSP level (i.e. above Servlets but lower than JSF, perhaps in conjunction with the new MVC spec). > d) Work on built-in implementation of JSTL tags in Jasper? (Jasper Tag > plugins) Jasper has plugin for JSTL core but there are some edge cases it handles incorrectly. I should open bugs for them and we could fix those :) I’d actually like to take a second look at the plugin mechanism anyway - for example, why does it key off the tag’s implementation class rather than its QName. > I mean: If there is no new development planned, we would better stay > on the current trunk without separate maintenance branch. It is a bit > more risky, but it has less overhead. > > I would like to fix some of many generics warnings shown by Eclipse > IDE (either implement generics or to add @SupressWarning). No definite > time slot for that though as I am not sure whether it is worth to > spend time on that. Things I was thinking of in the current implementation include: * Making Java 8 the baseline JRE and updating to it (separate from any functional work) * Making Java EE 7 the baseline container and dropping -jstlel in favour of -compat - This would get rid of a many of those code-health warnings in one swoop :) - -compat would merge back into -impl * Separating the 4 libraries into separate modules (core, fmt, xml, sql) so: - Users would only need the libraries they actually used - We could release each module separately as needed - Xalan would only be needed when using the XML library - We could do an alternate fmt using ICU4J which typically updates quicker than the JDK I probably wasn’t clear originally - I meant this type of work would be on trunk and we’d create a stable branch 1.2.x to support bug-fixes. — Jeremy
signature.asc
Description: Message signed with OpenPGP using GPGMail
