[oe] [PATCH 0/2] RFC: Support building Java recipes with openjdk-8-native

[André Draszik]

Hi,

First, I agree the current state isn't great at all.

It does appear to me though that Java world seems to be a bit different, in
that even today there are big Java projects out there that still only
compile using Java 8, which others do compile fine using more recent
versions.

With your suggested approach it becomes impossible to properly support that,
you still have to pick the lowest denominator globally.

Other distributions, Debian based ones in particular are taking a different
approach:
Each Java compiler/runtime provides virtual properties, and recipes can
depend on the required version easily, something like e.g.
virtual/java8-sdk virtual/java9-sdk virtual/java10-sdk etc.

I'had posted a patch series trying to mimic that before, but not really had
time to work on that any more:
http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/195641.html
http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/195642.html
http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/195643.html
http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/195644.html
http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/195645.html
http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/195646.html
http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/195647.html

What do you think?

Cheers,
Andre'

On Tue, 2019-02-05 at 10:53 -0500, Kyle Russell wrote:
> This series spun out of a request on the mailing list last October on
> configuring meta-java for using openjdk-8-native to compile other Java
> recipes that might require modern API features not provided by the
> bootstrap VM classes.
> 
> http://lists.openembedded.org/pipermail/openembedded-devel/2018-October/197186.html
> [oe] meta-java configuration
> 
> I've been running with this series on sumo, but I wanted to send it out
> to get other thoughts on the approach.
> 
> It seems like there's already precedent for this format with perlnative
> and pythonnative.  That was more or less how I expected java-native to
> behave initially until I understood more about the bootstrap process.
> 
> If I've missed a valid use case of java-native and this change would
> cause breakage to someone else's layer, I'd be fine with introducing
> javanative.bbclass as a new class that provides the same functionality
> as the following patch to java-native.bbclass.  (Its name would be more
> closely aligned to perlnative and pythonnative without the dash.)
> However, it appeared that java-native was essentially unused, and I
> thought having both a java-native and javanative class would be
> confusing.
> 
> Kyle Russell (2):
>   Add support for building Java recipes using java-native
>   ant-native: only use classpath tools if no JDK
> 
>  README                                          |  7 +++++++
>  classes/java-native.bbclass                     | 17 ++++++++++-------
>  .../ant-contrib/ant-contrib-native_1.0b3.bb     |  2 +-
>  recipes-core/ant/ant-native_1.8.1.bb            |  4 ++--
>  recipes-core/ant/files/ant                      |  9 +++++++++
>  recipes-core/openjdk/openjdk-8-native.inc       |  2 ++
>  6 files changed, 31 insertions(+), 10 deletions(-)
> 
> -- 
> 2.20.1
>