meta-java configuration

meta-java configuration

[Kyle Russell]

It looks like the only javac that meta-java exposes through its bbclasses
comes from libecj-bootstrap-native 3.6.2.  A few years ago, it looked like
there was an attempt to allow openjdk-8-native to provide
virtual/javac-native, but it has since been reverted.

I think I understand libecj is needed as part of the bootstrap process to
build openjdk, but if other layers want to build newer java code using
javac from openjdk 8 once available after bootstrap, does meta-java provide
support for using javac from openjdk-8-native, or is the expectation that
other layers would depend directly on openjdk-8-native and setup
EXTRANATIVEPATH as needed to reach its tools?

Maybe this is planned future work, but I wanted to make sure I was
configuring the layer correctly and using it as intended.

Thanks!

Kyle

Re: meta-java configuration

[Richard Leitner]

Hi Kyle,

On 10/24/18 11:15 PM, Kyle Russell wrote:
> It looks like the only javac that meta-java exposes through its bbclasses
> comes from libecj-bootstrap-native 3.6.2.  
That's definitely true.

> A few years ago, it looked like
> there was an attempt to allow openjdk-8-native to provide
> virtual/javac-native, but it has since been reverted.

As I'm not into the meta-java stuff that long I do not know anything 
about it... Do you have any pointers to ML discussions?

> 
> I think I understand libecj is needed as part of the bootstrap process to
> build openjdk, but if other layers want to build newer java code using
> javac from openjdk 8 once available after bootstrap, does meta-java provide
> support for using javac from openjdk-8-native, or is the expectation that
> other layers would depend directly on openjdk-8-native and setup
> EXTRANATIVEPATH as needed to reach its tools?

Yeah, ecj is needed for bootstrapping the jdk. For more details please 
take a look at docs/bootstrap-flow.txt.

AFAIK currently using openjdk-8-native seems like the only solution. 
Nonetheless I'm open for any patches to enhance this behaviour ;-)

> 
> Maybe this is planned future work, but I wanted to make sure I was
> configuring the layer correctly and using it as intended.

Currently (at least) I'm not having any future plans in this direction, 
but as mentioned above I'm open for discussions and/or patches!

> 
> Thanks!
> 
> Kyle
> 

hope that helps...

regards;Richard.L

Re: meta-java configuration

[Kyle Russell]

Hi Richard,

Thanks for your reply.

On Thu, Oct 25, 2018 at 9:09 AM Richard Leitner <richard.leitner@skidata.com>
wrote:

> > A few years ago, it looked like
> > there was an attempt to allow openjdk-8-native to provide
> > virtual/javac-native, but it has since been reverted.
>
> As I'm not into the meta-java stuff that long I do not know anything
> about it... Do you have any pointers to ML discussions?
>

Yes, I was specifically referring to
http://git.yoctoproject.org/cgit/cgit.cgi/meta-java/commit/?id=dfb21b449dd652b99bc4725796d143e8c9779cd6
.


> Yeah, ecj is needed for bootstrapping the jdk. For more details please
> take a look at docs/bootstrap-flow.txt.


Thanks!  I actually had missed that doc and was just looking at the README.


> AFAIK currently using openjdk-8-native seems like the only solution.
>
Nonetheless I'm open for any patches to enhance this behaviour ;-)
>

Ok, I will try to keep my eyes open for possibilities.  I didn't see any
documentation that described how to compile java code from other layers
using recent JDKs provided by meta-java, so I was looking for validation
that I was on the right track. :)  If I come up something I think would be
an enhancement, I'll send out a proposal.

Thanks again!
Kyle

Re: meta-java configuration

[André Draszik]

On Wed, 2018-10-24 at 17:15 -0400, Kyle Russell wrote:
> It looks like the only javac that meta-java exposes through its bbclasses
> comes from libecj-bootstrap-native 3.6.2.  A few years ago, it looked like
> there was an attempt to allow openjdk-8-native to provide
> virtual/javac-native, but it has since been reverted.
> 
> I think I understand libecj is needed as part of the bootstrap process to
> build openjdk, but if other layers want to build newer java code using
> javac from openjdk 8 once available after bootstrap, does meta-java
> provide
> support for using javac from openjdk-8-native, or is the expectation that
> other layers would depend directly on openjdk-8-native and setup
> EXTRANATIVEPATH as needed to reach its tools?
> 
> Maybe this is planned future work, but I wanted to make sure I was
> configuring the layer correctly and using it as intended.
> 
> Thanks!
> 
> Kyle

I've tried something here

http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/119590.html
http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/119591.html
http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/119592.html
http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/119593.html
http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/119594.html
http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/119595.html
http://lists.openembedded.org/pipermail/openembedded-devel/2018-July/119596.html

[oe] [meta-java][RFC][PATCH 1/7] openjdk-8-native: add meaningful (R)PROVIDES
[oe] [meta-java][RFC][PATCH 2/7] layer.conf: allow multiple Java SDKs & runtimes to co-exist
[oe] [meta-java][RFC][PATCH 3/7] openjdk-8: add meaningful (R)PROVIDES
[oe] [meta-java][RFC][PATCH 4/7] openjre-8: add meaningful (R)PROVIDES
[oe] [meta-java][RFC][PATCH 5/7] layer.conf: set defaults for Java JRE (R)PROVIDERS
[oe] [meta-java][RFC][PATCH 6/7] openjdk-7: (R)PROVIDE virtual Java [567] packages
[oe] [meta-java][RFC][PATCH 7/7] ca-certificates-java: switch to more generic / more correct JAVA (R)DEPENDS


the idea is to add virtual (R)PROVIDES that other recipes can depends on,
similar to e.g. Debian.

I'm using this locally, but I think there are some corner cases that aren't handled.


Cheers,
Andre'