Hi Thiago, Just a small correct, the next LTS is Java 17 to be released in 2021.
It would definitely be nice to provide intermediate releases that support byte code for non-LTS versions to let us use newest language features. Not sure about java 9 modules though, will tapestry development actually benefit from them? Or end projects built on top of/with tapestry? Are there any projects apart from JDK itself benefiting from modules? Would be nice to hear users feedback here. One idea that crossed my mind few times is adding support for ByteBuddy in favour of, or in addition to tapestry-plastic. Mostly to improve generics support in proxies, but may also benefit from other latest language features, not existing and newcoming. Regards, Dmitry On Fri, Mar 27, 2020 at 7:44 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Hello, Tapestry community! > > I have some ideas for Tapestry's next steps and I'd like to receive your > input about them. > > Tapestry 5.5 supports Java 12 bytecode. This is done through an embedded > copy of the ASM bytecode library. We change the package names so they don't > clash with the ASM version eventually used by other dependencies of your > project. A few other changes are also needed, the only one I recall right > now is changing one specific method visibility to public so it can be used > in Plastic. > > For 5.6, since Java 14, a long term support release, was released last week > and I guess lots of people are eager to try it, I was thinking of grabbing > the latest stable version of ASM to pick up its support for Java 14 > bytecode. We could have 5.6 released next month just for that and then have > later minor versions for fixes and improvements or wait a bit and have a > single release for everything. I prefer the first option. > > For 5.7, I was thinking of implementing something suggested by more than > one people (I apologize for not recalling who): separating the page library > (i.e. all the support for pages, components and mixins) from the rest of > tapestry-core (i.e. the request handling part: HttpServletRequestFilter, > RequestFilter, Dispatcher, asset support, etc). Ilya also suggested the > possibility of separating corelib (the component library provided by > Tapestry out of the box) from the rest of the framework, an interesting > idea, but I'm not sure that's really needed. If you need you own version of > some components, you can use the ComponentOverride service. This way, for > example, you can have your own implementation of Grid and have it > automatically used in all <t:grid> or <div t:type="Grid"> usages. But I'm > open to different opinions. I'm actually inviting them, and I may even > change my opinions. :) > > Also for 5.7, I'm planning to make the Tapestry JARs proper Java 9 modules. > This will require moving classes, maybe a lot of them, from one package to > another, since a package cannot be in more than one module and Tapestry has > a number of cases of this. > > Also for 5.7, build Tapestry with Java 11 instead of 8, which has mostly > reached its end of life already, not getting more updates and fixes from > Oracle unless you have a support contract. I don't want anyone sticking to > old Tapestry versions because they're still stuck with an old Java version, > but I guess we can agree Java 8 is pretty old by now. 2 major (i.e. LTS > releases) behind. > > Comments? Suggestions? Ideas? Please post them here! > > Cheers! > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
