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
