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

Attachment: signature.asc
Description: PGP signature

Reply via email to