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