Hi Julien/All, I'm a member of the Eclipse Adoptium Working group (we produce the Temurin binaries) as well as working for $MSFT (where my Java team produces the MSFT Build of OpenJDK). I know that folks will be happy to compare build/test notes with y'all. It's in everyone's best interests to have rock solid OpenJDK binaries no matter the vendor :-).
Our build scripts + CI/CD pipeline configs & Linux installer scripts can be a little convoluted. If you need to chat with the Adoptium folks, they hang out on a Slack instance (sorry!). Assuming that's a no go then you can probably just communicate through GH Issues or some other mechanism? Also happy to chat about Aqa-test, TCK testing and the like (we've introduced some automation there) as well if that's helpful. Cheers, Martijn On Fri, 1 Aug 2025 at 13:09, Julien Plissonneau Duquène <sre4e...@free.fr> wrote: > 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 > >
