Bug#897945: [Openjdk] Bug#920037: Bug#897945: #897945 still present/breaks with Java 8

2019-02-05 Thread Emmanuel Bourg
Le 05/02/2019 à 15:05, Emmanuel Bourg a écrit :

> The real issue is lombok, it needs both Java 8 and 11 to build (and even
> 6 and 7! But we managed do to without that).

Erratum: I've just figured out how to build lombok with Java 11 only.
Once ivyplusplus is taught about the new javac 'release' option it's
easy. Uploads will follow soon.

Emmanuel Bourg



Bug#897945: [Openjdk] Bug#920037: Bug#897945: #897945 still present/breaks with Java 8

2019-02-05 Thread Emmanuel Bourg
Hi all,

Le 05/02/2019 à 14:24, Per Lundberg a écrit :

> is this the correct list of packages which can only be built w/ openjdk-8

That's almost correct:
- jzmq and openjfx are built with openjdk-11 already
- openjdk-8-jre-dcevm has just been removed, replaced by
openjdk-11-jre-dcevm (not in testing yet)
- leiningen-clojure is about to be updated with Java 11 compatibility
- uwsgi builds with openjdk-11, but supports openjdk-8 on kfreebsd. The
Java 8 plugin can probably be dropped.
- virtualbox switched to openjdk-11 a few days ago
- icedtea-web should support Java 11 in the next upstream release

The real issue is lombok, it needs both Java 8 and 11 to build (and even
6 and 7! But we managed do to without that). This is a complicated
package that is now a key part of the Java ecosystem in Debian, and we
can't really do without it. It looks like the latest releases have
improved the Java 11 support but I doubt it can build without Java 8.

Note that we'll still need OpenJDK 8 as part of the SBT packaging effort
(which is required to build Scala 2.12). I wouldn't be surprised to see
it required as well to bootstrap Kotlin. So even if we managed to ship
Buster without openjdk-8, the package should remain in unstable until
this is sorted out.

Emmanuel Bourg



Bug#897945: [Openjdk] Bug#920037: Bug#897945: #897945 still present/breaks with Java 8

2019-02-05 Thread Per Lundberg
On 2/4/19 10:07 PM, Moritz Mühlenhoff wrote:

> What is the specific use case for this, is there some package which
> needs 8 and can't be fixed in time for 11?

Yes, it was stated in this thread earlier that such packages do exist.

Emmanuel/others, is this the correct list of packages which can only be 
built w/ openjdk-8 or am I missing something out? If so, it doesn't seem 
like a huge list and making all of these work on openjdk-11 "could" be 
doable/the release could possibly live without them. (well, ideally not 
of course)

$ grep-dctrl -FBuild-Depends openjdk-8 -sPackage /var/lib/apt/lists/*Sources
Package: virtualbox
Package: icedtea-web
Package: jzmq
Package: leiningen-clojure
Package: libbluray
Package: lombok
Package: openjdk-8
Package: openjdk-8-jre-dcevm
Package: openjdk-8
Package: openjfx
Package: uwsgi

Personally, I still rely on openjdk-8 for my work (because of customer 
environments still using it for at least 3-5 more years), but I can live 
with getting it from an unofficial repository. It's more important to 
provide a smooth user experience for the majority of people, who are 
perhaps not _developers_ of Java-based software but more _users_ of the 
same.

Best regards,
--
Per


Bug#897945: [Openjdk] Bug#920037: Bug#897945: #897945 still present/breaks with Java 8

2019-02-04 Thread Moritz Mühlenhoff
On Mon, Feb 04, 2019 at 03:04:41PM +0100, Markus Koschany wrote:
> I would add a NEWS file to OpenJDK 8 and explain the situation and in
> addition create a wrapper around the OpenJDK 8 java command that prints
> out a message and quits. javac shall continue to work because it is
> needed to build some packages. The debconf approach could also work but
> it is a bit more work to implement. Then we also announce it via release
> news. Just some thoughts.

What is the specific use case for this, is there some package which
needs 8 and can't be fixed in time for 11?

If we do keep openjdk-8 after all, could we simply omit the jre binary
packages when building for distrel=buster? That should ensure that noone
uses an unsupported Java (along with a NEWS file maybe) to run Java
applications.

Cheers,
Moritz



Bug#897945: [Openjdk] Bug#920037: Bug#897945: #897945 still present/breaks with Java 8

2019-02-04 Thread Markus Koschany


Am 04.02.19 um 14:56 schrieb Per Lundberg:
> On 2/1/19 11:20 AM, Matthias Klose wrote:
>> On 01.02.19 10:03, Emmanuel Bourg wrote:
> 
>>> This is an excellent suggestion. We should file a bug for openjdk-8 to
>>> implement that.
>> please attach the patch.
> 
> Sure, I should be able to write something up. Forbear my ignorance: 
> should I use debconf to show the message or what do you think would be 
> right approach? (I haven't been involved at this level in Debian since I 
> stepped down as package maintainer 15 years ago. :)
> 
> Best regards,
> Per
> 

Hi,

I would add a NEWS file to OpenJDK 8 and explain the situation and in
addition create a wrapper around the OpenJDK 8 java command that prints
out a message and quits. javac shall continue to work because it is
needed to build some packages. The debconf approach could also work but
it is a bit more work to implement. Then we also announce it via release
news. Just some thoughts.

Best,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#897945: [Openjdk] Bug#920037: Bug#897945: #897945 still present/breaks with Java 8

2019-02-04 Thread Per Lundberg
On 2/1/19 11:20 AM, Matthias Klose wrote:
> On 01.02.19 10:03, Emmanuel Bourg wrote:

>> This is an excellent suggestion. We should file a bug for openjdk-8 to
>> implement that.
> please attach the patch.

Sure, I should be able to write something up. Forbear my ignorance: 
should I use debconf to show the message or what do you think would be 
right approach? (I haven't been involved at this level in Debian since I 
stepped down as package maintainer 15 years ago. :)

Best regards,
Per


Bug#897945: [Openjdk] Bug#920037: Bug#897945: #897945 still present/breaks with Java 8

2019-02-01 Thread Matthias Klose
On 01.02.19 10:03, Emmanuel Bourg wrote:
> Le 01/02/2019 à 09:17, Per Lundberg a écrit :
> 
>> I think that risk is significant. If we go that route, I would suggest a 
>> postinst/debhelper message saying that "OpenJDK 8 is included but 
>> unsupported. Many packages will not work with it. Use at your own risk." 
>> or something similar.
> 
> This is an excellent suggestion. We should file a bug for openjdk-8 to
> implement that.

please attach the patch.



Bug#897945: #897945 still present/breaks with Java 8

2019-02-01 Thread Emmanuel Bourg
Le 01/02/2019 à 09:17, Per Lundberg a écrit :

> I think that risk is significant. If we go that route, I would suggest a 
> postinst/debhelper message saying that "OpenJDK 8 is included but 
> unsupported. Many packages will not work with it. Use at your own risk." 
> or something similar.

This is an excellent suggestion. We should file a bug for openjdk-8 to
implement that.

Emmanuel Bourg



Bug#897945: #897945 still present/breaks with Java 8

2019-02-01 Thread Per Lundberg
On 1/29/19 3:36 PM, Markus Koschany wrote:

> We usually ship only with one JDK per release because of security
> support. OpenJDK 8 will be EOL before the end of the Debian 10 release
> cycle. We still have a couple of packages that will not compile with
> OpenJDK 11 hence we also thought about shipping OpenJDK 8 for building
> those packages but declaring it as unsupported at runtime. However, as
> this bug report shows, people tend to assume that OpenJDK 8 is supported
> as well.

Yes, it's easy to get this impression and I think it'll get even worse 
when more people start using Buster.

> So we either end up without OpenJDK 8 in Buster at all and with
> less packages, that are only there to build other packages, or we
> declare OpenJDK 8 as unsupported at runtime in our release notes which
> carries the risk of nobody reading them.

I think that risk is significant. If we go that route, I would suggest a 
postinst/debhelper message saying that "OpenJDK 8 is included but 
unsupported. Many packages will not work with it. Use at your own risk." 
or something similar.

But removing it altogether is probably less cumulative work for the 
whole Debian team in the long run, so I think that option should be 
strongly considered. It will also increase the motivation for people to 
fix the broken packages to build correctly on OpenJDK 11... :-)

(Do we have a list of these packages btw?)

Best regards,
--
Per


Bug#897945: #897945 still present/breaks with Java 8

2019-01-29 Thread Markus Koschany


Am 29.01.19 um 14:19 schrieb Per Lundberg:
> Hi Markus,
> 
> On 1/29/19 1:32 PM, Markus Koschany wrote:
>>
>>> I am sorry but OpenJDK 8 will not be supported at runtime in
>>> Buster.
> Another question: if this is the case, should the openjdk-8-jdk package 
> (and friends) be removed altogether in sid? I looked briefly but 
> couldn't find any bugs mentioning this.

This is Debian bug:

https://bugs.debian.org/920037

We usually ship only with one JDK per release because of security
support. OpenJDK 8 will be EOL before the end of the Debian 10 release
cycle. We still have a couple of packages that will not compile with
OpenJDK 11 hence we also thought about shipping OpenJDK 8 for building
those packages but declaring it as unsupported at runtime. However, as
this bug report shows, people tend to assume that OpenJDK 8 is supported
as well. So we either end up without OpenJDK 8 in Buster at all and with
less packages, that are only there to build other packages, or we
declare OpenJDK 8 as unsupported at runtime in our release notes which
carries the risk of nobody reading them.



signature.asc
Description: OpenPGP digital signature


Bug#897945: #897945 still present/breaks with Java 8

2019-01-29 Thread Emmanuel Bourg
Le 29/01/2019 à 14:19, Per Lundberg a écrit :

> Another question: if this is the case, should the openjdk-8-jdk package 
> (and friends) be removed altogether in sid?

We can't remove openjdk-8 yet, it's still required to build some
convoluted packages. But Buster will only support OpenJDK 11, this will
be documented in the release notes.

Emmanuel Bourg



Bug#897945: #897945 still present/breaks with Java 8

2019-01-29 Thread Markus Koschany

Am 29.01.19 um 13:54 schrieb Per Lundberg:
[...]
> But, the approach you suggest is fine. Markus, will you reopen this bug 
> or should we file a new one about it, what do you prefer?

I think we don't need a new bug report for that. I will change that
later today.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#897945: #897945 still present/breaks with Java 8

2019-01-29 Thread Per Lundberg
Hi Markus,

On 1/29/19 1:32 PM, Markus Koschany wrote:
> 
>> I am sorry but OpenJDK 8 will not be supported at runtime in
>> Buster.
Another question: if this is the case, should the openjdk-8-jdk package 
(and friends) be removed altogether in sid? I looked briefly but 
couldn't find any bugs mentioning this.


Bug#897945: #897945 still present/breaks with Java 8

2019-01-29 Thread Per Lundberg
On 1/29/19 1:32 PM, Markus Koschany wrote:

Hi Markus and Emmanuel,

Emmanuel - the problem is that VisualVM will display its splash screen, 
then die with an error in the log about java.lang.NoSuchMethodError: 
java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;

>> I am sorry but OpenJDK 8 will not be supported at runtime in
>> Buster. If it works with OpenJDK 11, which it does, then we should
>> spend the remaining time before the release on more urgent issues.
> 
> I should have added that we compile for Java 9 bytecode with the
> - -Dpermit.jdk9.builds=true switch in visualvm and in
> libnb-platform18-java. No surprises here that it won't work with
> OpenJDK 8.

I am fine with this; we should just try to make the user experience a 
bit smoother.

> What we can and probably should do is to force OpenJDK 11
> by using a stricter dependency on default-jdk (>= 2:1.11) | java11-sdk
> and by also updating the 03-launcher.patch and remove the alternative
> search paths for OpenJDK 7 and OpenJDK 8. The result is that visualvm
> simply will not start anymore and quit with "No jdkhome found" if
> someone uses an unsupported JDK.

That sounds like a reasonable path: the effort should not be huge, and 
the user experience will be improved. The problem right now (with Java 
8) is that it just "dies" as described above, no error message printed. 
You have to more or less _know_ that you should go digging in 
~/.visualvm/1.4/var/log/messages.log for it. This is not so great.

But, the approach you suggest is fine. Markus, will you reopen this bug 
or should we file a new one about it, what do you prefer?
--
Best regards,
Per


Bug#897945: #897945 still present/breaks with Java 8

2019-01-29 Thread Markus Koschany
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am 29.01.19 um 12:06 schrieb Markus Koschany:

> I am sorry but OpenJDK 8 will not be supported at runtime in
> Buster. If it works with OpenJDK 11, which it does, then we should
> spend the remaining time before the release on more urgent issues.

I should have added that we compile for Java 9 bytecode with the
- -Dpermit.jdk9.builds=true switch in visualvm and in
libnb-platform18-java. No surprises here that it won't work with
OpenJDK 8. What we can and probably should do is to force OpenJDK 11
by using a stricter dependency on default-jdk (>= 2:1.11) | java11-sdk
and by also updating the 03-launcher.patch and remove the alternative
search paths for OpenJDK 7 and OpenJDK 8. The result is that visualvm
simply will not start anymore and quit with "No jdkhome found" if
someone uses an unsupported JDK.
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAlxQOa9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD
RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQACgkQ2a0UuVE7
UeRmiw/+Nxkz+4R+Uk6qgYyFtkTnM6zLvOOrb8QD+jrKpsomm6qstnAJuj0sPogG
Rz0q/NUjYT4YYzR7pROjXI6287E3G0fmYyVGep7lQWyEPCWMsKAHpN+Ya7S81mpD
PI6c2CQ3MvkdG38v5E+Jt0ILzFGmzE7eNtpnXBPVDrMi7+hLsxULQe+NR5GOdL15
c2kADaexqvxwgoRD75OeWtFapboAaMzm5Lj16q6wC3mygU8d0uBHuAbhMfW8AFIH
nHOLoGYj7Dxkhb7dILMCuTqL208oGGhQT/d5sX8xXRLV/WYH7bHCvTlABPMAgjlB
IqAXGfSZ70GY2hp1gN3iElAyS8vRjXrlAyTzar4ulx38WqD79qeKtan90+rcL3eA
mxZjtrHQtvjDW6JaPuEDkfRbT7gUOa1AldzxjprK/p7DwTpqLWAIGax+xnvWgWC0
V6w5/iCYprDzVSJQhQXDt5VyMOGgDkNyZ/0J2yJAADQ/4uFnsuSnrAw4YO/rlm4k
+fYXoBEdGqYHGe3l0BmTdvSOX279n6YzZCQUWX6IbuMeW0kNLtYD8CI355gS/2cG
CBNVE50YQZ95+h84tlmaL5Ce+xmEpxy14PNyKoFVfQwQA10ZR2eTvU8SODUtzkRs
yed/BEwbFZShUH42d98I/lJj86gmNE2hA2vwjuQQHZEqzKktxDU=
=p+tq
-END PGP SIGNATURE-



Bug#897945: #897945 still present/breaks with Java 8

2019-01-29 Thread Markus Koschany

Am 29.01.19 um 10:58 schrieb Emmanuel Bourg:
> Le 29/01/2019 à 10:40, Per Lundberg a écrit :
>> FWIW, version 1.4.2-1 works correctly with openjdk-11-jdk version 
>> 11.0.2+7-1, but it _does not_ work correct any more with Java 8 
>> (openjdk-8-jdk version 8u191-b12-2)
> 
> Thank you for the feedback Per. What issue did you see when using
> visualvm with Java 8? You tried running visualvm with Java 8 or you
> tried attaching visualvm to a Java 8 VM?
> 
> Emmanuel Bourg


I am sorry but OpenJDK 8 will not be supported at runtime in Buster. If
it works with OpenJDK 11, which it does, then we should spend the
remaining time before the release on more urgent issues.

Markus



signature.asc
Description: OpenPGP digital signature


Bug#897945: #897945 still present/breaks with Java 8

2019-01-29 Thread Emmanuel Bourg
Le 29/01/2019 à 10:40, Per Lundberg a écrit :
> FWIW, version 1.4.2-1 works correctly with openjdk-11-jdk version 
> 11.0.2+7-1, but it _does not_ work correct any more with Java 8 
> (openjdk-8-jdk version 8u191-b12-2)

Thank you for the feedback Per. What issue did you see when using
visualvm with Java 8? You tried running visualvm with Java 8 or you
tried attaching visualvm to a Java 8 VM?

Emmanuel Bourg



Bug#897945: #897945 still present/breaks with Java 8

2019-01-29 Thread Per Lundberg
FWIW, version 1.4.2-1 works correctly with openjdk-11-jdk version 
11.0.2+7-1, but it _does not_ work correct any more with Java 8 
(openjdk-8-jdk version 8u191-b12-2)

This worked correctly with 1.3.9-1 after downgrading the libnb-*-java 
packages as suggested by Ben - visualvm worked fine on Java 8 with this 
combination of packages.

So, we should either:

- Reopen the bug and fix the problem (likely by compiling visualvm with 
openjdk-8, which should make it work on newer JDK versions also)

- Accept the breakage and indicate this somehow, preferably in the 
package metadata. (I don't know if we can use dpkg dependencies in this 
case? It's perfectly legal to have both OpenJDK 11 and 8 _installed_ on 
a machine; it's just that the latter is unusable with visualvm from now on.)

Because the resolution here is not perfectly clear, I will refrain from 
just reopening the bug until it has been discussed a bit more.

Best regards,
--
Per