On Sat, Mar 28, 2020 at 7:07 AM Dmitry Gusev <dmitry.gu...@gmail.com> wrote:
> Hi Thiago, > Hello! > Just a small correct, the next LTS is Java 17 to be released in 2021. > Thanks for the info! > It would definitely be nice to provide intermediate releases that support > byte code for non-LTS versions to let us use newest language features. > Indeed. It was never out of my plans, though. It's just a case of updating the embedded ASM version and cut a new release. > Not sure about java 9 modules though, will tapestry development actually > benefit from them? > I believe so. We can actually prevent anyone from using internal classes directly, something that improves modularity and backward compatibility. > Or end projects built on top of/with tapestry? > Projects which are already modules themselves would benefit from it. > Are there any projects apart from JDK itself benefiting from modules? > I don't have a list right now, but I guess there's definitely a number of other projects out there already modularized. > Would be nice to hear users feedback here. > Yup! 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. > We already have genericsresolver-guava that deals with generics better than Tapestry-IoC itself does. Dmitry, is this what you're talking about? If yes, then we can create a ByteBuddy version of that, but it's not in my own plans. Or is it about replacing Plastic or replacing ASM in Plastic? That would a huuuuuuuuuuuuuuuuge project I definitely don't have the time for that nor I believe that would be a good priority. Also, we embed ASM into Tapestry-IoC for avoiding clashes with other ASM versions eventually used by other dependencies of end user projects, so we would need to embed ByteBuddy too for the same reason and that would still need a release for dealing with newer bytecode. > > 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 > -- Thiago
