We've had some problems with java 9 modules and building our (large) app
with Tapestry 5.5.
They may be *our* problems, but we would definitely welcome Tapestry
"rationalizing" the package & module structure as suggested by the java
9 modules.
Thanks!
On 3/28/2020 6:07 AM, Dmitry Gusev wrote:
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
--
Charles Roth
he.him.his
734-717-6803
lookfar.caucus.com <http://lookfar.caucus.com>
Software Architect & Political activist
<http://aavotes.org>
