[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

DebConf25 Java/JVM BoF report



Hi,

Thank you to all those who participated to the Java/JVM BoF two weeks ago at DebConf25.

As with many things at this DebConf it was a bit chaotic to start but a fallback was quickly worked out and we could proceed with all 10 participants, 8 on site and 2 remote on Jitsi.

After a round of introduction we discussed the following items:

* build tools — I did a quick recap of where we currently were with the upgrades of Gradle and Kotlin, and Vladimir added a few words about his own contribution to this work. Work on some other popular build tools such as sbt and Bazel is also on the radar.


* IDEs — Vladimir reported that JetBrains is planning some changes in the distribution of IDEA [1] that may make it easier to package. As the same open source base is used for Android Studio and the source package already exists in Debian, we are certainly going to look at what else would be needed to build a working IDE at some point in the future.

[1]: https://blog.jetbrains.com/idea/2025/07/intellij-idea-unified-distribution-plan/

Then we considered the Eclipse IDE, and whether attempting to package it is a worthy and realistic goal. Emmanuel said that this project is too large to be properly packaged and maintained with our current resources and I agree with him: proper integration is complex, and it's tentacular, so it's likely to amount to a full-time job.

Mechtilde suggested that Debian could provide an installer script in contrib to help users install Eclipse quickly. Alex proposed that instead of providing the Eclipse IDE in Debian, detailed wiki pages could be written to help users to properly install the IDE on a Debian system. [Note: a page already exists [2] but it's probably incomplete and outdated.]

[2]: https://wiki.debian.org/Eclipse


* JDKs — Trixie will ship the JDK 21 (LTS), and unstable already features an Early Access preview of the next LTS (25) to be released in September. Vladimir performed a mass rebuild of Java packages [3] with it and ended up with only 39 build failures, much less than in the previous migration to 21 (146).

[3]: https://lists.debian.org/debian-java/2025/07/msg00000.html

During DebCamp I was told that some people believe that the JDKs provided by Debian are not fit for use in production as they are only "reference implementations", and they would like Debian to ship the Eclipse (previously Adoptium) Temurin builds instead. This would have some benefits (as Temurin is known and used by popular build tools and IDEs) but it's probably not possible because the Debian policy is likely to conflict with the Temurin trademark policy. Instead I suggested that we study and document the differences between both builds (that are probably pretty similar) and eventually work on minimizing the divergences.

I shared again my intention to reintroduce legacy LTS JDKs to the stable distribution for the purpose of building and testing packages, with no formal security support and appropriate disclaimers. Matthias would be fine with that. I still have to validate this plan with Moritz.


* transitions — from a trusted source (online references missing) I learned that it will soon be possible to do proper transitions [4] with Architecture: all packages (such as Java libraries). An update to the transition tracker is on the way, and scheduling binNMUs will be possible.

As a reminder:

The Release Team considers everything a transition where the upload of a package requires changes (rebuilds or actual patches) to reverse dependencies.

[4]: https://wiki.debian.org/Teams/ReleaseTeam/Transitions


* autopkgtests — they are on the radar too. Currently too much breakage caused by updates is detected (too) late; autopkgtests would help to detect issues sooner and take appropriate decisions. In some cases there are only a few dependencies that are missing to be able to run the upstream test suites.


* reproducible builds — the current trend is to have build tools (such as Gradle, but also Maven) validate cryptographic signatures of dependencies at build time. A way to build signed artifacts would be to have them signed by the maintainer and the signature(s) committed to the package source before upload: this would in practice enforce a strictly reproducible build between the developer system and the CI (though a way to fail the package build if the signature doesn't match has yet to be implemented).

Does Gradle fulfill the requirements for reproducible builds? Yes: features were included into this build tool to make it possible to build reproducibly with it.


* helping and Debian Java Documentation — documentation is outdated and users/developers/maintainers don't know where to look for. The Java Policy is due for some updates as well.

The Debian Go Packaging Team pages [5] are IMO an interesting example of how a "team portal" could be structured.

[5]: https://go-team.pages.debian.net/

To make the #debian-java IRC channel more welcoming for newcomers and discussions, it was proposed to move the gitlab notifications out of it to a separate channel and reduce their verbosity [and this was since done by lavamind — thank you!].

There is also the team blog [6] that hasn't been updated since 2019. I'm planning to post updates on major milestones of build tool upgrades, and it would be nice if someone else could prepare a post about "what's new in Trixie" summarizing the changes in and around Java packages that are about to be released.

[6]: https://java.debian.net/blog/


* next meeting — a quarterly video call on Jitsi? This was suggested and most participants seemed interested. For the first meeting I've started a poll [7] to figure out which days would be preferred in the range September 10 to 23, then by late August I will run another poll to choose a day and time within the most popular days.

[7]: https://beta.framadate.org/polls/92ae6badb5f59bf80f21


* group picture — unfortunately I wasn't able to convince my phone front camera to focus on the group behind me so we get ... an unvoluntarily privacy-preserving picture? [8] (I really should have taken more pictures with me completely out of the field then stitch them, but I didn't think about that at the time.) Sorry about that, but anyway here it is.

[8]: https://assets.chaos.social/media_attachments/files/114/955/272/469/556/489/original/f8248965003bb8e4.jpg


Cheers,

--
Julien Plissonneau Duquène


Reply to: