Re: Updating source/target level for Java 21 compatibility to 8
Hi,
>For the previous Java migrations I started with a mass rebuild and then
filling a bug report for each broken package.
Thank you!!! I will follow the suite then - in addition to hardcoded
targets, there are about 93 packages with various compile errors
including javadoc issues.
>Interesting idea. Where would that variable be declared? In debhelper?
>Will the maintainers agree?
Yes, it has to be in the common code, e.g. debhelper, but adding
something specific to Java to it might not be a good solution.
>As a side note, bumping the source/target level isn't always the best
solution.These packages are a
recurrent source of issues when migrating to more recent JDKs, and they
are almost never used.
Maybe I can raise bugs for those and then the decision can be made on
a case by case basis?
Best Regards,
Vladimir.
On Fri, Sep 15, 2023 at 1:52 AM Emmanuel Bourg <ebourg@apache.org> wrote:
>
> Le 2023-09-14 01:03, Vladimir Petko a écrit :
>
> > Java 21 removes source/target compatibility level 7. Some packages (80
> > in total as per the attached list) have it specified in rules or
> > Makefiles.
> > I was wondering if it is okay to raise a single bug to update them and
> > submit the changes as pull requests on Salsa.
>
> For the previous Java migrations I started with a mass rebuild and then
> filling a bug report for each broken package. The reports had a user tag
> to be able to follow the progress (and document the main issues
> encountered).
>
> Here is for example the bug list for the migration to Java 17:
>
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java17;users=debian-java@lists.debian.org
>
> Personally I find it satisfying to see the list shrinking over time,
> I also hoped that it would entice new contributors to join the migration
> effort (but it barely materialized, if at all). But as long as the work
> is done it doesn't really matter how it is organized.
>
>
> > Also, we could add a DEB_ variable to specify the minimal supported
> > level. The variable will allow us to avoid repeating this work in the
> > future, but I am not sure what is the best way to provide it.
>
> Interesting idea. Where would that variable be declared? In debhelper?
> Will the maintainers agree?
>
> As a side note, bumping the source/target level isn't always the best
> solution. For example olap4j breaks when building the Javadoc, in this
> case I recommend scrapping the -java-doc package. These packages are a
> recurrent source of issues when migrating to more recent JDKs, and they
> are almost never used.
>
> Emmanuel Bourg
>
Reply to: