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 <ebo...@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 >
