Hi Ben! I didn't try to compile Tapestry itself to target compatibility = 11, as I mentioned above it should probably remain java 8 for some time.
It isn't necessary for the time being, we may do so later when we implement proper jigsaw modules. For now I was talking mostly about using JDK 11 complier with source/targetCompatibility=8, to be able to create Java 11 compatibility tests. It shouldn't stop you from adding current state of the master branch in your Java 11 projects as regular 3rd party dependency, same as we did with ours. I can't recall any issues of using current state of the master branch with Java 11, Tapestry team and contributors already did most of the job. On Sun, Jun 23, 2019 at 4:10 PM Ben Weidig <b...@netzgut.net> wrote: > Hi Dmitry, > > thanks for all the work towards Java 11! > > We're trying to get it up and running ourselves but without much luck... > > You committed the patch for the private instrumentations, but I don't see > any modifications on the build.gradle, I assume this is because your > suggestion of doing Java 11 support after the release of 5.5.x > > Could you give us some pointers how we could build Tapestry 5.5 with > target/source for Java 11? > > So far we've done the following trying to get the project to build with > OpenJDK 11 and gradle on the command line including all tests: > - gradle update to 4.10.3 > - spock update to 1.2-groovy-2.4 > - settings.gradle: remove unnecessary projects (e.g. javadoc, kaptcha, > mongo, clojure etc.) > - build.gradle: jdkMajorVersion convert to int and remove "--add-modules" > for Java 11" > - build.gradle: remove dependencies on tapestry-javadoc (117) > - build.gradle: remove jacoco > - build.gradle: sourceCompatibility/targetCompatibility 11 > - build.gradle: idea project languageLevel 11 > > It's building, but testing is wonky, mostly becausome unit tests are > failing. JUnit tries to run helper classes as Tests (e.g. > AccessMethodsSubject, ProtectedFieldCollaborator), which fails with > initializationError. > > Integration tests run in Quantum, but some are failing, but maybe Quantum > is the reason here, didn't dig into it. > > Did you ran into any other bigger issues with running your projects on Java > 11? > > We have a few 100k lines of code and use the IoC heavily for projects > customization and would love to test it on our end and create > issues/patches in Jira if we run into any problems. > > Cheers, > Ben > > On Sat, Jun 22, 2019 at 11:56 PM Dmitry Gusev <dmitry.gu...@gmail.com> > wrote: > > > Hi everyone! > > > > Earlier this year I worked on a project where we upgraded all Tapestry > apps > > of one of our client to Java 11 with source & target compatibility = 11. > We > > were using custom version of Tapestry with only one patch on top of > current > > state of the master which I just checked in to the main code base: > > > > https://issues.apache.org/jira/browse/TAP5-2611 > > > > However I couldn't find a way to write a test for it as it would require > > some test classes compiled with Java 11 target compatibility level. > > > > I've found the following issue discussing migration path to Java 11 for > the > > Tapestry build, but the issue is now closed and there were not conclusion > > on what should be done next: > > > > https://issues.apache.org/jira/browse/TAP5-2588 > > > > I tried to upgrade the build to Java 11 before I found discussion in > > TAP5-2588, and I even upgraded most of it while experimenting and got all > > the tests green, except tapestry-javadoc module, which at first glance > > requires code rewrite and not just library upgrades and minor fixes as it > > was with core modules. > > > > I found that current build has some customisations for Java 9, and in > > TAP5-2588 there were discussions about supporting Java 10 also, but I > don't > > think that's necessary at the moment when Java 11 -- current LTS release > -- > > is out, as those are intermediate releases and are already not supported. > > > > So I would suggest to go straight to Java 11 after we release current > state > > of master (5.5.x). > > > > Starting from 5.6 all releases can remain binary compatible with java 8, > > but the build itself may leverage the java 11 compiler to start testing > > java 8+ compatibility, as required by TAP5-2611, for example. > > > > What do you think? > > > > Best regards, > > Dmitry > > > > > -- > > Netzgut GmbH > -- Dmitry Gusev AnjLab Team http://anjlab.com
