[gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Miroslav Šulc]

hi guys,

we're still far from unmasking java 11 on gentoo, but i hope it will 
happen, one day (or another...). currently there is one issue across the 
whole gentoo tree that is a sure blocker and could and should be easily 
resolved. as java 11 does not compile bytecode older than 1.6, 
everything that specifies in deps virtual/(jdk|jre)-1.[2-5] will fail to 
compile and run. these deps should be lifted up to 
virtual/(jdk|jre)-1.8. also, packages that depend on 
virtual/(jdk|jre)-1.[67] should be lifted up to 1.8 as that is the 
lowest version that we support on gentoo and future versions of java 
might drop support for 1.6 and 1.7 as well, but it's not a blocker for now.

just to get an idea how many ebuilds are affected, here's a short summary:

$ git --no-pager grep -Eho "virtual/(jre|jdk)-1.[2-7]" | sort | uniq -c
       1 virtual/jdk-1.2
       7 virtual/jdk-1.3
      68 virtual/jdk-1.4
     119 virtual/jdk-1.5
     444 virtual/jdk-1.6
     136 virtual/jdk-1.7
       1 virtual/jre-1.2
       7 virtual/jre-1.3
      68 virtual/jre-1.4
     124 virtual/jre-1.5
     460 virtual/jre-1.6
     113 virtual/jre-1.7

here's the list of all packages where java 1.5 or older is used:

$ git --no-pager grep -Elo "virtual/(jre|jdk)-1.[2-5]" | sed -E 
"s%/[^/]+$%%g" | sort | uniq
app-accessibility/brltty
app-accessibility/freetts
app-crypt/jacksum
app-emacs/jde
app-misc/jitac
app-office/hourglass
app-text/hyperestraier
dev-db/db-je
dev-db/hsqldb
dev-db/qdbm
dev-java/ant-contrib
dev-java/ant-owanttask
dev-java/apple-java-extensions-bin
dev-java/apt-mirror
dev-java/aspectj
dev-java/avalon-framework
dev-java/bcel
dev-java/bnd-junit
dev-java/bndlib
dev-java/browserlauncher2
dev-java/bytelist
dev-java/cal10n
dev-java/cdegroot-db
dev-java/cldc-api
dev-java/codemodel
dev-java/commons-el
dev-java/commons-fileupload
dev-java/commons-lang
dev-java/commons-math
dev-java/commons-net
dev-java/commons-pool
dev-java/commons-validator
dev-java/dtdparser
dev-java/easymock-classextension
dev-java/ehcache
dev-java/ezmorph
dev-java/fastinfoset
dev-java/fscript
dev-java/glassfish-persistence
dev-java/gnu-classpath
dev-java/gson
dev-java/hamcrest-integration
dev-java/hawtjni-runtime
dev-java/helpgui
dev-java/higlayout
dev-java/htmlcleaner
dev-java/ical4j
dev-java/jansi
dev-java/jarbundler
dev-java/java-dep-check
dev-java/java-getopt
dev-java/javahelp
dev-java/java-service-wrapper
dev-java/javolution
dev-java/jaxen
dev-java/jbitcollider-core
dev-java/jboss-logmanager
dev-java/jcmdline
dev-java/jcodings
dev-java/jdbc2-stdext
dev-java/jdbm
dev-java/jebl
dev-java/jgoodies-looks
dev-java/jid3
dev-java/jinput
dev-java/jisp
dev-java/jlibeps
dev-java/jnr-ffi
dev-java/jnr-netdb
dev-java/joni
dev-java/jortho
dev-java/jreleaseinfo
dev-java/jstun
dev-java/jta
dev-java/junit-addons
dev-java/junrar
dev-java/jvmstat
dev-java/jvyamlb
dev-java/jzlib
dev-java/j2ssh
dev-java/ldapsdk
dev-java/libg
dev-java/libmatthew-java
dev-java/l2fprod-common
dev-java/miglayout
dev-java/minlog
dev-java/mockito
dev-java/msv
dev-java/nekohtml
dev-java/odfdom
dev-java/osgi-compendium
dev-java/osgi-enterprise-api
dev-java/osgi-foundation
dev-java/pdf-renderer
dev-java/picocontainer
dev-java/prefuse
dev-java/radeox
dev-java/resin-servlet-api
dev-java/sblim-cim-client
dev-java/skinlf
dev-java/slf4j-ext
dev-java/spymemcached
dev-java/squareness-jlf
dev-java/stax-ex
dev-java/stax2-api
dev-java/sun-httpserver-bin
dev-java/sun-jai-bin
dev-java/sun-jimi
dev-java/sun-jms
dev-java/sun-jmx
dev-java/swingx
dev-java/swt
dev-java/tagsoup
dev-java/tapestry
dev-java/validation-api
dev-java/werken-xpath
dev-java/wsdl4j
dev-java/xmlstreambuffer
dev-java/xom
dev-java/zeus-jscl
dev-lang/interprolog
dev-lang/R
dev-lang/xsb
dev-libs/OpenNI
dev-libs/OpenNI2
dev-lisp/abcl
dev-ruby/rjb
dev-tex/tex4ht
dev-util/android-sdk-update-manager
dev-util/jarwizard
dev-util/oprofile
games-board/domination
games-board/megamek
games-puzzle/pauker
java-virtuals/jmx
media-gfx/freewrl
media-gfx/graphviz
media-gfx/povtree
media-libs/libcaca
media-libs/libjpeg-turbo
media-libs/libpano13
media-libs/mlt
media-sound/entagged-tageditor
media-sound/protux
media-tv/channeleditor
media-video/projectx
net-analyzer/munin
net-analyzer/neti
net-dns/libidn
net-libs/NativeThread
net-misc/tigervnc
net-nds/jxplorer
sci-biology/amap
sci-libs/cdf
sci-libs/libsigrok
sci-libs/libsvm
sci-libs/plplot
sci-misc/netlogo-bin
sci-physics/jaxodraw
sci-physics/thepeg
sys-devel/gettext
sys-libs/db

i would like to ask you to revisit your packages where java 1.5 or lower 
is specified and lift the restriction up to 1.8. you might want to do 
the same for 1.7 and 1.8 or just leave it for the time when bumping the 
package. you must do the update in a revbump, as it affects the format 
of java (.jar) files generated and it would not be picked up if done 
in-place and would cause an issue in the future that the existing java 
files would not be supported at the runtime (if not recompiled) due to 
an obsolete format.

the correct ways to specify the deps are those:

in case you want to support java 1.8 and newer
 >=virtual/jdk-1.8:*
 >=virtual/jre-1.8:*

in case the package does not work with java > 1.8 (still, i suggest we 
first try to resolve the issue before we use this restriction as it 
might cause some issues in the future)
virtual/jdk:1.8
virtual/jre:1.8

if, during the update to java 1.8, you come across an issue that you 
would not be able to resolve, you can create a pr at github and assign 
it to me, i will help you resolve that issue.

still, after unmasking java 11, there might be issues with compiling 
those packages with java 11 (one of the cases might be that java 11 does 
not provide some packages that java 8 does which can be resolved by 
adding the missing deps that should be packaged separately, other might 
be related to api changes). i suppose most of you won't want to bother 
with setting up java 11 for compiling your packages and testing and 
resolving that so imo we can for now just resolve the min java version 
and once, when java 11 is unmasked, and should any issues pop up, you 
can cc java team if not sure how to fix the issue and we can help to 
resolve it.

for those that want to try java 11, here's what you need to do to unmask 
java 11 for compilation on your systems:

# grep -r openjdk /etc/portage/*
/etc/portage/package.use/multi:dev-java/openjdk gentoo-vm 
jvm_variant_client source
/etc/portage/package.use/multi:dev-java/openjdk-bin gentoo-vm source
/etc/portage/profile/package.use.mask/multi:dev-java/openjdk:11 -gentoo-vm
/etc/portage/profile/package.use.mask/multi:dev-java/openjdk-bin:11 
-gentoo-vm

in fact, i have this setup for longer than i can remember (over a year 
definitely) and i'm a java dev myself so probably have more java 
packages on my systems than you do, and everything i need is working.


guys, thank you for your attention and have a nice day. should you have 
any questions or need some clarifications, just let me know.


fordfrog

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Miroslav Šulc]

according to flow's question, here's the update to config files without 
the obsolete and irrelevant stuff:

# grep -r openjdk /etc/portage/*
/etc/portage/package.use/multi:dev-java/openjdk gentoo-vm
/etc/portage/package.use/multi:dev-java/openjdk-bin gentoo-vm
/etc/portage/profile/package.use.mask/multi:dev-java/openjdk:11 -gentoo-vm
/etc/portage/profile/package.use.mask/multi:dev-java/openjdk-bin:11 
-gentoo-vm

fordfrog


Dne 14. 04. 21 v 9:45 Miroslav Šulc napsal(a):
> hi guys,
>
> we're still far from unmasking java 11 on gentoo, but i hope it will 
> happen, one day (or another...). currently there is one issue across 
> the whole gentoo tree that is a sure blocker and could and should be 
> easily resolved. as java 11 does not compile bytecode older than 1.6, 
> everything that specifies in deps virtual/(jdk|jre)-1.[2-5] will fail 
> to compile and run. these deps should be lifted up to 
> virtual/(jdk|jre)-1.8. also, packages that depend on 
> virtual/(jdk|jre)-1.[67] should be lifted up to 1.8 as that is the 
> lowest version that we support on gentoo and future versions of java 
> might drop support for 1.6 and 1.7 as well, but it's not a blocker for 
> now.
>
> just to get an idea how many ebuilds are affected, here's a short 
> summary:
>
> $ git --no-pager grep -Eho "virtual/(jre|jdk)-1.[2-7]" | sort | uniq -c
>       1 virtual/jdk-1.2
>       7 virtual/jdk-1.3
>      68 virtual/jdk-1.4
>     119 virtual/jdk-1.5
>     444 virtual/jdk-1.6
>     136 virtual/jdk-1.7
>       1 virtual/jre-1.2
>       7 virtual/jre-1.3
>      68 virtual/jre-1.4
>     124 virtual/jre-1.5
>     460 virtual/jre-1.6
>     113 virtual/jre-1.7
>
> here's the list of all packages where java 1.5 or older is used:
>
> $ git --no-pager grep -Elo "virtual/(jre|jdk)-1.[2-5]" | sed -E 
> "s%/[^/]+$%%g" | sort | uniq
> app-accessibility/brltty
> app-accessibility/freetts
> app-crypt/jacksum
> app-emacs/jde
> app-misc/jitac
> app-office/hourglass
> app-text/hyperestraier
> dev-db/db-je
> dev-db/hsqldb
> dev-db/qdbm
> dev-java/ant-contrib
> dev-java/ant-owanttask
> dev-java/apple-java-extensions-bin
> dev-java/apt-mirror
> dev-java/aspectj
> dev-java/avalon-framework
> dev-java/bcel
> dev-java/bnd-junit
> dev-java/bndlib
> dev-java/browserlauncher2
> dev-java/bytelist
> dev-java/cal10n
> dev-java/cdegroot-db
> dev-java/cldc-api
> dev-java/codemodel
> dev-java/commons-el
> dev-java/commons-fileupload
> dev-java/commons-lang
> dev-java/commons-math
> dev-java/commons-net
> dev-java/commons-pool
> dev-java/commons-validator
> dev-java/dtdparser
> dev-java/easymock-classextension
> dev-java/ehcache
> dev-java/ezmorph
> dev-java/fastinfoset
> dev-java/fscript
> dev-java/glassfish-persistence
> dev-java/gnu-classpath
> dev-java/gson
> dev-java/hamcrest-integration
> dev-java/hawtjni-runtime
> dev-java/helpgui
> dev-java/higlayout
> dev-java/htmlcleaner
> dev-java/ical4j
> dev-java/jansi
> dev-java/jarbundler
> dev-java/java-dep-check
> dev-java/java-getopt
> dev-java/javahelp
> dev-java/java-service-wrapper
> dev-java/javolution
> dev-java/jaxen
> dev-java/jbitcollider-core
> dev-java/jboss-logmanager
> dev-java/jcmdline
> dev-java/jcodings
> dev-java/jdbc2-stdext
> dev-java/jdbm
> dev-java/jebl
> dev-java/jgoodies-looks
> dev-java/jid3
> dev-java/jinput
> dev-java/jisp
> dev-java/jlibeps
> dev-java/jnr-ffi
> dev-java/jnr-netdb
> dev-java/joni
> dev-java/jortho
> dev-java/jreleaseinfo
> dev-java/jstun
> dev-java/jta
> dev-java/junit-addons
> dev-java/junrar
> dev-java/jvmstat
> dev-java/jvyamlb
> dev-java/jzlib
> dev-java/j2ssh
> dev-java/ldapsdk
> dev-java/libg
> dev-java/libmatthew-java
> dev-java/l2fprod-common
> dev-java/miglayout
> dev-java/minlog
> dev-java/mockito
> dev-java/msv
> dev-java/nekohtml
> dev-java/odfdom
> dev-java/osgi-compendium
> dev-java/osgi-enterprise-api
> dev-java/osgi-foundation
> dev-java/pdf-renderer
> dev-java/picocontainer
> dev-java/prefuse
> dev-java/radeox
> dev-java/resin-servlet-api
> dev-java/sblim-cim-client
> dev-java/skinlf
> dev-java/slf4j-ext
> dev-java/spymemcached
> dev-java/squareness-jlf
> dev-java/stax-ex
> dev-java/stax2-api
> dev-java/sun-httpserver-bin
> dev-java/sun-jai-bin
> dev-java/sun-jimi
> dev-java/sun-jms
> dev-java/sun-jmx
> dev-java/swingx
> dev-java/swt
> dev-java/tagsoup
> dev-java/tapestry
> dev-java/validation-api
> dev-java/werken-xpath
> dev-java/wsdl4j
> dev-java/xmlstreambuffer
> dev-java/xom
> dev-java/zeus-jscl
> dev-lang/interprolog
> dev-lang/R
> dev-lang/xsb
> dev-libs/OpenNI
> dev-libs/OpenNI2
> dev-lisp/abcl
> dev-ruby/rjb
> dev-tex/tex4ht
> dev-util/android-sdk-update-manager
> dev-util/jarwizard
> dev-util/oprofile
> games-board/domination
> games-board/megamek
> games-puzzle/pauker
> java-virtuals/jmx
> media-gfx/freewrl
> media-gfx/graphviz
> media-gfx/povtree
> media-libs/libcaca
> media-libs/libjpeg-turbo
> media-libs/libpano13
> media-libs/mlt
> media-sound/entagged-tageditor
> media-sound/protux
> media-tv/channeleditor
> media-video/projectx
> net-analyzer/munin
> net-analyzer/neti
> net-dns/libidn
> net-libs/NativeThread
> net-misc/tigervnc
> net-nds/jxplorer
> sci-biology/amap
> sci-libs/cdf
> sci-libs/libsigrok
> sci-libs/libsvm
> sci-libs/plplot
> sci-misc/netlogo-bin
> sci-physics/jaxodraw
> sci-physics/thepeg
> sys-devel/gettext
> sys-libs/db
>
> i would like to ask you to revisit your packages where java 1.5 or 
> lower is specified and lift the restriction up to 1.8. you might want 
> to do the same for 1.7 and 1.8 or just leave it for the time when 
> bumping the package. you must do the update in a revbump, as it 
> affects the format of java (.jar) files generated and it would not be 
> picked up if done in-place and would cause an issue in the future that 
> the existing java files would not be supported at the runtime (if not 
> recompiled) due to an obsolete format.
>
> the correct ways to specify the deps are those:
>
> in case you want to support java 1.8 and newer
>> =virtual/jdk-1.8:*
>> =virtual/jre-1.8:*
>
> in case the package does not work with java > 1.8 (still, i suggest we 
> first try to resolve the issue before we use this restriction as it 
> might cause some issues in the future)
> virtual/jdk:1.8
> virtual/jre:1.8
>
> if, during the update to java 1.8, you come across an issue that you 
> would not be able to resolve, you can create a pr at github and assign 
> it to me, i will help you resolve that issue.
>
> still, after unmasking java 11, there might be issues with compiling 
> those packages with java 11 (one of the cases might be that java 11 
> does not provide some packages that java 8 does which can be resolved 
> by adding the missing deps that should be packaged separately, other 
> might be related to api changes). i suppose most of you won't want to 
> bother with setting up java 11 for compiling your packages and testing 
> and resolving that so imo we can for now just resolve the min java 
> version and once, when java 11 is unmasked, and should any issues pop 
> up, you can cc java team if not sure how to fix the issue and we can 
> help to resolve it.
>
> for those that want to try java 11, here's what you need to do to 
> unmask java 11 for compilation on your systems:
>
> # grep -r openjdk /etc/portage/*
> /etc/portage/package.use/multi:dev-java/openjdk gentoo-vm 
> jvm_variant_client source
> /etc/portage/package.use/multi:dev-java/openjdk-bin gentoo-vm source
> /etc/portage/profile/package.use.mask/multi:dev-java/openjdk:11 
> -gentoo-vm
> /etc/portage/profile/package.use.mask/multi:dev-java/openjdk-bin:11 
> -gentoo-vm
>
> in fact, i have this setup for longer than i can remember (over a year 
> definitely) and i'm a java dev myself so probably have more java 
> packages on my systems than you do, and everything i need is working.
>
>
> guys, thank you for your attention and have a nice day. should you 
> have any questions or need some clarifications, just let me know.
>
>
> fordfrog
>
>

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Joakim Tjernlund]

On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote:
> 
> in case the package does not work with java > 1.8 (still, i suggest we 
> first try to resolve the issue before we use this restriction as it 
> might cause some issues in the future)
> virtual/jdk:1.8
> virtual/jre:1.8


This does not seem to be enforced by java eclasses. Example dev-java/icedtea-web has
BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system default will
try to build with java-11 and the build will fail.

 Jocke

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Miroslav Šulc]

Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a):
> On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote:
>> in case the package does not work with java > 1.8 (still, i suggest we
>> first try to resolve the issue before we use this restriction as it
>> might cause some issues in the future)
>> virtual/jdk:1.8
>> virtual/jre:1.8
>
> This does not seem to be enforced by java eclasses. Example dev-java/icedtea-web has
> BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system default will
> try to build with java-11 and the build will fail.
not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND. 
regular java apps use classes from jre (java runtime engine) and so they 
must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this 
icedtea-web issue, this should be filed as a bug. thank you for 
mentioning this.
>   Jocke

fordfrog

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Joakim Tjernlund]

On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote:
> Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a):
> > On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote:
> > > in case the package does not work with java > 1.8 (still, i suggest we
> > > first try to resolve the issue before we use this restriction as it
> > > might cause some issues in the future)
> > > virtual/jdk:1.8
> > > virtual/jre:1.8
> > 
> > This does not seem to be enforced by java eclasses. Example dev-java/icedtea-web has
> > BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system default will
> > try to build with java-11 and the build will fail.
> not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND. 
> regular java apps use classes from jre (java runtime engine) and so they 
> must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this 
> icedtea-web issue, this should be filed as a bug. thank you for 
> mentioning this.

Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and changed
RDEPEND to virtual/jdk:1.8 it still fails.


> >   Jocke
> 
> fordfrog
> 
> 

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Miroslav Šulc]

Dne 15. 04. 21 v 17:56 Joakim Tjernlund napsal(a):
> On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote:
>> Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a):
>>> On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote:
>>>> in case the package does not work with java > 1.8 (still, i suggest we
>>>> first try to resolve the issue before we use this restriction as it
>>>> might cause some issues in the future)
>>>> virtual/jdk:1.8
>>>> virtual/jre:1.8
>>> This does not seem to be enforced by java eclasses. Example dev-java/icedtea-web has
>>> BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system default will
>>> try to build with java-11 and the build will fail.
>> not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND.
>> regular java apps use classes from jre (java runtime engine) and so they
>> must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this
>> icedtea-web issue, this should be filed as a bug. thank you for
>> mentioning this.
> Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and changed
> RDEPEND to virtual/jdk:1.8 it still fails.
yes, looking at that icedtea-web ebuild, it inherits none of java 
eclasses so it can't behave as a package that inherits a java eclass. 
gyakovlev would definitely know better. generally, this thread is meant 
for packages that inherit one of java eclasses, and even that is 
oversimplified.
>>>    Jocke

fordfrog

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Joakim Tjernlund]

On Thu, 2021-04-15 at 18:28 +0200, Miroslav Šulc wrote:
> Dne 15. 04. 21 v 17:56 Joakim Tjernlund napsal(a):
> > On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote:
> > > Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a):
> > > > On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote:
> > > > > in case the package does not work with java > 1.8 (still, i suggest we
> > > > > first try to resolve the issue before we use this restriction as it
> > > > > might cause some issues in the future)
> > > > > virtual/jdk:1.8
> > > > > virtual/jre:1.8
> > > > This does not seem to be enforced by java eclasses. Example dev-java/icedtea-web has
> > > > BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system default will
> > > > try to build with java-11 and the build will fail.
> > > not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND.
> > > regular java apps use classes from jre (java runtime engine) and so they
> > > must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this
> > > icedtea-web issue, this should be filed as a bug. thank you for
> > > mentioning this.
> > Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and changed
> > RDEPEND to virtual/jdk:1.8 it still fails.
> yes, looking at that icedtea-web ebuild, it inherits none of java 
> eclasses so it can't behave as a package that inherits a java eclass. 
> gyakovlev would definitely know better. generally, this thread is meant 
> for packages that inherit one of java eclasses, and even that is 
> oversimplified.
> > > 

Yes, I found the error in dev-java/icedtea-web. Q: Should one use JDK_HOME or JAVA_HOME in ebuilds?
However, BDEPEND vs DEPEND is still outstanding. I don't think it is wrong to use BDEPEND here?

Also, RDEPEND does not seem to matter, only BDEPEND

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Joakim Tjernlund]

On Thu, 2021-04-15 at 16:35 +0000, Joakim Tjernlund wrote:
> On Thu, 2021-04-15 at 18:28 +0200, Miroslav Šulc wrote:
> > Dne 15. 04. 21 v 17:56 Joakim Tjernlund napsal(a):
> > > On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote:
> > > > Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a):
> > > > > On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote:
> > > > > > in case the package does not work with java > 1.8 (still, i suggest we
> > > > > > first try to resolve the issue before we use this restriction as it
> > > > > > might cause some issues in the future)
> > > > > > virtual/jdk:1.8
> > > > > > virtual/jre:1.8
> > > > > This does not seem to be enforced by java eclasses. Example dev-java/icedtea-web has
> > > > > BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system default will
> > > > > try to build with java-11 and the build will fail.
> > > > not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND.
> > > > regular java apps use classes from jre (java runtime engine) and so they
> > > > must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this
> > > > icedtea-web issue, this should be filed as a bug. thank you for
> > > > mentioning this.
> > > Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and changed
> > > RDEPEND to virtual/jdk:1.8 it still fails.
> > yes, looking at that icedtea-web ebuild, it inherits none of java 
> > eclasses so it can't behave as a package that inherits a java eclass. 
> > gyakovlev would definitely know better. generally, this thread is meant 
> > for packages that inherit one of java eclasses, and even that is 
> > oversimplified.
> > > > 
> 
> Yes, I found the error in dev-java/icedtea-web. Q: Should one use JDK_HOME or JAVA_HOME in ebuilds?
> However, BDEPEND vs DEPEND is still outstanding. I don't think it is wrong to use BDEPEND here?
> 
> Also, RDEPEND does not seem to matter, only BDEPEND

Filed bug https://bugs.gentoo.org/783027 with a small patch, in case you want to comment.

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Miroslav Šulc]

Dne 15. 04. 21 v 18:35 Joakim Tjernlund napsal(a):
> Yes, I found the error in dev-java/icedtea-web. Q: Should one use 
> JDK_HOME or JAVA_HOME in ebuilds? 

i guess it doesn't matter (at least for packages that inherit 
java-utils-2.eclass):

https://github.com/gentoo/gentoo/blob/master/eclass/java-utils-2.eclass#L2711

> However, BDEPEND vs DEPEND is still outstanding. I don't think it is wrong to use BDEPEND here?
>
> Also, RDEPEND does not seem to matter, only BDEPEND

this thread is about packages inheriting a java eclass, which 
icedtea-web isn't, so it works in a different way. i never touched that 
package so cannot give you more details, but you can join us at 
#gentoo-java@freenode.net and address gyakovlev there.

fordfrog

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Kaibo Ma]

[-- Attachment #1: Type: text/plain, Size: 7837 bytes --]

Is there a tracking issue for Java 11 on Bugzilla?

Kaibo Ma

On Wed, 14 Apr 2021 at 15:45, Miroslav Šulc <fordfrog@gentoo.org> wrote:

> hi guys,
>
> we're still far from unmasking java 11 on gentoo, but i hope it will
> happen, one day (or another...). currently there is one issue across the
> whole gentoo tree that is a sure blocker and could and should be easily
> resolved. as java 11 does not compile bytecode older than 1.6,
> everything that specifies in deps virtual/(jdk|jre)-1.[2-5] will fail to
> compile and run. these deps should be lifted up to
> virtual/(jdk|jre)-1.8. also, packages that depend on
> virtual/(jdk|jre)-1.[67] should be lifted up to 1.8 as that is the
> lowest version that we support on gentoo and future versions of java
> might drop support for 1.6 and 1.7 as well, but it's not a blocker for now.
>
> just to get an idea how many ebuilds are affected, here's a short summary:
>
> $ git --no-pager grep -Eho "virtual/(jre|jdk)-1.[2-7]" | sort | uniq -c
>        1 virtual/jdk-1.2
>        7 virtual/jdk-1.3
>       68 virtual/jdk-1.4
>      119 virtual/jdk-1.5
>      444 virtual/jdk-1.6
>      136 virtual/jdk-1.7
>        1 virtual/jre-1.2
>        7 virtual/jre-1.3
>       68 virtual/jre-1.4
>      124 virtual/jre-1.5
>      460 virtual/jre-1.6
>      113 virtual/jre-1.7
>
> here's the list of all packages where java 1.5 or older is used:
>
> $ git --no-pager grep -Elo "virtual/(jre|jdk)-1.[2-5]" | sed -E
> "s%/[^/]+$%%g" | sort | uniq
> app-accessibility/brltty
> app-accessibility/freetts
> app-crypt/jacksum
> app-emacs/jde
> app-misc/jitac
> app-office/hourglass
> app-text/hyperestraier
> dev-db/db-je
> dev-db/hsqldb
> dev-db/qdbm
> dev-java/ant-contrib
> dev-java/ant-owanttask
> dev-java/apple-java-extensions-bin
> dev-java/apt-mirror
> dev-java/aspectj
> dev-java/avalon-framework
> dev-java/bcel
> dev-java/bnd-junit
> dev-java/bndlib
> dev-java/browserlauncher2
> dev-java/bytelist
> dev-java/cal10n
> dev-java/cdegroot-db
> dev-java/cldc-api
> dev-java/codemodel
> dev-java/commons-el
> dev-java/commons-fileupload
> dev-java/commons-lang
> dev-java/commons-math
> dev-java/commons-net
> dev-java/commons-pool
> dev-java/commons-validator
> dev-java/dtdparser
> dev-java/easymock-classextension
> dev-java/ehcache
> dev-java/ezmorph
> dev-java/fastinfoset
> dev-java/fscript
> dev-java/glassfish-persistence
> dev-java/gnu-classpath
> dev-java/gson
> dev-java/hamcrest-integration
> dev-java/hawtjni-runtime
> dev-java/helpgui
> dev-java/higlayout
> dev-java/htmlcleaner
> dev-java/ical4j
> dev-java/jansi
> dev-java/jarbundler
> dev-java/java-dep-check
> dev-java/java-getopt
> dev-java/javahelp
> dev-java/java-service-wrapper
> dev-java/javolution
> dev-java/jaxen
> dev-java/jbitcollider-core
> dev-java/jboss-logmanager
> dev-java/jcmdline
> dev-java/jcodings
> dev-java/jdbc2-stdext
> dev-java/jdbm
> dev-java/jebl
> dev-java/jgoodies-looks
> dev-java/jid3
> dev-java/jinput
> dev-java/jisp
> dev-java/jlibeps
> dev-java/jnr-ffi
> dev-java/jnr-netdb
> dev-java/joni
> dev-java/jortho
> dev-java/jreleaseinfo
> dev-java/jstun
> dev-java/jta
> dev-java/junit-addons
> dev-java/junrar
> dev-java/jvmstat
> dev-java/jvyamlb
> dev-java/jzlib
> dev-java/j2ssh
> dev-java/ldapsdk
> dev-java/libg
> dev-java/libmatthew-java
> dev-java/l2fprod-common
> dev-java/miglayout
> dev-java/minlog
> dev-java/mockito
> dev-java/msv
> dev-java/nekohtml
> dev-java/odfdom
> dev-java/osgi-compendium
> dev-java/osgi-enterprise-api
> dev-java/osgi-foundation
> dev-java/pdf-renderer
> dev-java/picocontainer
> dev-java/prefuse
> dev-java/radeox
> dev-java/resin-servlet-api
> dev-java/sblim-cim-client
> dev-java/skinlf
> dev-java/slf4j-ext
> dev-java/spymemcached
> dev-java/squareness-jlf
> dev-java/stax-ex
> dev-java/stax2-api
> dev-java/sun-httpserver-bin
> dev-java/sun-jai-bin
> dev-java/sun-jimi
> dev-java/sun-jms
> dev-java/sun-jmx
> dev-java/swingx
> dev-java/swt
> dev-java/tagsoup
> dev-java/tapestry
> dev-java/validation-api
> dev-java/werken-xpath
> dev-java/wsdl4j
> dev-java/xmlstreambuffer
> dev-java/xom
> dev-java/zeus-jscl
> dev-lang/interprolog
> dev-lang/R
> dev-lang/xsb
> dev-libs/OpenNI
> dev-libs/OpenNI2
> dev-lisp/abcl
> dev-ruby/rjb
> dev-tex/tex4ht
> dev-util/android-sdk-update-manager
> dev-util/jarwizard
> dev-util/oprofile
> games-board/domination
> games-board/megamek
> games-puzzle/pauker
> java-virtuals/jmx
> media-gfx/freewrl
> media-gfx/graphviz
> media-gfx/povtree
> media-libs/libcaca
> media-libs/libjpeg-turbo
> media-libs/libpano13
> media-libs/mlt
> media-sound/entagged-tageditor
> media-sound/protux
> media-tv/channeleditor
> media-video/projectx
> net-analyzer/munin
> net-analyzer/neti
> net-dns/libidn
> net-libs/NativeThread
> net-misc/tigervnc
> net-nds/jxplorer
> sci-biology/amap
> sci-libs/cdf
> sci-libs/libsigrok
> sci-libs/libsvm
> sci-libs/plplot
> sci-misc/netlogo-bin
> sci-physics/jaxodraw
> sci-physics/thepeg
> sys-devel/gettext
> sys-libs/db
>
> i would like to ask you to revisit your packages where java 1.5 or lower
> is specified and lift the restriction up to 1.8. you might want to do
> the same for 1.7 and 1.8 or just leave it for the time when bumping the
> package. you must do the update in a revbump, as it affects the format
> of java (.jar) files generated and it would not be picked up if done
> in-place and would cause an issue in the future that the existing java
> files would not be supported at the runtime (if not recompiled) due to
> an obsolete format.
>
> the correct ways to specify the deps are those:
>
> in case you want to support java 1.8 and newer
>  >=virtual/jdk-1.8:*
>  >=virtual/jre-1.8:*
>
> in case the package does not work with java > 1.8 (still, i suggest we
> first try to resolve the issue before we use this restriction as it
> might cause some issues in the future)
> virtual/jdk:1.8
> virtual/jre:1.8
>
> if, during the update to java 1.8, you come across an issue that you
> would not be able to resolve, you can create a pr at github and assign
> it to me, i will help you resolve that issue.
>
> still, after unmasking java 11, there might be issues with compiling
> those packages with java 11 (one of the cases might be that java 11 does
> not provide some packages that java 8 does which can be resolved by
> adding the missing deps that should be packaged separately, other might
> be related to api changes). i suppose most of you won't want to bother
> with setting up java 11 for compiling your packages and testing and
> resolving that so imo we can for now just resolve the min java version
> and once, when java 11 is unmasked, and should any issues pop up, you
> can cc java team if not sure how to fix the issue and we can help to
> resolve it.
>
> for those that want to try java 11, here's what you need to do to unmask
> java 11 for compilation on your systems:
>
> # grep -r openjdk /etc/portage/*
> /etc/portage/package.use/multi:dev-java/openjdk gentoo-vm
> jvm_variant_client source
> /etc/portage/package.use/multi:dev-java/openjdk-bin gentoo-vm source
> /etc/portage/profile/package.use.mask/multi:dev-java/openjdk:11 -gentoo-vm
> /etc/portage/profile/package.use.mask/multi:dev-java/openjdk-bin:11
> -gentoo-vm
>
> in fact, i have this setup for longer than i can remember (over a year
> definitely) and i'm a java dev myself so probably have more java
> packages on my systems than you do, and everything i need is working.
>
>
> guys, thank you for your attention and have a nice day. should you have
> any questions or need some clarifications, just let me know.
>
>
> fordfrog
>
>
>

[-- Attachment #2: Type: text/html, Size: 8860 bytes --]

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Miroslav Šulc]

Dne 22. 04. 21 v 8:37 Kaibo Ma napsal(a):
> Is there a tracking issue for Java 11 on Bugzilla?
>
> Kaibo Ma

this is it: https://bugs.gentoo.org/697014

fordfrog

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Georgy Yakovlev]

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

On 22.04.2021 10:22, Miroslav Šulc wrote:
> Dne 22. 04. 21 v 8:37 Kaibo Ma napsal(a):
> > Is there a tracking issue for Java 11 on Bugzilla?
> > 
> > Kaibo Ma
> 
> this is it: https://bugs.gentoo.org/697014

created an alias for it, also can be found as

https://bugs.gentoo.org/show_bug.cgi?id=jdk11

and simply searching for jdk11 in the search field
> 
> fordfrog
> 
> 
> 

-- 
Best regards,
Georgy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 902 bytes --]