Hi,

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.

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.

Best Regards,
Vladimir.

YW50bHIzCmFydGZhc3RxZ2VuZXJhdG9yCmF2YWxvbi1mcmFtZXdvcmsKYXhpcwpiZWFuc2JpbmRp bmcKY2FkZW5jaWkKY2hlc2hpcmUtY2xvanVyZQpjbGoteWFtbC1jbG9qdXJlCmNvY28tamF2YQpj b20taHlwaXJpb24taW8tY2xvanVyZQpjcHB0YXNrcwpkYjUuMwpkYnVzLWphdmEKZGljb21zY29w ZQpkb2N0b3JqCmRybWlwcwpnbHVlZ2VuMgpnbm9tZS1zcGxpdApqYWp1awpqYXZhLWltYWdpbmct dXRpbGl0aWVzCmphdmFtb3JwaApqY2hhcnRzCmpjbGljCmpmbGV4CmpmcmFjdGlvbmxhYgpqbGFw YWNrCmpsaWJlcHMKam1vbApqb2Rjb252ZXJ0ZXIKam9kY29udmVydGVyLWNsaQpqc3NjCmpzdXJm LWFsZ2dlbwpqdGIKanVuaXQKanZlcmVpbgpqeHBsb3Jlcgpqem1xCmtpbmcKa25vcGZsZXJmaXNo LW9zZ2kKbGliY29tbW9ucy1sb2dnaW5nLWphdmEKbGliZnJlZW1hcmtlci1qYXZhCmxpYmh0bWxw YXJzZXItamF2YQpsaWJpYmF0aXMtamF2YQpsaWJpdGV4dDEtamF2YQpsaWJqYW1vbi1qYXZhCmxp Ym1hdHRoZXctamF2YQpsaWJ4YWxhbjItamF2YQpsaWJ4ZXJjZXMyLWphdmEKbGluay1ncmFtbWFy Cmx1Y2VuZS1zb2xyCmx1Y2VuZTQuMTAKbHo0LWphdmEKbWF2ZW4tcmVwby1oZWxwZXIKbWVjYWIK bWluYQptb2JpbGUtYXRsYXMtY3JlYXRvcgpuYXRicmFpbGxlCm5la29odG1sCm9sYXA0agpvcHRp Y2FscmF5dHJhY2VyCm9ydGhhbmMtaW1hZ2VqCm9zZ2ktZm91bmRhdGlvbi1lZQpwaWVzcHkKcGl4 ZWxtZWQKcGl4ZWxtZWQtY29kZWMKcGxhbnR1bWwKc2xhc2h0aW1lCnNzdm5jCnN1cmFua2NvCnN2 bmtpdApzd2VldGhvbWUzZApzd2VldGhvbWUzZC1mdXJuaXR1cmUtZWRpdG9yCnN3ZWV0aG9tZTNk LXRleHR1cmVzLWVkaXRvcgpzd2ktcHJvbG9nCnRpZ2h0dm5jLWphdmEKdHJ1ZmZsZQp0cnVmZmxl LWRzbC1wcm9jZXNzb3IKdmlzdWFsdm0KeG1sLWNvbW1vbnMtZXh0ZXJuYWwKeHotamF2YQoK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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;[email protected]

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <[email protected]> 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;[email protected]

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

I have prepared a script[1] to report the obvious failures here[2]. I
wonder if I should send a mass bug filing email to debian-devel
mailing list before running it?

Best Regards,
Vladimir.

[1] https://git.launchpad.net/~vpa1977/+git/default-java21/tree/report-all.sh?h=main
[2] https://git.launchpad.net/~vpa1977/+git/default-java21/tree/?h=main

On Fri, Sep 15, 2023 at 9:54 AM Vladimir Petko
<[email protected]> wrote:

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 <[email protected]> wrote:

Le 2023-09-14 01:03, Vladimir Petko a écrit :

Java 21 removes source/target compatibility level 7. Some packages (8

0

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;[email protected]

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 2023-09-25 04:17, Vladimir Petko a écrit :

I have prepared a script[1] to report the obvious failures here[2]. I
wonder if I should send a mass bug filing email to debian-devel
mailing list before running it?

Best Regards,
Vladimir.

[1] https://git.launchpad.net/~vpa1977/+git/default-java21/tree/report-all.sh?h=main
[2] https://git.launchpad.net/~vpa1977/+git/default-java21/tree/?h=main

Nice! I've rebuilt the Java packages last week and started filling a few
bugs,
but it looks like you've already caught most of them. I suggest a minor
tweak
to the script, the severity could be set to important since these bugs
will
turn into build failures in the near future. Also there is an
unnecessary space
before "FTBFS".

Go ahead and file the bugs. I'll probably reword the titles afterwards
to add
a description of the issue, that's convenient to pick and fix similar
bugs
from the list.

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)