It seems like a question of how many JDK versions meta-java plans on providing, and for how long. To me the number of different per-version providers feels like a maintenance point that could quickly get out of hand. I guess my assumption has been that all of the embedded Java code for the distribution would compile with the same JDK (either the latest JDK provided by meta-java, or perhaps one behind the latest version; similar to how oe-core handles gcc upgrades, for example), and that compile would pass in the appropriate -target or -bootclasspath parameters for the preferred JVM.
I hope I understand what you're saying, because I'd like to work together toward a solution. Does your distribution require specifying different providers per runtime version? On Wed, Feb 6, 2019 at 8:38 AM André Draszik <[email protected]> wrote: > 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 > > > > -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
