{"title":"Debian Java News","link":[{"@attributes":{"href":"http:\/\/java.debian.net\/blog\/","rel":"alternate"}},{"@attributes":{"href":"http:\/\/java.debian.net\/blog\/atom.xml","rel":"self"}}],"id":"http:\/\/java.debian.net\/blog\/","updated":"2019-01-31T14:00:00+01:00","entry":[{"title":"Help the Java Team distribute your project!","link":{"@attributes":{"href":"http:\/\/java.debian.net\/blog\/2019\/01\/help-the-java-team-distribute-your-project.html","rel":"alternate"}},"published":"2019-01-31T14:00:00+01:00","updated":"2019-01-31T14:00:00+01:00","author":{"name":"Hans-Christoph Steiner"},"id":"tag:java.debian.net,2019-01-31:\/blog\/2019\/01\/help-the-java-team-distribute-your-project.html","summary":"

There is a vast array of great free software projects written in Java.\nAll sorts of large systems that we all rely on every day are built\nupon the Apache Foundation libraries<\/a>.\nLarge companies like Google<\/a> and\nIBM<\/a>\nput out standard libraries that so many other projects use.\nUnfortunately, the standard practice for distributing Java code makes\nit a lot of work to integrate them into Debian.<\/p>\n

The Debian Java Team's work is generally under-appreciated, so we are\ngetting the word out here. The Java Team has to consistently fight the\nJava standard practice of bundling all deps into a single JAR. This\nmeans there is no shared security updates, each dev has to update\nevery dependency themselves in that model. That works great for large\ncompanies with staff devoted to doing that.<\/p>\n

For the majority of Debian use cases, that works poorly. Debian\ndelivers on the promise that people can just apt install foo<\/code> and\nhave it work, and receive security updates. The user does not even\nneed to know what language the program is written in, it just works.<\/p>\n

The Java developer community need to embrace the value of these use\ncases, and help Debian by making it easier to package Java projects in\nthe standard distro method, with shared dependencies that are\nindependently updated.<\/p>\n

Python and Ruby provide great examples of more flexible standard\npractice for shipping software. Both have methods of describing the\ndependencies needed, and then automatically fetching them. They are\ndesigned in a way that is quite easy to hook into the native build\nsystem and make Debian packages. That is sadly not the case with\nGradle<\/em> and Maven<\/em>, the most popular build systems for Java. For\nthose, the Java Team usually has to extensively patch the build system\nto make it work for the Debian package.<\/p>","content":"

There is a vast array of great free software projects written in Java.\nAll sorts of large systems that we all rely on every day are built\nupon the Apache Foundation libraries<\/a>.\nLarge companies like Google<\/a> and\nIBM<\/a>\nput out standard libraries that so many other projects use.\nUnfortunately, the standard practice for distributing Java code makes\nit a lot of work to integrate them into Debian.<\/p>\n

The Debian Java Team's work is generally under-appreciated, so we are\ngetting the word out here. The Java Team has to consistently fight the\nJava standard practice of bundling all deps into a single JAR. This\nmeans there is no shared security updates, each dev has to update\nevery dependency themselves in that model. That works great for large\ncompanies with staff devoted to doing that.<\/p>\n

For the majority of Debian use cases, that works poorly. Debian\ndelivers on the promise that people can just apt install foo<\/code> and\nhave it work, and receive security updates. The user does not even\nneed to know what language the program is written in, it just works.<\/p>\n

The Java developer community need to embrace the value of these use\ncases, and help Debian by making it easier to package Java projects in\nthe standard distro method, with shared dependencies that are\nindependently updated.<\/p>\n

Python and Ruby provide great examples of more flexible standard\npractice for shipping software. Both have methods of describing the\ndependencies needed, and then automatically fetching them. They are\ndesigned in a way that is quite easy to hook into the native build\nsystem and make Debian packages. That is sadly not the case with\nGradle<\/em> and Maven<\/em>, the most popular build systems for Java. For\nthose, the Java Team usually has to extensively patch the build system\nto make it work for the Debian package.<\/p>"},{"title":"Wheezy LTS and the switch to OpenJDK 7","link":{"@attributes":{"href":"http:\/\/java.debian.net\/blog\/2016\/06\/wheezy-lts-and-the-switch-to-openjdk-7.html","rel":"alternate"}},"published":"2016-06-19T00:00:00+02:00","updated":"2016-06-19T00:00:00+02:00","author":{"name":"Markus Koschany"},"id":"tag:java.debian.net,2016-06-19:\/blog\/2016\/06\/wheezy-lts-and-the-switch-to-openjdk-7.html","summary":"

Wheezy's LTS period started a few weeks ago and the LTS team had to make an\nearly support decision concerning the Java eco-system since Wheezy ships two Java\nruntime environments OpenJDK 6<\/a> and\nOpenJDK 7<\/a>. (To be fair, there are\nactually three but gcj<\/a> has\nbeen superseded by OpenJDK a long time ago and the latter should be preferred\nwhenever possible.)<\/p>\n

OpenJDK 6 is currently maintained by Red Hat and we mostly rely on their\nupstream work as well as on package updates from Debian's maintainer Matthias Klose and\nTiago St\u00fcrmer Daitx from Ubuntu. We already knew that both intend\nto support OpenJDK 6 until April 2017 when Ubuntu 12.04 will reach its\nend-of-life. Thus we had basically two options, supporting OpenJDK 6 for another\ntwelve months or dropping support right from the start. One of my first steps\nwas to ask for feedback and advice on\ndebian-java<\/a> since\nsupporting only one JDK seemed to be the more reasonable solution. We agreed on warning users\nvia various channels about the intended change, especially about possible\nincompatibilities<\/a>\nwith OpenJDK 7. Even Andrew Haley, OpenJDK 6 project lead, participated<\/a> in the discussion and confirmed that, while still supported, OpenJDK 6 security\nreleases are \"always the last in the queue when there is urgent work to be\ndone\".<\/p>\n

I informed debian-lts<\/a> about\nmy findings and issued a call for tests<\/a> later.<\/p>\n

Eventually we decided to concentrate our efforts on OpenJDK\n7<\/a> because we are confident that for the\nmajority of our users one Java implementation is sufficient during a stable\nrelease cycle. An immediate positive effect in making OpenJDK 7 the default is that\nresources can be relocated to more pressing issues. On the other hand we were\nalso forced to make compromises. The switch to a newer default implementation\nusually triggers a major transition with dozens of FTBFS bugs and the OpenJDK 7\ntransition<\/a>\nwas no exception. I pondered about the usefulness of fixing all these bugs for\nWheezy LTS again and focussing on runtime issues instead and finally decided\nthat the latter was both more reasonable and more economic.<\/p>\n

Different from regular default Java changes, users will still be able to use OpenJDK 6 to\ncompile their packages and the security impact for development systems is in general neglectable.\nMore important was to avoid runtime installations of OpenJDK 6. I identified eighteen\npackages that strictly depended on the now obsolete JRE and fixed those\nissues<\/a>\non 4 May 2016 together with an update of\njava-common<\/a> and announced the switch to\nOpenJDK 7 with a Debian NEWS file.<\/p>\n

If you are not a regular reader of Debian\nnews<\/a> and also not subscribed to\ndebian-lts<\/a>,\ndebian-lts-announce<\/a> or\ndebian-java<\/a>, remember 26 June\n2016<\/strong> is the day when OpenJDK 7 will be made the default Java implementation in\nWheezy LTS. Of course there is no need to wait. You can switch right now:<\/p>\n

<\/span>sudo update-alternatives --config java\n<\/pre><\/div>","content":"
Wheezy's LTS period started a few weeks ago and the LTS team had to make an\nearly support decision concerning the Java eco-system since Wheezy ships two Java\nruntime environments OpenJDK 6<\/a> and\nOpenJDK 7<\/a>. (To be fair, there are\nactually three but gcj<\/a> has\nbeen superseded by OpenJDK a long time ago and the latter should be preferred\nwhenever possible.)<\/p>\n
OpenJDK 6 is currently maintained by Red Hat and we mostly rely on their\nupstream work as well as on package updates from Debian's maintainer Matthias Klose and\nTiago St\u00fcrmer Daitx from Ubuntu. We already knew that both intend\nto support OpenJDK 6 until April 2017 when Ubuntu 12.04 will reach its\nend-of-life. Thus we had basically two options, supporting OpenJDK 6 for another\ntwelve months or dropping support right from the start. One of my first steps\nwas to ask for feedback and advice on\ndebian-java<\/a> since\nsupporting only one JDK seemed to be the more reasonable solution. We agreed on warning users\nvia various channels about the intended change, especially about possible\nincompatibilities<\/a>\nwith OpenJDK 7. Even Andrew Haley, OpenJDK 6 project lead, participated<\/a> in the discussion and confirmed that, while still supported, OpenJDK 6 security\nreleases are \"always the last in the queue when there is urgent work to be\ndone\".<\/p>\n
I informed debian-lts<\/a> about\nmy findings and issued a call for tests<\/a> later.<\/p>\n
Eventually we decided to concentrate our efforts on OpenJDK\n7<\/a> because we are confident that for the\nmajority of our users one Java implementation is sufficient during a stable\nrelease cycle. An immediate positive effect in making OpenJDK 7 the default is that\nresources can be relocated to more pressing issues. On the other hand we were\nalso forced to make compromises. The switch to a newer default implementation\nusually triggers a major transition with dozens of FTBFS bugs and the OpenJDK 7\ntransition<\/a>\nwas no exception. I pondered about the usefulness of fixing all these bugs for\nWheezy LTS again and focussing on runtime issues instead and finally decided\nthat the latter was both more reasonable and more economic.<\/p>\n
Different from regular default Java changes, users will still be able to use OpenJDK 6 to\ncompile their packages and the security impact for development systems is in general neglectable.\nMore important was to avoid runtime installations of OpenJDK 6. I identified eighteen\npackages that strictly depended on the now obsolete JRE and fixed those\nissues<\/a>\non 4 May 2016 together with an update of\njava-common<\/a> and announced the switch to\nOpenJDK 7 with a Debian NEWS file.<\/p>\n
If you are not a regular reader of Debian\nnews<\/a> and also not subscribed to\ndebian-lts<\/a>,\ndebian-lts-announce<\/a> or\ndebian-java<\/a>, remember 26 June\n2016<\/strong> is the day when OpenJDK 7 will be made the default Java implementation in\nWheezy LTS. Of course there is no need to wait. You can switch right now:<\/p>\n
<\/span>sudo update-alternatives --config java\n<\/pre><\/div>"},{"title":"What's new since Jessie?","link":{"@attributes":{"href":"http:\/\/java.debian.net\/blog\/2016\/05\/whats-new-since-jessie.html","rel":"alternate"}},"published":"2016-05-04T00:00:00+02:00","updated":"2016-05-04T00:00:00+02:00","author":{"name":"Emmanuel Bourg"},"id":"tag:java.debian.net,2016-05-04:\/blog\/2016\/05\/whats-new-since-jessie.html","summary":"
Jessie was released one year ago now and the Java Team has been busy preparing\nthe next release. Here is a quick summary of the current state of the Java packages:<\/p>\n