openjdk-8-native: add meaningful (R)PROVIDES
RFC PATCH 1/7 openjdk-8-native: add meaningful (R)PROVIDES
From: André Draszik <[email protected]>
The OpenJDK8-native recipe provides a Java SDK, and a Java Runtime. It is compatible with Java versions 5 through 8 (including), so add appropriate (R)PROVIDES, so that recipes depending on it can can specify that virtual dependency, rather than hard-coding to openjdk-8. This makes it possible to:
a) add OpenJDK9 and OpenJDK10 recipes in the future without much disruption
b) use a different provider than OpenJDK, e.g. Oracle Java, or Zulu Java
This is the approach taken by e.g. Debian.
--- recipes-core/openjdk/openjdk-8-native.inc | 3 +++ 1 file changed, 3 insertions(+)
recipes-core/openjdk/openjdk-8-native.inc +3 -0
@@ -87,3 +87,6 @@ do_install() { ln -sf "../lib/jvm/${JDK_DIR}/bin/$tool" ${D}${bindir}/$tool done } + +PROVIDES = "${@' '.join('virtual/java'+str(x)+'-sdk-native virtual/java'+str(x)+'-runtime-native' for x in range(5,9))}" +RPROVIDES_${PN} = "${@' '.join('virtual-java'+str(x)+'-sdk-native virtual-java'+str(x)+'-runtime-native' for x in range(5,9))}"
Signature · 1 line
2.18.0
RFC PATCH 2/7 layer.conf: allow multiple Java SDKs & runtimes to co-exist
From: André Draszik <[email protected]>
Using MULTI_PROVIDER_WHITELIST, we can instruct Bitbake to not complain if multiple recipes provide or runtime provide the same Java environment.
This is a common use-case, and Java packages don't conflict with each other as they are typically installed under a different prefix, while still providing (more or less) the same features.
--- conf/layer.conf | 3 +++ 1 file changed, 3 insertions(+)
conf/layer.conf +3 -0
@@ -14,3 +14,6 @@ LICENSE_PATH += "${LAYERDIR}/licenses" SIGGEN_EXCLUDERECIPES_ABISAFE += "\ ca-certificates-java \ " + +MULTI_PROVIDER_WHITELIST_append = " ${@' '.join('virtual/java'+str(x)+'-sdk-native virtual/java'+str(x)+'-runtime-native' for x in range(5,9))}" +MULTI_PROVIDER_WHITELIST_append = " ${@' '.join('virtual/java'+str(x)+'-runtime' for x in range(5,9))}"
Signature · 1 line
2.18.0
Re: [meta-java][RFC][PATCH 2/7] layer.conf: allow multiple Java SDKs & runtimes to co-exist
Hi André,
again: thank you and feel free to add
regards;Richard.L
Quoted 26 lines · André Draszik
From: André Draszik <[email protected]>
Using
MULTI_PROVIDER_WHITELIST, we can instruct Bitbake to not complain if multiple recipes provide or runtime provide the same Java environment.This is a common use-case, and Java packages don't conflict with each other as they are typically installed under a different prefix, while still providing (more or less) the same features.
Signed-off-by André Draszik <[email protected]>--- conf/layer.conf | 3 +++ 1 file changed, 3 insertions(+)conf/layer.conf +3
-0@@ -14,3 +14,6 @@ LICENSE_PATH += "${LAYERDIR}/licenses" SIGGEN_EXCLUDERECIPES_ABISAFE += "\ ca-certificates-java \ " + +MULTI_PROVIDER_WHITELIST_append = " ${@' '.join('virtual/java'+str(x)+'-sdk-native virtual/java'+str(x)+'-runtime-native' for x in range(5,9))}" +MULTI_PROVIDER_WHITELIST_append = " ${@' '.join('virtual/java'+str(x)+'-runtime' for x in range(5,9))}"
RFC PATCH 3/7 openjdk-8: add meaningful (R)PROVIDES
In reply to André DraszikFrom: André Draszik <[email protected]>
Then OpenJDK8 recipe provides a Java SDK, and a Java Runtime. It is compatible with Java versions 5 through 8 (including), so add appropriate (R)PROVIDES, so that recipes depending on it can can specify that virtual dependency, rather than hard-coding to openjdk-8. This makes it possible to:
a) add OpenJDK9 and OpenJDK10 recipes in the future without much disruption
b) use a different provider than OpenJDK, e.g. Oracle Java, or Zulu Java
This is the approach taken by e.g. Debian.
--- recipes-core/openjdk/openjdk-8_172b11.bb | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
recipes-core/openjdk/openjdk-8_172b11.bb +4 -4
@@ -45,10 +45,10 @@ FILES_${PN}-doc_append = "\ FILES_${PN}-source = " ${JDK_HOME}/src.zip " -RPROVIDES_${PN} = "java2-vm" -PROVIDES_${PN} = "java2-vm" -RPROVIDES_${PN} = "java2-runtime" -PROVIDES_${PN} = "java2-runtime" +PROVIDES = "java2-vm java2-runtime" +PROVIDES += "${@' '.join('virtual/java'+str(x)+'-sdk virtual/java'+str(x)+'-runtime' for x in range(5,9))}" +RPROVIDES_${PN} = "java2-vm java2-runtime" +RPROVIDES_${PN} += "${@' '.join('virtual-java'+str(x)+'-sdk virtual-java'+str(x)+'-runtime' for x in range(5,9))}" inherit update-alternatives
Signature · 1 line
2.18.0
Re: [meta-java][RFC][PATCH 3/7] openjdk-8: add meaningful (R)PROVIDES
Hi André,
again: thank you and feel free to add
regards;Richard.L
Quoted 37 lines · André Draszik
From: André Draszik <[email protected]>
Then OpenJDK8 recipe provides a Java SDK, and a Java Runtime. It is compatible with Java versions 5 through 8 (including), so add appropriate (R)PROVIDES, so that recipes depending on it can can specify that virtual dependency, rather than hard-coding to openjdk-8. This makes it possible to:
a) add OpenJDK9 and OpenJDK10 recipes in the future without much disruption
b) use a different provider than OpenJDK, e.g. Oracle Java, or Zulu JavaThis is the approach taken by e.g. Debian.
Signed-off-by André Draszik <[email protected]>--- recipes-core/openjdk/openjdk-8_172b11.bb | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)recipes-core/openjdk/openjdk-8_172b11.bb +4
-4@@ -45,10 +45,10 @@ FILES_${PN}-doc_append = "\ FILES_${PN}-source = " ${JDK_HOME}/src.zip " -RPROVIDES_${PN} = "java2-vm" -PROVIDES_${PN} = "java2-vm" -RPROVIDES_${PN} = "java2-runtime" -PROVIDES_${PN} = "java2-runtime" +PROVIDES = "java2-vm java2-runtime" +PROVIDES += "${@' '.join('virtual/java'+str(x)+'-sdk virtual/java'+str(x)+'-runtime' for x in range(5,9))}" +RPROVIDES_${PN} = "java2-vm java2-runtime" +RPROVIDES_${PN} += "${@' '.join('virtual-java'+str(x)+'-sdk virtual-java'+str(x)+'-runtime' for x in range(5,9))}" inherit update-alternatives
RFC PATCH 4/7 openjre-8: add meaningful (R)PROVIDES
In reply to André DraszikFrom: André Draszik <[email protected]>
Then OpenJRE8 recipe provides a Java Runtime. It
is compatible with Java versions 5 through 8 (including), so add appropriate (R)PROVIDES, so that recipes depending on it can can specify that virtual dependency, rather than hard-coding to openjre-8. This makes it possible to:
a) add OpenJRE9 and OpenJRE10 recipes in the future without much disruption
b) use a different provider than OpenJDK, e.g. Oracle Java, or Zulu Java
This is the approach taken by e.g. Debian.
--- recipes-core/openjdk/openjre-8_172b11.bb | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
recipes-core/openjdk/openjre-8_172b11.bb +4 -4
@@ -33,10 +33,10 @@ FILES_${PN}-doc_append = "\ ${JRE_HOME}/THIRD_PARTY_README \ " -RPROVIDES_${PN} = "java2-vm" -PROVIDES_${PN} = "java2-vm" -RPROVIDES_${PN} = "java2-runtime" -PROVIDES_${PN} = "java2-runtime" +PROVIDES = "java2-vm java2-runtime" +PROVIDES += "${@' '.join('virtual/java'+str(x)+'-runtime' for x in range(5,9))}" +RPROVIDES_${PN} = "java2-vm java2-runtime" +RPROVIDES_${PN} += "${@' '.join('virtual-java'+str(x)+'-runtime' for x in range(5,9))}" inherit update-alternatives
Signature · 1 line
2.18.0
Re: [meta-java][RFC][PATCH 4/7] openjre-8: add meaningful (R)PROVIDES
Hi André,
again: thank you and feel free to add
regards;Richard.L
Quoted 37 lines · André Draszik
From: André Draszik <[email protected]>
Then OpenJRE8 recipe provides a Java Runtime. It
is compatible with Java versions 5 through 8 (including), so add appropriate (R)PROVIDES, so that recipes depending on it can can specify that virtual dependency, rather than hard-coding to openjre-8. This makes it possible to:
a) add OpenJRE9 and OpenJRE10 recipes in the future without much disruption
b) use a different provider than OpenJDK, e.g. Oracle Java, or Zulu JavaThis is the approach taken by e.g. Debian.
Signed-off-by André Draszik <[email protected]>--- recipes-core/openjdk/openjre-8_172b11.bb | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)recipes-core/openjdk/openjre-8_172b11.bb +4
-4@@ -33,10 +33,10 @@ FILES_${PN}-doc_append = "\ ${JRE_HOME}/THIRD_PARTY_README \ " -RPROVIDES_${PN} = "java2-vm" -PROVIDES_${PN} = "java2-vm" -RPROVIDES_${PN} = "java2-runtime" -PROVIDES_${PN} = "java2-runtime" +PROVIDES = "java2-vm java2-runtime" +PROVIDES += "${@' '.join('virtual/java'+str(x)+'-runtime' for x in range(5,9))}" +RPROVIDES_${PN} = "java2-vm java2-runtime" +RPROVIDES_${PN} += "${@' '.join('virtual-java'+str(x)+'-runtime' for x in range(5,9))}" inherit update-alternatives
RFC PATCH 5/7 layer.conf: set defaults for Java JRE (R)PROVIDERS
In reply to André DraszikFrom: André Draszik <[email protected]>
OpenJRE-8 seems like a good choice.
--- conf/layer.conf | 9 +++++++++ 1 file changed, 9 insertions(+)
conf/layer.conf +9 -0
@@ -17,3 +17,12 @@ SIGGEN_EXCLUDERECIPES_ABISAFE += "\ MULTI_PROVIDER_WHITELIST_append = " ${@' '.join('virtual/java'+str(x)+'-sdk-native virtual/java'+str(x)+'-runtime-native' for x in range(5,9))}" MULTI_PROVIDER_WHITELIST_append = " ${@' '.join('virtual/java'+str(x)+'-runtime' for x in range(5,9))}" + +PREFERRED_PROVIDER_virtual/java5-runtime ?= "openjre-8" +PREFERRED_PROVIDER_virtual/java6-runtime ?= "openjre-8" +PREFERRED_PROVIDER_virtual/java7-runtime ?= "openjre-8" +PREFERRED_PROVIDER_virtual/java8-runtime ?= "openjre-8" +PREFERRED_RPROVIDER_virtual-java5-runtime ?= "openjre-8" +PREFERRED_RPROVIDER_virtual-java6-runtime ?= "openjre-8" +PREFERRED_RPROVIDER_virtual-java7-runtime ?= "openjre-8" +PREFERRED_RPROVIDER_virtual-java8-runtime ?= "openjre-8"
Signature · 1 line
2.18.0
Re: [meta-java][RFC][PATCH 5/7] layer.conf: set defaults for Java JRE (R)PROVIDERS
Hi André,
Quoted 3 lines · André Draszik
From: André Draszik <[email protected]>
OpenJRE-8 seems like a good choice.
I'm not sure if OpenJRE-8 is the best choice as it currently doesn't support JIT for arm architectures...
Maybe openjdk-7-jre would be better here?
Furthermore as already mentioned in PATCH 1 IMHO it would be great to describe/document those PROVIDERs in the README. This would help newcomers a lot.
Quoted 14 lines
Signed-off-by André Draszik <[email protected]>--- conf/layer.conf | 9 +++++++++ 1 file changed, 9 insertions(+)conf/layer.conf +0
-0@@ -17,3 +17,12 @@ SIGGEN_EXCLUDERECIPES_ABISAFE += "\ MULTI_PROVIDER_WHITELIST_append = " ${@' '.join('virtual/java'+str(x)+'-sdk-native virtual/java'+str(x)+'-runtime-native' for x in range(5,9))}"
conf/layer.conf SIGGEN_EXCLUDERECIPES_ABISAFE += "\ · line 28
Quoted 10 lines
conf/layer.conf +9
-0MULTI_PROVIDER_WHITELIST_append = " ${@' '.join('virtual/java'+str(x)+'-runtime' for x in range(5,9))}" + +PREFERRED_PROVIDER_virtual/java5-runtime ?= "openjre-8" +PREFERRED_PROVIDER_virtual/java6-runtime ?= "openjre-8" +PREFERRED_PROVIDER_virtual/java7-runtime ?= "openjre-8" +PREFERRED_PROVIDER_virtual/java8-runtime ?= "openjre-8" +PREFERRED_RPROVIDER_virtual-java5-runtime ?= "openjre-8" +PREFERRED_RPROVIDER_virtual-java6-runtime ?= "openjre-8" +PREFERRED_RPROVIDER_virtual-java7-runtime ?= "openjre-8" +PREFERRED_RPROVIDER_virtual-java8-runtime ?= "openjre-8"
regards;Richard.L
Re: [meta-java][RFC][PATCH 5/7] layer.conf: set defaults for Java JRE (R)PROVIDERS
Quoted 10 lines · Richard Leitner
Hi André,
Quoted 3 lines · André Draszik
From: André Draszik <[email protected]>
OpenJRE-8 seems like a good choice.
I'm not sure if OpenJRE-8 is the best choice as it currently doesn't support JIT for
arm architectures...
Oh, thanks. I didn't realise that...
Anybody know why? Just nobody interested enough so far to integrate the aarch32 hotspot port into meta-java?
Cheers,
Andre'
RFC PATCH 6/7 openjdk-7: (R)PROVIDE virtual Java [567] packages
In reply to André DraszikFrom: André Draszik <[email protected]>
Similar to OpenJDK-8, OpenJDK-7 is a provider of Java 5 through 7 (including).
--- recipes-core/openjdk/openjdk-7-common.inc | 2 ++ 1 file changed, 2 insertions(+)
recipes-core/openjdk/openjdk-7-common.inc +2 -0
@@ -22,6 +22,7 @@ JDK_DIR = "java-7-openjdk" PN = "${JDKPN}-jre" PROVIDES += "${JDKPN}" +PROVIDES += "${@' '.join('virtual/java'+str(x)+'-sdk virtual/java'+str(x)+'-runtime' for x in range(5,8))}" DEPENDS = " \ icedtea7-native zip-native ant-native \
@@ -283,6 +284,7 @@ FILES_${JDKPN}-jdk = " \ RDEPENDS_${JDKPN}-jre = "${JDKPN}-java ${JDKPN}-common" RDEPENDS_${JDKPN}-java = "${JDKPN}-common" RPROVIDES_${JDKPN}-jre = "java2-runtime" +RPROVIDES_${JDKPN}-jre += "${@' '.join('virtual-java'+str(x)+'-runtime' for x in range(5,8))}" RDEPENDS_${JDKPN}-jdk = "${JDKPN}-jre"
Signature · 1 line
2.18.0
Re: [meta-java][RFC][PATCH 6/7] openjdk-7: (R)PROVIDE virtual Java [567] packages
Hi André,
again: thank you and feel free to add
regards;Richard.L
Quoted 31 lines · André Draszik
From: André Draszik <[email protected]>
Similar to OpenJDK-8, OpenJDK-7 is a provider of Java 5 through 7 (including).
Signed-off-by André Draszik <[email protected]>--- recipes-core/openjdk/openjdk-7-common.inc | 2 ++ 1 file changed, 2 insertions(+)recipes-core/openjdk/openjdk-7-common.inc +2
-0@@ -22,6 +22,7 @@ JDK_DIR = "java-7-openjdk" PN = "${JDKPN}-jre" PROVIDES += "${JDKPN}" +PROVIDES += "${@' '.join('virtual/java'+str(x)+'-sdk virtual/java'+str(x)+'-runtime' for x in range(5,8))}" DEPENDS = " \ icedtea7-native zip-native ant-native \@@ -283,6 +284,7 @@ FILES_${JDKPN}-jdk = " \ RDEPENDS_${JDKPN}-jre = "${JDKPN}-java ${JDKPN}-common" RDEPENDS_${JDKPN}-java = "${JDKPN}-common" RPROVIDES_${JDKPN}-jre = "java2-runtime" +RPROVIDES_${JDKPN}-jre += "${@' '.join('virtual-java'+str(x)+'-runtime' for x in range(5,8))}" RDEPENDS_${JDKPN}-jdk = "${JDKPN}-jre"
RFC PATCH 7/7 ca-certificates-java: switch to more generic / more correct JAVA (R)DEPENDS
In reply to André DraszikFrom: André Draszik <[email protected]>
This recipe here actually depends on Java7 upwards, not Java2 upwards, so state that dependency correctly using the newly introduced (virtual) RPROVIDES of the OpenJDK8/OpenJRE8 recipes.
At the same time, we can remove hard-coded references to openjdk-8 and openjre-8, and thusly make the build more flexible.
--- .../ca-certificates-java_20180516.bb | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)
recipes-core/ca-certificates-java/ca-certificates-java_20180516.bb +2 -8
@@ -14,7 +14,7 @@ DEPENDS = "virtual/javac-native fastjar-native" # We can't use virtual/javac-native, because that would create a # keystore that can't be read on the target (as virtual/javac-native # usually is either too old, or plain incompatible with this) -PACKAGE_WRITE_DEPS += "openjdk-8-native" +PACKAGE_WRITE_DEPS += "virtual/java7-runtime-native" SRC_URI = "\ git://salsa.debian.org/java-team/ca-certificates-java.git \
@@ -31,12 +31,6 @@ B = "${WORKDIR}/build" JARFILENAME = "${BPN}.jar" -python () { - runtime = d.getVar("PREFERRED_RPROVIDER_java2-runtime") or "" - if not runtime in ("openjdk-8", "openjre-8"): - raise bb.parse.SkipRecipe("PREFERRED_RPROVIDER_java2-runtime '%s' unsupported" % runtime) -} - do_patch_append () { bb.build.exec_func('do_fix_sysconfdir', d) }
@@ -99,7 +93,7 @@ pkg_postinst_${PN} () { } RDEPENDS_${PN} = "ca-certificates" -RDEPENDS_${PN}_append_class-target = " java2-runtime" +RDEPENDS_${PN}_append_class-target = " virtual-java7-runtime" FILES_${PN} += "${datadir_java}"
Signature · 1 line
2.18.0
Re: [meta-java][RFC][PATCH 7/7] ca-certificates-java: switch to more generic / more correct JAVA (R)DEPENDS
Hi André,
again: thank you and feel free to add
regards;Richard.L
Quoted 50 lines · André Draszik
From: André Draszik <[email protected]>
This recipe here actually depends on Java7 upwards, not Java2 upwards, so state that dependency correctly using the newly introduced (virtual) RPROVIDES of the OpenJDK8/OpenJRE8 recipes.
At the same time, we can remove hard-coded references to openjdk-8 and openjre-8, and thusly make the build more flexible.
Signed-off-by André Draszik <[email protected]>--- .../ca-certificates-java_20180516.bb | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)recipes-core/ca-certificates-java/ca-certificates-java_20180516.bb +2
-8@@ -14,7 +14,7 @@ DEPENDS = "virtual/javac-native fastjar-native" # We can't use virtual/javac-native, because that would create a # keystore that can't be read on the target (as virtual/javac-native # usually is either too old, or plain incompatible with this) -PACKAGE_WRITE_DEPS += "openjdk-8-native" +PACKAGE_WRITE_DEPS += "virtual/java7-runtime-native" SRC_URI = "\ git://salsa.debian.org/java-team/ca-certificates-java.git \@@ -31,12 +31,6 @@ B = "${WORKDIR}/build" JARFILENAME = "${BPN}.jar" -python () { - runtime = d.getVar("PREFERRED_RPROVIDER_java2-runtime") or "" - if not runtime in ("openjdk-8", "openjre-8"): - raise bb.parse.SkipRecipe("PREFERRED_RPROVIDER_java2-runtime '%s' unsupported" % runtime) -} - do_patch_append () { bb.build.exec_func('do_fix_sysconfdir', d) }@@ -99,7 +93,7 @@ pkg_postinst_${PN} () { } RDEPENDS_${PN} = "ca-certificates" -RDEPENDS_${PN}_append_class-target = " java2-runtime" +RDEPENDS_${PN}_append_class-target = " virtual-java7-runtime" FILES_${PN} += "${datadir_java}"
Re: [meta-java][RFC][PATCH 7/7] ca-certificates-java: switch to more generic / more correct JAVA (R)DEPENDS
In reply to André DraszikQuoted 21 lines · André Draszik
From: André Draszik <[email protected]>
This recipe here actually depends on Java7 upwards, not Java2 upwards, so state that dependency correctly using the newly introduced (virtual) RPROVIDES of the OpenJDK8/OpenJRE8 recipes.
At the same time, we can remove hard-coded references to openjdk-8 and openjre-8, and thusly make the build more flexible.
Signed-off-by André Draszik <[email protected]>--- .../ca-certificates-java_20180516.bb | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)(quoted diff) +0
-0ca-certificates-java_20180516.bb b/recipes-core/ca-certificates-java/ ca-certificates-java_20180516.bb
index a2d7abd..2ae7352 100644
recipes-core/ca-certificates-java/ca-certificates-java_20180516.bb DEPENDS = "virtual/javac-native fastjar-native" · line 14
Quoted 1 line
recipes-core/ca-certificates-java/ca-certificates-java_20180516.bb +0
-0@@ -14,7 +14,7 @@ DEPENDS = "virtual/javac-native fastjar-native"
Should this DEPEND on virtual/java7-sdk-native instead?
# We can't use virtual/javac-native, because that would create a
recipes-core/ca-certificates-java/ca-certificates-java_20180516.bb DEPENDS = "virtual/javac-native fastjar-native" · line 18
Quoted 5 lines
recipes-core/ca-certificates-java/ca-certificates-java_20180516.bb +1
-1# keystore that can't be read on the target (as virtual/javac-native # usually is either too old, or plain incompatible with this) -PACKAGE_WRITE_DEPS += "openjdk-8-native" +PACKAGE_WRITE_DEPS += "virtual/java7-runtime-native"
Would you still need the PACKAGE_WRITE_DEPS if the DEPENDS above was changed? I thought virtual/javac-native was "too old" because it was reserved for the bootstrap process, so I've been considering it as a special case.
Hi André,
thanks for the patches!
Some comments from my side:
A cover letter describing the purpose of the whole patchset would be great ;-)
Furthermore IMHO the -runtime-native and -sdk-native providers should be documented/described in the README file.
Otherwise feel free to add
for this patch.
regards;Richard.L
Quoted 29 lines · André Draszik
From: André Draszik <[email protected]>
The OpenJDK8-native recipe provides a Java SDK, and a Java Runtime. It is compatible with Java versions 5 through 8 (including), so add appropriate (R)PROVIDES, so that recipes depending on it can can specify that virtual dependency, rather than hard-coding to openjdk-8. This makes it possible to:
a) add OpenJDK9 and OpenJDK10 recipes in the future without much disruption
b) use a different provider than OpenJDK, e.g. Oracle Java, or Zulu JavaThis is the approach taken by e.g. Debian.
Signed-off-by André Draszik <[email protected]>--- recipes-core/openjdk/openjdk-8-native.inc | 3 +++ 1 file changed, 3 insertions(+)recipes-core/openjdk/openjdk-8-native.inc +3
-0@@ -87,3 +87,6 @@ do_install() { ln -sf "../lib/jvm/${JDK_DIR}/bin/$tool" ${D}${bindir}/$tool done } + +PROVIDES = "${@' '.join('virtual/java'+str(x)+'-sdk-native virtual/java'+str(x)+'-runtime-native' for x in range(5,9))}" +RPROVIDES_${PN} = "${@' '.join('virtual-java'+str(x)+'-sdk-native virtual-java'+str(x)+'-runtime-native' for x in range(5,9))}"