Re: Starting to move Gump to using Java 11
Mark Thomas <[email protected]> Wed, 11 Aug 2021 21:07:03 +0200
| Newsgroups | gmane.comp.jakarta.gump |
|---|---|
| Message-ID | <[email protected]> |
On 11/08/2021 10:46, Mark Thomas wrote: > On 11/08/2021 09:06, Adam Jack wrote: >> I am traveling home from abroad right now but I can look into things >> when I >> get settled back. That said, I am sure others are far less rusty than >> me on >> this. That said, from my rusty/simplistic perspective: >> >> Would the best case be that the whole stack be built with one >> compiler/language version, the newest supported, so we uncover any build >> issues and then mail them to teams? Would that be helpful to getting >> those >> build issues resolved, or are such notifications going unanswered? >> Meaning >> do we change the Java version and then wait, rather than work around >> things? >> >> Sorry if that is missing something obvious (I haven’t touched Java in >> well >> over a decade.) > > Thanks. Additional eyes on this would be good. > > I agree that in an ideal world, everything would build with the latest > version of Java. Switching from Java 8 to Java 11 was a step in that > direction. > > The complicating factor is that the chain of dependencies leads back to > (branches of) projects that are no longer maintained and don't build > with Java >8. In some cases, updating the dependencies to newer branches > is an option. I managed to remove Commons Lang 2.x from the dependency > chain that way. However, there are some dependency chains where that > does not appear to be an option. Maybe the right answer is that we > should just provide JARs for such projects rather than trying to build > them. > > Also, there are potentially some dependencies where we aren't building > from source and perhaps should be such as the Eclipse JDT JAR. > > Given that Tomcat is the only project really using Gump right now, I > think I am going to start there and work backwards checking dependencies > as I suspect some of those may be rather out of date. It might be that > the problem will turn out to be a lot simpler than it appears, once the > dependencies are tidied up. Packaging log4j 1.2.x and removing a number of the old XML dependencies has improved things quite a bit. I think there has been sufficient progress to continue running with Java 11 and fix the remaining issues as they arise. As part of the clean-up / simplification I am currently planning on pruning various optional dependencies unless the Tomcat builds require them. Please speak up if there are any objections to doing this. Mark