WildFly 11 and JDK9
by Tomaž Cerar
Hey guys,
during development of WF11 we have done lots of work on making it build &
run on JDK9.
as release nears I would like to summarize what the current state is and
how to move on.
Currently most of our core [1] & full [2] testsuite passes on latest builds
of JDK9.
Remaining failures are already addressed by [3] and [4]
**But** passing testsuite on JDK9 is not the same as using our binary
distribution under JDK9.
Currently as part of running build / testsuite we override version of
javassit to 3.22.0-CR2
which is currently the only version that works properly on JDK9.
As there is no .GA version of javassit that work on JDK9 avalible we
currently do not have it as default.
On top of that, hibernate as main user of javassit is not tested enough
with this version of javassist
unless hibernate / JPA team says otherwise.
That would in practice mean that users running WF11 on JDK9 would have
issues with JPA/Hibernate
based applications.
Currently I see two options how to address this:
- upgrade javassist to 3.22.x in server, preferably ask for .GA release.
- produce additional WildFly.x.x.x-jdk9 zip that would include the newer
javassist.
So question is do we even want to have working JDK9 build of WildFly 11
.Final
or should we postpone this for next update release.
--
tomaz
[1]
https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9
[2] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea
[3] https://github.com/wildfly/wildfly-core/pull/2738
[4] https://github.com/wildfly/wildfly-core/pull/2751
6 years, 11 months
Version ownership (conflict?): Apache Avro
by Sanne Grinovero
Hi all,
I just noticed that the Apache Avro version included in WildFly was
upgraded to 1.8.1.
This breaks Hibernate Search. It wasn't caught by automated
integration tests as this aspect wasn't covered by integration tests
within the wildfly codebase - we have them within Hibernate.
A quick grep on the module definitions doesn't reveal any other user,
and "git blame" seems to suggest it was updated just for the sake of
updating some components.. so I'm guessing there is no other
stackeholder I should align with?
1# Could we please revert it to 1.7.6, which is what Hibernate Search requires?
Alternatively we'll need some ad-hoc coding on Hibernate Search and a
new version respin - with all associated risks - just for the sake of
updating this.
2# What can we do to prevent such things in the future?
I can of course contribute some more integration tests but it's never
going to be enough: there will always be more tests "upstream". Could
we rather agree on some improved communication process when you all
consider updating an indirect dependency?
Thanks,
Sanne
- https://issues.jboss.org/browse/WFLY-9221
7 years, 3 months
Ready for JDK 9 ?
by Rory O'Donnell
Hi Jason/Tomaz,
Thank you very much for all your testing of JDK 9 during its
development! Such contributions have significantly helped shape and
improve JDK 9.
Now that we have reached the JDK 9 Final Release Candidate phase [1] , I
would like to ask if your project can be considered to be 'ready for JDK
9', or if there are any remaining show stopper issues which you've
encountered when testing with the JDK 9 release candidate.
JDK 9 b181 is available at http://jdk.java.net/9/
If you have a public web page, mailing list post, or even a tweet
announcing you project's readiness for JDK 9, I'd love to add the URL to
the upcoming JDK 9 readiness page on the Quality Outreach wiki.
Looking forward to hearing from you,
Rory
[1] http://openjdk.java.net/projects/jdk9/
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
7 years, 3 months
