Bug#813041: icedtea-netx should not depend on default-jre

[tony mancill]

On Sat, Nov 23, 2019 at 12:58:52AM +0100, Marco Gamberoni wrote:
> icedtea-netx can be used with any JRE.
> Java Network Launch Programs (jnlp) declare a specific version of JRE in the jnlp file, and often misbehave if another version is used.
> javaws prints a warning on stdout if the chosen JRE is not the one declared in the jnlp file, but it easy to miss it.
> 
> In my case, I use a jnlp application once a year for tax filings, supplied by Italian tax authority Agenzia delle Entrate, via jnlp technology. It works correctly only with openjdk-8-jre, and being provisioned via jnlp, needs javaws from icedtea-netx.
> So, due to icedtea-netx dependency on default-jre I end up with 2 JRE installed: 8 and (currently) 11.
> The default JRE ends up being 11, so I have to configure icedea-netx to use the 8, and cannot remove 11.
> This is too much hassle and bloat to pay taxes :o)
> 
> I would like to see this wishlist bug closed this way:
>  -  icedtea-web should depend on java-runtime, and suggest default-jre
>  -  openjdk-8-jre should provide java-runtime (it provides only versioned ones: java2-runtime, java5-runtime, java6-runtime, java7-runtime, java8-runtime)
> This would make it easy to have only openjdk-8-jre and icedtea-netx installed, without defaul-jre and its dependencies.
> As things stand, one must resort to other more complex options, like equivs to circumvent package dependencies, or simply tolerate the bloat.
> 
> Regards
> 
> Marco Gamberoni

Hello Marco,

I agree about the hard dependency on default-jre.  That's the reason
that the javaX-runtime virtual dependencies were created.  However, I'm
not sure about creating a new java-runtime dependency, since I think
that we're going to continue to have situations where we have to
differentiate between JRE runtimes.

Since the default-jre going back to oldstable provides java8-runtime,
would it be okay to have icedtea-web depend on java8-runtime, which can
be satisfied by default-jre for stretch and anything later?  This should
simplify your use case and continue to work until there is a default-jre
that is for some reason unable to run older byte code.

Cheers,
tony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20191123/8b936aa1/attachment.sig>