Help the Java Team distribute your project!

 Thu 31 January 2019 by Hans-Christoph Steiner

There is a vast array of great free software projects written in Java. All sorts of large systems that we all rely on every day are built upon the Apache Foundation libraries. Large companies like Google and IBM put out standard libraries that so many other projects use. Unfortunately, the standard practice for distributing Java code makes it a lot of work to integrate them into Debian.

The Debian Java Team's work is generally under-appreciated, so we are getting the word out here. The Java Team has to consistently fight the Java standard practice of bundling all deps into a single JAR. This means there is no shared security updates, each dev has to update every dependency themselves in that model. That works great for large companies with staff devoted to doing that.

For the majority of Debian use cases, that works poorly. Debian delivers on the promise that people can just apt install foo and have it work, and receive security updates. The user does not even need to know what language the program is written in, it just works.

The Java developer community need to embrace the value of these use cases, and help Debian by making it easier to package Java projects in the standard distro method, with shared dependencies that are independently updated.

Python and Ruby provide great examples of more flexible standard practice for shipping software. Both have methods of describing the dependencies needed, and then automatically fetching them. They are designed in a way that is quite easy to hook into the native build system and make Debian packages. That is sadly not the case with Gradle and Maven, the most popular build systems for Java. For those, the Java Team usually has to extensively patch the build system to make it work for the Debian package.

Wheezy LTS and the switch to OpenJDK 7

 Sun 19 June 2016 by Markus Koschany

Wheezy's LTS period started a few weeks ago and the LTS team had to make an early support decision concerning the Java eco-system since Wheezy ships two Java runtime environments OpenJDK 6 and OpenJDK 7. (To be fair, there are actually three but gcj has been superseded by OpenJDK a long time ago and the latter should be preferred whenever possible.)

OpenJDK 6 is currently maintained by Red Hat and we mostly rely on their upstream work as well as on package updates from Debian's maintainer Matthias Klose and Tiago Stürmer Daitx from Ubuntu. We already knew that both intend to support OpenJDK 6 until April 2017 when Ubuntu 12.04 will reach its end-of-life. Thus we had basically two options, supporting OpenJDK 6 for another twelve months or dropping support right from the start. One of my first steps was to ask for feedback and advice on debian-java since supporting only one JDK seemed to be the more reasonable solution. We agreed on warning users via various channels about the intended change, especially about possible incompatibilities with OpenJDK 7. Even Andrew Haley, OpenJDK 6 project lead, participated in the discussion and confirmed that, while still supported, OpenJDK 6 security releases are "always the last in the queue when there is urgent work to be done".

I informed debian-lts about my findings and issued a call for tests later.

Eventually we decided to concentrate our efforts on OpenJDK 7 because we are confident that for the majority of our users one Java implementation is sufficient during a stable release cycle. An immediate positive effect in making OpenJDK 7 the default is that resources can be relocated to more pressing issues. On the other hand we were also forced to make compromises. The switch to a newer default implementation usually triggers a major transition with dozens of FTBFS bugs and the OpenJDK 7 transition was no exception. I pondered about the usefulness of fixing all these bugs for Wheezy LTS again and focussing on runtime issues instead and finally decided that the latter was both more reasonable and more economic.

Different from regular default Java changes, users will still be able to use OpenJDK 6 to compile their packages and the security impact for development systems is in general neglectable. More important was to avoid runtime installations of OpenJDK 6. I identified eighteen packages that strictly depended on the now obsolete JRE and fixed those issues on 4 May 2016 together with an update of java-common and announced the switch to OpenJDK 7 with a Debian NEWS file.

If you are not a regular reader of Debian news and also not subscribed to debian-lts, debian-lts-announce or debian-java, remember 26 June 2016 is the day when OpenJDK 7 will be made the default Java implementation in Wheezy LTS. Of course there is no need to wait. You can switch right now:

sudo update-alternatives --config java

What's new since Jessie?

 Wed 04 May 2016 by Emmanuel Bourg, Markus Koschany, Tony Mancill

Jessie was released one year ago now and the Java Team has been busy preparing the next release. Here is a quick summary of the current state of the Java packages:

  • A total of 136 packages have been added, 63 removed, 213 upgraded to a new upstream release, and 145 updated. We are now maintaining 892 packages (+12.34%).
  • OpenJDK 8 is now the default Java runtime in testing/unstable. OpenJDK 7 has been removed, as well as several packages that couldn't be upgraded to work with OpenJDK 8 (avian, eclipse).
  • OpenJDK 9 is available in experimental. As a reminder, it won't be part of the next release; OpenJDK 8 will be the only Java runtime supported for Stretch.
  • Netbeans didn't make it into Jessie, but it is now back and up to date.
  • The main build tools are close to their latest upstream releases, especially Maven and Gradle which were seriously lagging behind.
  • Scala has been upgraded to the version 2.11. We are looking for Scala experts to maintain the package and its dependencies.
  • Freemind has been removed due to lack of maintenance, Freeplane is recommended instead.
  • The reproducibility rate has greatly improved, climbing from 50% to 75% in the past year.
  • Backports are continuously provided for the key packages and applications: OpenJDK 8, OpenJFX, Ant, Maven, Gradle, Tomcat 7 & 8, Jetty 8 & 9, OpenJDK 8, OpenJFX, jEdit.
  • The transition to Maven 3 has been completed, and packages are no longer built with Maven 2.
  • We replaced several obsolete libraries and transitioned them to their latest versions - for example, asm2, commons-net1 and commons-net2. Groovy 1.x was replaced with Groovy 2, and we upgraded BND, an important tool to develop with OSGi, and more than thirty of its reverse-dependencies from the 1.x series to version 2.4.1.
  • New packaging tools have been created to work with Gradle (gradle-debian-helper) and Ivy (ivy-debian-helper).

Outlook, goals and request for help

  • We have several difficult transitions ahead: BND 3, Tomcat 7 to 8, Jetty 8 to 9, ASM 5, and of course Java 9. Any help would be welcome.
  • Eclipse is severely outdated and currently not part of testing. We would like to update this important piece of software and its corresponding modules to the latest upstream release, but we need more active people who want to maintain them. If you care about the Eclipse ecosystem, please get in touch with us.
  • We still are in the midst of removing old libraries like asm3, commons-httpclient and the servlet 2.5 API, which is part of the Tomcat 6 source package.
  • Want to see Azureus/Vuze in Stretch again? Packaging is almost complete but we are looking for someone who can clarify remaining licensing issues with upstream and wants to maintain the software for the foreseeable future.
  • Do you have more ideas and want to get involved with the Java Team? Just send your suggestions to debian-java@lists.debian.org or chat with us on IRC at irc.debian.org, #debian-java.

Java and Friends

  • The Java Team is not the only team that maintains Java software in Debian. DebianMed, DebianScience and the Android Tools Maintainers rely heavily on Java. By helping the Java Team and working together, you can improve the Java ecosystem and further the efforts of multiple other fields of endeavor all at once.

Package updates

The packages listed below detail the changes in jessie-backports and testing. Libraries and Debian specific tools have been excluded.

Packages added to jessie-backports:

Packages removed from testing:

Packages added to testing:

Packages upgraded in testing:

Page 1 / 1

Links