Openembedded.org - User contributions [en]

Fosdem 2012

2012-01-30T09:28:40Z

Thebohemian: /* Manning */

[[Category:Conferences]]

= OpenEmbedded booth =
== Manning ==
You are going to FOSDEM and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Robert Schuster (Saturday, Sunday until ~4pm)
* Alex Lennon (Saturday, Sunday)
* Henning Heinold (Saturday, Sunday)
* Ulf Samuelsson (Saturday, Sunday)
* Paul Eggleton (Saturday, Sunday)
* Marco Cavallini (Saturday)
* Radoslav Kolev (Sunday afternoon) - I'll be leaving Brussels on Monday, so I can stay until later to help with cleaning up tables, etc.
* Florian Boor

== Tasks ==
A bunch of tasks need to be carried out to make our attendance a pleasant experience. Each task needs a volunteer who is willing to help.

=== Table cloth ===
We only have a single table cloth (it washed but has a negligible stain from a quick soldering action that happened last year). We definitely need a 2nd one to also cover our second table. The FOSDEM tables are pretty huge (2.5m length), so chose a reasonably sized cloth. Additionally it would be super cool to have the OpenEmbedded logo printed on it. The idea would be to show the logo on the front side of our tables. For that the 'OE' sign should not be taller than say 50cm (The tables are approximately 70cm high.).

Volunteer: Philip Balister plans to bring 2 table cloths carrying the OE logo.

=== Bringing an TFT LCD ===
Displaying a presentation during the time of the conference makes our stand visually more attractive. We have a simple OpenDocument presentation in our SCM that can be used for this. However we need a display as well. If you come by car and can transport a display that'd be great. Getting a screen is not so complicated. Robert Schuster could send one to you by mail.

Volunteer: Florian Boor, a display is part of an event box he brings

=== Poster ===
A nice poster with updated sponsor was used for 2011's LinuxTag in Berlin. This poster needs to be brought to FOSDEM. Where is it right now and can it be taken to Brussels?

Volunteer: Henning Heinold (brings it from Berlin)

=== Flyers ===
Years ago we printed a bunch (2500) of flyers. We still have a bunch of them left (exact number unknown; will update this as soon as I know). As the text is already a few years old it makes sense to update the actual document (it is in openembedded/contrib/marketing/oe-flyer.pdf) and print new ones.

Volunteer: Henning and Florian bring some

=== Device Tags ===
People standing in front of our booth often want to know what kind of device it is that blinks so funnily. ;) We could make things easier by being able to print small tags providing some information about board manufacturer, CPU, RAM and what its relation to OpenEmbedded is.

Volunteer:

Alex Lennon - please send details of any tags needed to me, (ajlennon at dynamicdevices.co.uk) in reasonable time.

== Devices ==

Robert Schuster - Pandaboard - Hopefully booting Angstrom with some desktop and Java foo.

Alex Lennon - Gem (i.MX28 based telematics board) - Booting OpenEmbedded with an end-user demo running (hopefully)

Ulf Samuelsson - Atmel AT91SAM9Gx5 Kit with 5 CPU Modules (G15,G25,G35,X25,X35)
Will boot the OpenEmbedded from www.linux4sam.org
A raffle for the kit will be held in the Embedded DevRoom,
and you have to visit the OpenEmbedded stand to leave your business card.

== Flyers and posters ==
You can bring and/or print OpenEmbedded flyers and posters? Add your name and what you'll bring.

== Power extensions, adapters and other stand material ==
Bringing devices is cool but we need a way to bring power to them too. Additionally people might need power sockets for different systems than the european one. List your name and what stuff you can bring.

* Robert Schuster:
**3-socket power extension (EU)
**tape
**WiFi-Router in client mode to provide Internet access for Ethernet-based devices
**2 1m-Ethernet cables

= General attendance =

Attending FOSDEM 2012? Add your name to this page so that other developers can look out for you!

* Robert Schuster (rschus/thebohemian)
* Henning Heinold (woglinde)
* Paul Eggleton (bluelightning)
* Marco Cavallini (mckoan)

== Hotels ==

Although FOSDEM itself takes place at the ULB campus, most folks prefer to stay nearer the city centre.

The Astrid has traditionally been the default choice for OE developers, though there are many other hotels in the area. If you are staying in a hotel other than the Astrid, feel free to add it to this section for the benefit of others.

Scandic Grand Place.
Rue d'Arenberg 18
Close to beer event (300 m) and Central Station.
Tram to Fosdem around the corner.

Saint Nicolas
Hôtel Saint Nicolas ***
Rue Marché aux Poulets 32
1000 Bruxelles Tél. +32/2-219.04.40
Fax +32/2-219.17.21
http://www.st-nicolas.be/contentENG/home.asp
close to beer event, bus to Fosdem few minutes by walk from hotel.

IBIS Brussels off Grand' Place
Grasmarkt 100
Rue du Marché aux Herbes 100
1000 BRUSSELS

Fosdem 2012

2012-01-30T09:28:22Z

Thebohemian: /* Flyers */

[[Category:Conferences]]

= OpenEmbedded booth =
== Manning ==
You are going to FOSDEM and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Robert Schuster (Saturday, Sunday until ~4pm)
* Alex Lennon (Saturday, Sunday)
* Henning Heinold (Saturday, Sunday)
* Ulf Samuelsson (Saturday, Sunday)
* Paul Eggleton (Saturday, Sunday)
* Marco Cavallini (Saturday)
* Radoslav Kolev (Sunday afternoon) - I'll be leaving Brussels on Monday, so I can stay until later to help with cleaning up tables, etc.

== Tasks ==
A bunch of tasks need to be carried out to make our attendance a pleasant experience. Each task needs a volunteer who is willing to help.

=== Table cloth ===
We only have a single table cloth (it washed but has a negligible stain from a quick soldering action that happened last year). We definitely need a 2nd one to also cover our second table. The FOSDEM tables are pretty huge (2.5m length), so chose a reasonably sized cloth. Additionally it would be super cool to have the OpenEmbedded logo printed on it. The idea would be to show the logo on the front side of our tables. For that the 'OE' sign should not be taller than say 50cm (The tables are approximately 70cm high.).

Volunteer: Philip Balister plans to bring 2 table cloths carrying the OE logo.

=== Bringing an TFT LCD ===
Displaying a presentation during the time of the conference makes our stand visually more attractive. We have a simple OpenDocument presentation in our SCM that can be used for this. However we need a display as well. If you come by car and can transport a display that'd be great. Getting a screen is not so complicated. Robert Schuster could send one to you by mail.

Volunteer: Florian Boor, a display is part of an event box he brings

=== Poster ===
A nice poster with updated sponsor was used for 2011's LinuxTag in Berlin. This poster needs to be brought to FOSDEM. Where is it right now and can it be taken to Brussels?

Volunteer: Henning Heinold (brings it from Berlin)

=== Flyers ===
Years ago we printed a bunch (2500) of flyers. We still have a bunch of them left (exact number unknown; will update this as soon as I know). As the text is already a few years old it makes sense to update the actual document (it is in openembedded/contrib/marketing/oe-flyer.pdf) and print new ones.

Volunteer: Henning and Florian bring some

=== Device Tags ===
People standing in front of our booth often want to know what kind of device it is that blinks so funnily. ;) We could make things easier by being able to print small tags providing some information about board manufacturer, CPU, RAM and what its relation to OpenEmbedded is.

Volunteer:

Alex Lennon - please send details of any tags needed to me, (ajlennon at dynamicdevices.co.uk) in reasonable time.

== Devices ==

Robert Schuster - Pandaboard - Hopefully booting Angstrom with some desktop and Java foo.

Alex Lennon - Gem (i.MX28 based telematics board) - Booting OpenEmbedded with an end-user demo running (hopefully)

Ulf Samuelsson - Atmel AT91SAM9Gx5 Kit with 5 CPU Modules (G15,G25,G35,X25,X35)
Will boot the OpenEmbedded from www.linux4sam.org
A raffle for the kit will be held in the Embedded DevRoom,
and you have to visit the OpenEmbedded stand to leave your business card.

== Flyers and posters ==
You can bring and/or print OpenEmbedded flyers and posters? Add your name and what you'll bring.

== Power extensions, adapters and other stand material ==
Bringing devices is cool but we need a way to bring power to them too. Additionally people might need power sockets for different systems than the european one. List your name and what stuff you can bring.

* Robert Schuster:
**3-socket power extension (EU)
**tape
**WiFi-Router in client mode to provide Internet access for Ethernet-based devices
**2 1m-Ethernet cables

= General attendance =

Attending FOSDEM 2012? Add your name to this page so that other developers can look out for you!

* Robert Schuster (rschus/thebohemian)
* Henning Heinold (woglinde)
* Paul Eggleton (bluelightning)
* Marco Cavallini (mckoan)

== Hotels ==

Although FOSDEM itself takes place at the ULB campus, most folks prefer to stay nearer the city centre.

The Astrid has traditionally been the default choice for OE developers, though there are many other hotels in the area. If you are staying in a hotel other than the Astrid, feel free to add it to this section for the benefit of others.

Scandic Grand Place.
Rue d'Arenberg 18
Close to beer event (300 m) and Central Station.
Tram to Fosdem around the corner.

Saint Nicolas
Hôtel Saint Nicolas ***
Rue Marché aux Poulets 32
1000 Bruxelles Tél. +32/2-219.04.40
Fax +32/2-219.17.21
http://www.st-nicolas.be/contentENG/home.asp
close to beer event, bus to Fosdem few minutes by walk from hotel.

IBIS Brussels off Grand' Place
Grasmarkt 100
Rue du Marché aux Herbes 100
1000 BRUSSELS

Fosdem 2012

2012-01-30T09:16:22Z

Thebohemian: /* Poster */

[[Category:Conferences]]

= OpenEmbedded booth =
== Manning ==
You are going to FOSDEM and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Robert Schuster (Saturday, Sunday until ~4pm)
* Alex Lennon (Saturday, Sunday)
* Henning Heinold (Saturday, Sunday)
* Ulf Samuelsson (Saturday, Sunday)
* Paul Eggleton (Saturday, Sunday)
* Marco Cavallini (Saturday)
* Radoslav Kolev (Sunday afternoon) - I'll be leaving Brussels on Monday, so I can stay until later to help with cleaning up tables, etc.

== Tasks ==
A bunch of tasks need to be carried out to make our attendance a pleasant experience. Each task needs a volunteer who is willing to help.

=== Table cloth ===
We only have a single table cloth (it washed but has a negligible stain from a quick soldering action that happened last year). We definitely need a 2nd one to also cover our second table. The FOSDEM tables are pretty huge (2.5m length), so chose a reasonably sized cloth. Additionally it would be super cool to have the OpenEmbedded logo printed on it. The idea would be to show the logo on the front side of our tables. For that the 'OE' sign should not be taller than say 50cm (The tables are approximately 70cm high.).

Volunteer: Philip Balister plans to bring 2 table cloths carrying the OE logo.

=== Bringing an TFT LCD ===
Displaying a presentation during the time of the conference makes our stand visually more attractive. We have a simple OpenDocument presentation in our SCM that can be used for this. However we need a display as well. If you come by car and can transport a display that'd be great. Getting a screen is not so complicated. Robert Schuster could send one to you by mail.

Volunteer: Florian Boor, a display is part of an event box he brings

=== Poster ===
A nice poster with updated sponsor was used for 2011's LinuxTag in Berlin. This poster needs to be brought to FOSDEM. Where is it right now and can it be taken to Brussels?

Volunteer: Henning Heinold (brings it from Berlin)

=== Flyers ===
Years ago we printed a bunch (2500) of flyers. We still have a bunch of them left (exact number unknown; will update this as soon as I know). As the text is already a few years old it makes sense to update the actual document (it is in openembedded/contrib/marketing/oe-flyer.pdf) and print new ones.

Volunteer:

=== Device Tags ===
People standing in front of our booth often want to know what kind of device it is that blinks so funnily. ;) We could make things easier by being able to print small tags providing some information about board manufacturer, CPU, RAM and what its relation to OpenEmbedded is.

Volunteer:

Alex Lennon - please send details of any tags needed to me, (ajlennon at dynamicdevices.co.uk) in reasonable time.

== Devices ==

Robert Schuster - Pandaboard - Hopefully booting Angstrom with some desktop and Java foo.

Alex Lennon - Gem (i.MX28 based telematics board) - Booting OpenEmbedded with an end-user demo running (hopefully)

Ulf Samuelsson - Atmel AT91SAM9Gx5 Kit with 5 CPU Modules (G15,G25,G35,X25,X35)
Will boot the OpenEmbedded from www.linux4sam.org
A raffle for the kit will be held in the Embedded DevRoom,
and you have to visit the OpenEmbedded stand to leave your business card.

== Flyers and posters ==
You can bring and/or print OpenEmbedded flyers and posters? Add your name and what you'll bring.

== Power extensions, adapters and other stand material ==
Bringing devices is cool but we need a way to bring power to them too. Additionally people might need power sockets for different systems than the european one. List your name and what stuff you can bring.

* Robert Schuster:
**3-socket power extension (EU)
**tape
**WiFi-Router in client mode to provide Internet access for Ethernet-based devices
**2 1m-Ethernet cables

= General attendance =

Attending FOSDEM 2012? Add your name to this page so that other developers can look out for you!

* Robert Schuster (rschus/thebohemian)
* Henning Heinold (woglinde)
* Paul Eggleton (bluelightning)
* Marco Cavallini (mckoan)

== Hotels ==

Although FOSDEM itself takes place at the ULB campus, most folks prefer to stay nearer the city centre.

The Astrid has traditionally been the default choice for OE developers, though there are many other hotels in the area. If you are staying in a hotel other than the Astrid, feel free to add it to this section for the benefit of others.

Scandic Grand Place.
Rue d'Arenberg 18
Close to beer event (300 m) and Central Station.
Tram to Fosdem around the corner.

Saint Nicolas
Hôtel Saint Nicolas ***
Rue Marché aux Poulets 32
1000 Bruxelles Tél. +32/2-219.04.40
Fax +32/2-219.17.21
http://www.st-nicolas.be/contentENG/home.asp
close to beer event, bus to Fosdem few minutes by walk from hotel.

IBIS Brussels off Grand' Place
Grasmarkt 100
Rue du Marché aux Herbes 100
1000 BRUSSELS

Fosdem 2012

2012-01-30T09:15:54Z

Thebohemian: /* Bringing an TFT LCD */

[[Category:Conferences]]

= OpenEmbedded booth =
== Manning ==
You are going to FOSDEM and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Robert Schuster (Saturday, Sunday until ~4pm)
* Alex Lennon (Saturday, Sunday)
* Henning Heinold (Saturday, Sunday)
* Ulf Samuelsson (Saturday, Sunday)
* Paul Eggleton (Saturday, Sunday)
* Marco Cavallini (Saturday)
* Radoslav Kolev (Sunday afternoon) - I'll be leaving Brussels on Monday, so I can stay until later to help with cleaning up tables, etc.

== Tasks ==
A bunch of tasks need to be carried out to make our attendance a pleasant experience. Each task needs a volunteer who is willing to help.

=== Table cloth ===
We only have a single table cloth (it washed but has a negligible stain from a quick soldering action that happened last year). We definitely need a 2nd one to also cover our second table. The FOSDEM tables are pretty huge (2.5m length), so chose a reasonably sized cloth. Additionally it would be super cool to have the OpenEmbedded logo printed on it. The idea would be to show the logo on the front side of our tables. For that the 'OE' sign should not be taller than say 50cm (The tables are approximately 70cm high.).

Volunteer: Philip Balister plans to bring 2 table cloths carrying the OE logo.

=== Bringing an TFT LCD ===
Displaying a presentation during the time of the conference makes our stand visually more attractive. We have a simple OpenDocument presentation in our SCM that can be used for this. However we need a display as well. If you come by car and can transport a display that'd be great. Getting a screen is not so complicated. Robert Schuster could send one to you by mail.

Volunteer: Florian Boor, a display is part of an event box he brings

=== Poster ===
A nice poster with updated sponsor was used for 2011's LinuxTag in Berlin. This poster needs to be brought to FOSDEM. Where is it right now and can it be taken to Brussels?

Volunteer:

=== Flyers ===
Years ago we printed a bunch (2500) of flyers. We still have a bunch of them left (exact number unknown; will update this as soon as I know). As the text is already a few years old it makes sense to update the actual document (it is in openembedded/contrib/marketing/oe-flyer.pdf) and print new ones.

Volunteer:

=== Device Tags ===
People standing in front of our booth often want to know what kind of device it is that blinks so funnily. ;) We could make things easier by being able to print small tags providing some information about board manufacturer, CPU, RAM and what its relation to OpenEmbedded is.

Volunteer:

Alex Lennon - please send details of any tags needed to me, (ajlennon at dynamicdevices.co.uk) in reasonable time.

== Devices ==

Robert Schuster - Pandaboard - Hopefully booting Angstrom with some desktop and Java foo.

Alex Lennon - Gem (i.MX28 based telematics board) - Booting OpenEmbedded with an end-user demo running (hopefully)

Ulf Samuelsson - Atmel AT91SAM9Gx5 Kit with 5 CPU Modules (G15,G25,G35,X25,X35)
Will boot the OpenEmbedded from www.linux4sam.org
A raffle for the kit will be held in the Embedded DevRoom,
and you have to visit the OpenEmbedded stand to leave your business card.

== Flyers and posters ==
You can bring and/or print OpenEmbedded flyers and posters? Add your name and what you'll bring.

== Power extensions, adapters and other stand material ==
Bringing devices is cool but we need a way to bring power to them too. Additionally people might need power sockets for different systems than the european one. List your name and what stuff you can bring.

* Robert Schuster:
**3-socket power extension (EU)
**tape
**WiFi-Router in client mode to provide Internet access for Ethernet-based devices
**2 1m-Ethernet cables

= General attendance =

Attending FOSDEM 2012? Add your name to this page so that other developers can look out for you!

* Robert Schuster (rschus/thebohemian)
* Henning Heinold (woglinde)
* Paul Eggleton (bluelightning)
* Marco Cavallini (mckoan)

== Hotels ==

Although FOSDEM itself takes place at the ULB campus, most folks prefer to stay nearer the city centre.

The Astrid has traditionally been the default choice for OE developers, though there are many other hotels in the area. If you are staying in a hotel other than the Astrid, feel free to add it to this section for the benefit of others.

Scandic Grand Place.
Rue d'Arenberg 18
Close to beer event (300 m) and Central Station.
Tram to Fosdem around the corner.

Saint Nicolas
Hôtel Saint Nicolas ***
Rue Marché aux Poulets 32
1000 Bruxelles Tél. +32/2-219.04.40
Fax +32/2-219.17.21
http://www.st-nicolas.be/contentENG/home.asp
close to beer event, bus to Fosdem few minutes by walk from hotel.

IBIS Brussels off Grand' Place
Grasmarkt 100
Rue du Marché aux Herbes 100
1000 BRUSSELS

Fosdem 2012

2012-01-30T08:33:07Z

Thebohemian: /* Manning */

[[Category:Conferences]]

= OpenEmbedded booth =
== Manning ==
You are going to FOSDEM and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Robert Schuster (Saturday, Sunday until ~4pm)
* Alex Lennon (Saturday, Sunday)
* Henning Heinold (Saturday, Sunday)
* Ulf Samuelsson (Saturday, Sunday)
* Paul Eggleton (Saturday, Sunday)
* Marco Cavallini (Saturday)
* Radoslav Kolev (Sunday afternoon) - I'll be leaving Brussels on Monday, so I can stay until later to help with cleaning up tables, etc.

== Tasks ==
A bunch of tasks need to be carried out to make our attendance a pleasant experience. Each task needs a volunteer who is willing to help.

=== Table cloth ===
We only have a single table cloth (it washed but has a negligible stain from a quick soldering action that happened last year). We definitely need a 2nd one to also cover our second table. The FOSDEM tables are pretty huge (2.5m length), so chose a reasonably sized cloth. Additionally it would be super cool to have the OpenEmbedded logo printed on it. The idea would be to show the logo on the front side of our tables. For that the 'OE' sign should not be taller than say 50cm (The tables are approximately 70cm high.).

Volunteer: Philip Balister plans to bring 2 table cloths carrying the OE logo.

=== Bringing an TFT LCD ===
Displaying a presentation during the time of the conference makes our stand visually more attractive. We have a simple OpenDocument presentation in our SCM that can be used for this. However we need a display as well. If you come by car and can transport a display that'd be great. Getting a screen is not so complicated. Robert Schuster could send one to you by mail.

Volunteer:

=== Poster ===
A nice poster with updated sponsor was used for 2011's LinuxTag in Berlin. This poster needs to be brought to FOSDEM. Where is it right now and can it be taken to Brussels?

Volunteer:

=== Flyers ===
Years ago we printed a bunch (2500) of flyers. We still have a bunch of them left (exact number unknown; will update this as soon as I know). As the text is already a few years old it makes sense to update the actual document (it is in openembedded/contrib/marketing/oe-flyer.pdf) and print new ones.

Volunteer:

=== Device Tags ===
People standing in front of our booth often want to know what kind of device it is that blinks so funnily. ;) We could make things easier by being able to print small tags providing some information about board manufacturer, CPU, RAM and what its relation to OpenEmbedded is.

Volunteer:

Alex Lennon - please send details of any tags needed to me, (ajlennon at dynamicdevices.co.uk) in reasonable time.

== Devices ==

Robert Schuster - Pandaboard - Hopefully booting Angstrom with some desktop and Java foo.

Alex Lennon - Gem (i.MX28 based telematics board) - Booting OpenEmbedded with an end-user demo running (hopefully)

Ulf Samuelsson - Atmel AT91SAM9Gx5 Kit with 5 CPU Modules (G15,G25,G35,X25,X35)
Will boot the OpenEmbedded from www.linux4sam.org
A raffle for the kit will be held in the Embedded DevRoom,
and you have to visit the OpenEmbedded stand to leave your business card.

== Flyers and posters ==
You can bring and/or print OpenEmbedded flyers and posters? Add your name and what you'll bring.

== Power extensions, adapters and other stand material ==
Bringing devices is cool but we need a way to bring power to them too. Additionally people might need power sockets for different systems than the european one. List your name and what stuff you can bring.

* Robert Schuster:
**3-socket power extension (EU)
**tape
**WiFi-Router in client mode to provide Internet access for Ethernet-based devices
**2 1m-Ethernet cables

= General attendance =

Attending FOSDEM 2012? Add your name to this page so that other developers can look out for you!

* Robert Schuster (rschus/thebohemian)
* Henning Heinold (woglinde)
* Paul Eggleton (bluelightning)
* Marco Cavallini (mckoan)

== Hotels ==

Although FOSDEM itself takes place at the ULB campus, most folks prefer to stay nearer the city centre.

The Astrid has traditionally been the default choice for OE developers, though there are many other hotels in the area. If you are staying in a hotel other than the Astrid, feel free to add it to this section for the benefit of others.

Scandic Grand Place.
Rue d'Arenberg 18
Close to beer event (300 m) and Central Station.
Tram to Fosdem around the corner.

Saint Nicolas
Hôtel Saint Nicolas ***
Rue Marché aux Poulets 32
1000 Bruxelles Tél. +32/2-219.04.40
Fax +32/2-219.17.21
http://www.st-nicolas.be/contentENG/home.asp
close to beer event, bus to Fosdem few minutes by walk from hotel.

IBIS Brussels off Grand' Place
Grasmarkt 100
Rue du Marché aux Herbes 100
1000 BRUSSELS

Fosdem 2012

2012-01-19T13:24:27Z

Thebohemian: /* Table cloth */

[[Category:Conferences]]

= OpenEmbedded booth =
== Manning ==
You are going to FOSDEM and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Robert Schuster (Saturday, Sunday)
* Alex Lennon (Saturday, Sunday)
* Henning Heinold (Saturday, Sunday)

== Tasks ==
A bunch of tasks need to be carried out to make our attendance a pleasant experience. Each task needs a volunteer who is willing to help.

=== Table cloth ===
We only have a single table cloth (it washed but has a negligible stain from a quick soldering action that happened last year). We definitely need a 2nd one to also cover our second table. The FOSDEM tables are pretty huge (2.5m length), so chose a reasonably sized cloth. Additionally it would be super cool to have the OpenEmbedded logo printed on it. The idea would be to show the logo on the front side of our tables. For that the 'OE' sign should not be taller than say 50cm (The tables are approximately 70cm high.).

Volunteer: Philip Balister plans to bring 2 table cloths carrying the OE logo.

=== Bringing an TFT LCD ===
Displaying a presentation during the time of the conference makes our stand visually more attractive. We have a simple OpenDocument presentation in our SCM that can be used for this. However we need a display as well. If you come by car and can transport a display that'd be great. Getting a screen is not so complicated. Robert Schuster could send one to you by mail.

Volunteer:

=== Poster ===
A nice poster with updated sponsor was used for 2011's LinuxTag in Berlin. This poster needs to be brought to FOSDEM. Where is it right now and can it be taken to Brussels?

Volunteer:

=== Flyers ===
Years ago we printed a bunch (2500) of flyers. We still have a bunch of them left (exact number unknown; will update this as soon as I know). As the text is already a few years old it makes sense to update the actual document (it is in openembedded/contrib/marketing/oe-flyer.pdf) and print new ones.

Volunteer:

=== Device Tags ===
People standing in front of our booth often want to know what kind of device it is that blinks so funnily. ;) We could make things easier by being able to print small tags providing some information about board manufacturer, CPU, RAM and what its relation to OpenEmbedded is.

Volunteer:

== Devices ==

Robert Schuster - Pandaboard - Hopefully booting Angstrom with some desktop and Java foo.

Alex Lennon - Gem (i.MX28 based telematics board) - Booting OpenEmbedded with an end-user demo running (hopefully)

== Flyers and posters ==
You can bring and/or print OpenEmbedded flyers and posters? Add your name and what you'll bring.

== Power extensions, adapters and other stand material ==
Bringing devices is cool but we need a way to bring power to them too. Additionally people might need power sockets for different systems than the european one. List your name and what stuff you can bring.

* Robert Schuster:
**3-socket power extension (EU)
**tape
**WiFi-Router in client mode to provide Internet access for Ethernet-based devices
**2 1m-Ethernet cables

= General attendance =

Attending FOSDEM 2012? Add your name to this page so that other developers can look out for you!

* Robert Schuster (rschus/thebohemian)
* Henning Heinold (woglinde)
== Hotels ==

Although FOSDEM itself takes place at the ULB campus, most folks prefer to stay nearer the city centre.

The Astrid has traditionally been the default choice for OE developers, though there are many other hotels in the area. If you are staying in a hotel other than the Astrid, feel free to add it to this section for the benefit of others.

Scandic Grand Place.
Rue d'Arenberg 18
Close to beer event (300 m) and Central Station.
Tram to Fosdem around the corner.

Saint Nicolas
Hôtel Saint Nicolas ***
Rue Marché aux Poulets 32
1000 Bruxelles Tél. +32/2-219.04.40
Fax +32/2-219.17.21
http://www.st-nicolas.be/contentENG/home.asp
close to beer event, bus to Fosdem few minutes by walk from hotel.

Fosdem 2012

2012-01-13T14:42:00Z

Thebohemian: /* Power extensions, adapters and other stand material */

[[Category:Conferences]]

= OpenEmbedded booth =
== Manning ==
You are going to FOSDEM and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Robert Schuster (Saturday, Sunday)

== Tasks ==
A bunch of tasks need to be carried out to make our attendance a pleasant experience. Each task needs a volunteer who is willing to help.

=== Table cloth ===
We only have a single table cloth (it washed but has a negligible stain from a quick soldering action that happened last year). We definitely need a 2nd one to also cover our second table. The FOSDEM tables are pretty huge (2.5m length), so chose a reasonably sized cloth. Additionally it would be super cool to have the OpenEmbedded logo printed on it. The idea would be to show the logo on the front side of our tables. For that the 'OE' sign should not be taller than say 50cm (The tables are approximately 70cm high.).

Volunteer:

=== Bringing an TFT LCD ===
Displaying a presentation during the time of the conference makes our stand visually more attractive. We have a simple OpenDocument presentation in our SCM that can be used for this. However we need a display as well. If you come by car and can transport a display that'd be great. Getting a screen is not so complicated. Robert Schuster could send one to you by mail.

Volunteer:

=== Poster ===
A nice poster with updated sponsor was used for 2011's LinuxTag in Berlin. This poster needs to be brought to FOSDEM. Where is it right now and can it be taken to Brussels?

Volunteer:

=== Flyers ===
Years ago we printed a bunch of flyers. We still have a bunch of them left (exact number unknown; will update this as soon as I know). As the text is already a few years old it makes sense to update the actual document (it is in our SCM?) and print new ones.

Volunteer:

=== Device Tags ===
People standing in front of our booth often want to know what kind of device it is that blinks so funnily. ;) We could make things easier by being able to print small tags providing some information about board manufacturer, CPU, RAM and what its relation to OpenEmbedded is.

Volunteer:

== Devices ==

Robert Schuster - Pandaboard - Hopefully booting Angstrom with some desktop and Java foo.

== Flyers and posters ==
You can bring and/or print OpenEmbedded flyers and posters? Add your name and what you'll bring.

== Power extensions, adapters and other stand material ==
Bringing devices is cool but we need a way to bring power to them too. Additionally people might need power sockets for different systems than the european one. List your name
and what stuff you can bring.

* Robert Schuster:
**3-socket power extension (EU)
**tape
**WiFi-Router in client mode to provide Internet access for Ethernet-based devices
**2 1m-Ethernet cables

= General attendance =

Attending FOSDEM 2011? Add your name to this page so that other developers can look out for you!

* Robert Schuster (rschus/thebohemian)

== Hotels ==

Although FOSDEM itself takes place at the ULB campus, most folks prefer to stay nearer the city centre.

The Astrid has traditionally been the default choice for OE developers, though there are many other hotels in the area. If you are staying in a hotel other than the Astrid, feel free to add it to this section for the benefit of others.

Scandic Grand Place.
Rue d'Arenberg 18
Close to beer event (300 m) and Central Station.
Tram to Fosdem around the corner.

Fosdem 2012

2012-01-13T14:41:01Z

Thebohemian: added tasks

TravelReimbursement

2011-12-05T20:25:46Z

Thebohemian:

== What? ==
OpenEmbedded needs to be present with a booth at conferences etc. For this the OEEV is planning to reimburse volunteers. This page is about collecting the information about travel costs and come to a conclusion of how much each helper is reimbursed and what the details for reimbursement are.

== Requirements ==
There should be at least 2 people per day at the OpenEmbedded booth. If the event is a short one like FOSDEM (2 days) it is fine if the same two people are there during the whole conference.

CeBIT lasts usually from Tuesday to Saturday and is a very busy event. Supporters should be changed every few days so that not one person mans the booth everyday.

=== Costs for travel (in Europe) ===
Varies from 20€ (public transport) to 2000€ (late-booked flight ticket). We should pay up to 300€ for this.

=== Meals ===
Companies usually pay 24€ per day.

=== Lodging ===
Hotels costs are in the range of 80 to 100€ per night.

== U.S. Per diem rates ==
http://www.gsa.gov/portal/category/21287

== Foreign Per diem rates ==
http://aoprals.state.gov/content.asp?content_id=184&menu_id=78

TravelReimbursement

2011-12-05T20:20:48Z

Thebohemian: created

== What? ==
OpenEmbedded needs to be present with a booth at conferences etc. For this the OEEV is planning to reimburse volunteers. This page is about collecting the information about travel costs and come to a conclusion of how much each helper is reimbursed and what the details for reimbursement are.

== Requirements ==
There should be at least 2 people per day at the OpenEmbedded booth. If the event is a short one like FOSDEM (2 days) it is fine if the same two people are there during the whole conference.

CeBIT lasts usually from Tuesday to Saturday and is a very busy event. Supporters should be changed every few days so that not one person mans the booth everyday.

=== Costs for travel (in Europe) ===
Varies from 20€ (public transport) to 2000€ (late-booked flight ticket)

=== Meals ===
Companies usually pay 24€ per day.

=== Lodging ===
Hotels costs are in the range of 80 to 100€ per night.

== U.S. Per diem rates ==
http://www.gsa.gov/portal/category/21287

== Foreign Per diem rates ==
http://aoprals.state.gov/content.asp?content_id=184&menu_id=78

LinuxTag

2011-04-26T17:03:38Z

Thebohemian:

== LinuxTag 2011 ==
* takes place in Berlin, Germany
* May 11th to 14th 2011
* LinuxTag is Germany's biggest F/OSS event
* Berlin is supercool and quite cheap

== Manning ==
You are going to LinuxTag and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Florian Boor
* Robert Schuster (will definitely be there)
* Henning Heinold (occassionally, can jump in so that other people can take a break)
* <your name here>

== Yocto/oe-core ==

* be informed of what will come
* oe-core/layers bsp's

== Booth support material ==
* power extensions and converters
* TFT screen
* transport box
* SD cards and reader
* WIFI AP in managed mode (provide wired network to embedded devices)

== Marketing material ==
* Flyer availability?
* Poster availability?
- Poster needs to be updated
- where are poster sources?
* embedded devices to show (+ what is running on them)
-
-
-
* booth presentation slideshow
- Robert Schuster made one for CeBIT, will update it and bring it to the event
* OE booth demo image

LinuxTag

2011-04-18T09:13:10Z

Thebohemian: /* Marketing material */

== LinuxTag 2011 ==
* takes place in Berlin, Germany
* May 11th to 14th 2011
* LinuxTag is Germany's biggest F/OSS event
* Berlin is supercool and quite cheap

== Manning ==
You are going to LinuxTag and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Florian Boor
* Robert Schuster (remains to be decided by employer)
* Henning Heinold (occassionally, can jump in so that other people can take a break)
* <your name here>

== Booth support material ==
* power extensions and converters
* TFT screen
* transport box
* SD cards and reader
* WIFI AP in managed mode (provide wired network to embedded devices)

== Marketing material ==
* Flyer availability?
* Poster availability?
- Poster needs to be updated
- where are poster sources?
* embedded devices to show (+ what is running on them)
-
-
-
* booth presentation slideshow
- Robert Schuster made one for CeBIT, will update it and bring it to the event
* OE booth demo image

LinuxTag

2011-04-18T09:04:43Z

Thebohemian: Created page with "== LinuxTag 2011 == * takes place in Berlin, Germany * May 11th to 14th 2011 * LinuxTag is Germany's biggest F/OSS event * Berlin is supercool and quite cheap == Manning == You ..."

== LinuxTag 2011 ==
* takes place in Berlin, Germany
* May 11th to 14th 2011
* LinuxTag is Germany's biggest F/OSS event
* Berlin is supercool and quite cheap

== Manning ==
You are going to LinuxTag and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Florian Boor
* Robert Schuster (remains to be decided by employer)
* Henning Heinold (occassionally, can jump in so that other people can take a break)
* <your name here>

== Booth support material ==
* power extensions and converters
* TFT screen
* transport box
* SD cards and reader
* WIFI AP in managed mode (provide wired network to embedded devices)

== Marketing material ==
* Flyer availability?
* Poster availability?
- Poster needs to be updated
- where are poster sources?
* embedded devices to show (+ what is running on them)
-
-
-
* booth presentation slideshow
* OE booth demo image

CeBIT 2011

2011-02-21T10:04:49Z

Thebohemian: /* Flyers and posters */

= OpenEmbedded booth =
== Manning ==
You are going to CeBIT 2011 and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Robert Schuster
* Mickey Lauer
* Henning Heinold (3.3-5.3, only parttime, mainly on the navit booth)

== Devices ==

== Flyers and posters ==
* Robert Schuster: ~500 OpenEmbedded flyers (will be sent from Florian to tarent office in Bonn)

== Free Tickets ==

CeBIT organizers provided us with lots of free tickets for the event. If you want one leave your name and email here (don't forget to obfuscate the later a bit).

CeBIT 2011

2011-02-17T20:10:33Z

Thebohemian: new page

= OpenEmbedded booth =
== Manning ==
You are going to CeBIT 2011 and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Robert Schuster
* Mickey Lauer

== Devices ==

== Flyers and posters ==
You can bring and/or print OpenEmbedded flyers and posters? Add your name and what you'll bring.

== Free Tickets ==

CeBIT organizers provided us with lots of free tickets for the event. If you want one leave your name and email here (don't forget to obfuscate the later a bit).

Fosdem 2011

2011-01-31T16:10:14Z

Thebohemian: /* Power extensions and adapters */

= OpenEmbedded booth =
== Manning ==
You are going to FOSDEM and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Robert Schuster (Saturday)
* Ulf Samuelsson (Saturday and Sunday occasionally)
* Philip Balister (As needed)

== Devices ==
Add your name and what devices you'll bring for the stand.

Ulf Samuelsson - AT91SAM9M10EKES booting Openembedded/Android from SD-Card
(No flash on board enabled)

Robert Schuster - Pandaboard - Hopefully booting Angstrom with some desktop and Java foo. Try to get hold of a small TFT display

== Flyers and posters ==
You can bring and/or print OpenEmbedded flyers and posters? Add your name and what you'll bring.

== Power extensions, adapters and other stand material ==
Bringing devices is cool but we need a way to bring power to them too. Additionally people might need power sockets for different systems than the european one. List your name
and what stuff you can bring.

* Robert Schuster:
**3-socket power extension (EU)
**tape

= General attendance =

Attending FOSDEM 2011? Add your name to this page so that other developers can look out for you!

* Esben Haabendal
* Frans Meulenbroeks (eFfeM)
* Philip Balister (Crofton)
* Robert Schuster (rschus/thebohemian)
* Ulf Samuelsson

== Hotels ==

Although FOSDEM itself takes place at the ULB campus, most folks prefer to stay nearer the city centre.

The Astrid has traditionally been the default choice for OE developers, though there are many other hotels in the area. If you are staying in a hotel other than the Astrid, feel free to add it to this section for the benefit of others.

Scandic Grand Place.
Rue d'Arenberg 18
Close to beer event (300 m) and Central Station.
Tram to Fosdem around the corner.

Fosdem 2011

2011-01-10T07:25:18Z

Thebohemian: /* Devices */

= OpenEmbedded booth =
== Manning ==
You are going to FOSDEM and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Robert Schuster (Saturday)
* Ulf Samuelsson (Saturday and Sunday occasionally)

== Devices ==
Add your name and what devices you'll bring for the stand.

Ulf Samuelsson - AT91SAM9M10EKES booting Openembedded/Android from SD-Card
(No flash on board enabled)

Robert Schuster - Pandaboard - Hopefully booting Angstrom with some desktop and Java foo. Try to get hold of a small TFT display

== Flyers and posters ==
You can bring and/or print OpenEmbedded flyers and posters? Add your name and what you'll bring.

== Power extensions and adapters ==
Bringing devices is cool but we need a way to bring power to them too. Additionally people might need power sockets for different systems than the european one. List your name
and what stuff you can bring.

* Robert Schuster: 4-socket power extension (EU)

= General attendance =

Attending FOSDEM 2011? Add your name to this page so that other developers can look out for you!

* Esben Haabendal
* Frans Meulenbroeks (eFfeM)
* Robert Schuster (rschus/thebohemian)
* Ulf Samuelsson

== Hotels ==

Although FOSDEM itself takes place at the ULB campus, most folks prefer to stay nearer the city centre.

The Astrid has traditionally been the default choice for OE developers, though there are many other hotels in the area. If you are staying in a hotel other than the Astrid, feel free to add it to this section for the benefit of others.

Scandic Grand Place.
Rue d'Arenberg 18
Close to beer event (300 m) and Central Station.
Tram to Fosdem around the corner.

Fosdem 2011

2011-01-06T08:21:21Z

Thebohemian:

= OpenEmbedded booth =
== Manning ==
You are going to FOSDEM and can spend some time at the OpenEmbedded stand to explain interested individuals the virtues of OpenEmbedded? Add your name and on which day you'll be available.

* Robert Schuster (Saturday)

== Devices ==
Add your name and what devices you'll bring for the stand.

== Flyers and posters ==
You can bring and/or print OpenEmbedded flyers and posters? Add your name and what you'll bring.

== Power extensions and adapters ==
Bringing devices is cool but we need a way to bring power to them too. Additionally people might need power sockets for different systems than the european one. List your name
and what stuff you can bring.

* Robert Schuster: 4-socket power extension (EU)

= General attendance =

Attending FOSDEM 2011? Add your name to this page so that other developers can look out for you!

* Frans Meulenbroeks (eFfeM)
* Esben Haabendal
* Robert Schuster (rschus/thebohemian)

== Hotels ==

Although FOSDEM itself takes place at the ULB campus, most folks prefer to stay nearer the city centre.

The Astrid has traditionally been the default choice for OE developers, though there are many other hotels in the area. If you are staying in a hotel other than the Astrid, feel free to add it to this section for the benefit of others.

Presentations

2010-11-22T13:41:36Z

Thebohemian: /* 2010 */

List of presentations talking of OpenEmbedded and bitbake :

== 2004 ==
[http://uuu.enseirb.fr/~kadionik/rmll2004/presentation/philip_blundell.pdf Introduction to the GPE Palmtop Environment and the OpenEmbedded Project] - Phil Blundell - RMLL - [[Media:philip_blundell.pdf]]

== 2005 ==
Building Embedded Linux Distributions with BitBake and OpenEmbedded - Michael 'Mickey' Lauer - FOSDEM - [[Media:FOSDEM2005.pdf]]

== 2006 ==
[http://svn.gnumonks.org/trunk/presentation/2006/oe_simputer-foss.in-2006/oe_simputer.pdf OpenEmbedded on the Simputer] - Harald Welte - FOSS.in - [[Media:oe_simputer.pdf]]

== 2007 ==
[http://www.power.org/devcon/07/Session_Downloads/PADC07_Koroneos_OE-presentation-final.pdf Introduction to OE] - Stelios S. Koroneos - PowerArchitecture Developer Conference - [[Media:PADC07_Koroneos_OE-presentation-final.pdf]]

[http://elinux.org/images/7/7c/Koen-ELC2007.pdf OpenEmbedded Easy QA, repeatability and retargetting] - Koen Kooi, Michael 'Mickey' Lauer, Richard 'RP' Purdie, Holger 'zecke' Freyther - ELC - [[Media:Koen-ELC2007.pdf]]

== 2008 ==
[http://www.celinux.org/elc08_presentations/mlocke-elc2008-oe.pdf OpenEmbedded for Product Development] - Matthew Locke - ELC - [[Media:mlocke-elc2008-oe.pdf]]

[http://cgit.openembedded.org/cgit.cgi/openembedded/plain/contrib/presentations/cross-compilation_with_OpenEmbedded_-_LinuxTag2008_-_Robert_Schuster.odp Cross Compilation With OpenEmbedded] - Robert Schuster - LinuxTag [[Media:Cross-compilation with OpenEmbedded - LinuxTag2008 - Robert Schuster.pdf]]

== 2009 ==
[http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFile&do=get&target=ELC.klaasvangend.openembedded.v4.pdf Top 3 pains in professional use of bitbake] - Klaas van Gend - ELC - [[Media:ELC2009Presentations.pdf]]

[http://marcin.juszkiewicz.com.pl/download/presentations/2009-SCW-Poky_Linux_and_OpenEmbedded_based_environment.pdf Poky Linux & OpenEmbedded based environment] - Marcin Juszkiewicz - ST-Ericsson Community Workshop - [[Media:2009-SCW-Poky_Linux_and_OpenEmbedded_based_environment.pdf]]

[http://elinux.org/images/a/ac/Hombourger-Why_oe_good_foundation_for_mv.odp Why OpenEmbedded proved a good foundation for MontaVista] - Cedric Hombourger - ELCE - [[Media:Hombourger-Why_oe_good_foundation_for_mv.pdf]]

[http://elinux.org/images/e/e4/Juszkiewicz-HackingWithOpenEmbedded.pdf Hacking with OpenEmbedded] - Marcin Juszkiewicz - ELCE - [[Media:Juszkiewicz-HackingWithOpenEmbedded.pdf]]

[ftp://ftp.koansoftware.com/public/talks/Confsl-2009/KaeilOS-Confsl09.pdf KaeilOS e Openembedded Linux - paper] - Marco Cavallini - [http://www.confsl.org/confsl09/ CONFSL] (presentation in Italian / presentazione in italiano) - [[Media:KaeilOS-Confsl09.pdf]]

[ftp://ftp.koansoftware.com/public/talks/Confsl-2009/KaeilOS-Confsl09-slides.pdf KaeilOS e Openembedded Linux - slides] - Marco Cavallini - [http://www.confsl.org/confsl09/ CONFSL] (presentation in Italian / presentazione in italiano) - [[Media:KaeilOS-Confsl09-slides.pdf]]

== 2010 ==
[http://www.slideshare.net/zenlinux/openembedded OpenEmbedded] - Scott Garman - PLUG Advanced Topics

[http://www.solutionslinux.fr/upload/file/linux%202010/oe_presentation.pdf OpenEmbedded Une solution GNU/Linux pour l'embarqué] - Cyril Romain - Solutions Linux - (presentation in French / présentation en Français)

[http://elinux.org/images/7/73/Openembedded.pdf The State of OpenEmbedded and Tooling to Make Life Easier] - Koen Kooi - ELCE - [[Media:Openembedded.pdf]]

[http://files.meetup.com/1590495/openembedded.pdf OpenEmbedded An Embedded Linux Distribution Framework] - Khem Raj - [[Media:2010_Khem_Openembedded.pdf‎]]

Presentations

2010-11-22T13:40:46Z

Thebohemian: /* 2008 */

List of presentations talking of OpenEmbedded and bitbake :

== 2004 ==
[http://uuu.enseirb.fr/~kadionik/rmll2004/presentation/philip_blundell.pdf Introduction to the GPE Palmtop Environment and the OpenEmbedded Project] - Phil Blundell - RMLL - [[Media:philip_blundell.pdf]]

== 2005 ==
Building Embedded Linux Distributions with BitBake and OpenEmbedded - Michael 'Mickey' Lauer - FOSDEM - [[Media:FOSDEM2005.pdf]]

== 2006 ==
[http://svn.gnumonks.org/trunk/presentation/2006/oe_simputer-foss.in-2006/oe_simputer.pdf OpenEmbedded on the Simputer] - Harald Welte - FOSS.in - [[Media:oe_simputer.pdf]]

== 2007 ==
[http://www.power.org/devcon/07/Session_Downloads/PADC07_Koroneos_OE-presentation-final.pdf Introduction to OE] - Stelios S. Koroneos - PowerArchitecture Developer Conference - [[Media:PADC07_Koroneos_OE-presentation-final.pdf]]

[http://elinux.org/images/7/7c/Koen-ELC2007.pdf OpenEmbedded Easy QA, repeatability and retargetting] - Koen Kooi, Michael 'Mickey' Lauer, Richard 'RP' Purdie, Holger 'zecke' Freyther - ELC - [[Media:Koen-ELC2007.pdf]]

== 2008 ==
[http://www.celinux.org/elc08_presentations/mlocke-elc2008-oe.pdf OpenEmbedded for Product Development] - Matthew Locke - ELC - [[Media:mlocke-elc2008-oe.pdf]]

[http://cgit.openembedded.org/cgit.cgi/openembedded/plain/contrib/presentations/cross-compilation_with_OpenEmbedded_-_LinuxTag2008_-_Robert_Schuster.odp Cross Compilation With OpenEmbedded] - Robert Schuster - LinuxTag [[Media:Cross-compilation with OpenEmbedded - LinuxTag2008 - Robert Schuster.pdf]]

== 2009 ==
[http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFile&do=get&target=ELC.klaasvangend.openembedded.v4.pdf Top 3 pains in professional use of bitbake] - Klaas van Gend - ELC - [[Media:ELC2009Presentations.pdf]]

[http://marcin.juszkiewicz.com.pl/download/presentations/2009-SCW-Poky_Linux_and_OpenEmbedded_based_environment.pdf Poky Linux & OpenEmbedded based environment] - Marcin Juszkiewicz - ST-Ericsson Community Workshop - [[Media:2009-SCW-Poky_Linux_and_OpenEmbedded_based_environment.pdf]]

[http://elinux.org/images/a/ac/Hombourger-Why_oe_good_foundation_for_mv.odp Why OpenEmbedded proved a good foundation for MontaVista] - Cedric Hombourger - ELCE - [[Media:Hombourger-Why_oe_good_foundation_for_mv.pdf]]

[http://elinux.org/images/e/e4/Juszkiewicz-HackingWithOpenEmbedded.pdf Hacking with OpenEmbedded] - Marcin Juszkiewicz - ELCE - [[Media:Juszkiewicz-HackingWithOpenEmbedded.pdf]]

[ftp://ftp.koansoftware.com/public/talks/Confsl-2009/KaeilOS-Confsl09.pdf KaeilOS e Openembedded Linux - paper] - Marco Cavallini - [http://www.confsl.org/confsl09/ CONFSL] (presentation in Italian / presentazione in italiano) - [[Media:KaeilOS-Confsl09.pdf]]

[ftp://ftp.koansoftware.com/public/talks/Confsl-2009/KaeilOS-Confsl09-slides.pdf KaeilOS e Openembedded Linux - slides] - Marco Cavallini - [http://www.confsl.org/confsl09/ CONFSL] (presentation in Italian / presentazione in italiano) - [[Media:KaeilOS-Confsl09-slides.pdf]]

== 2010 ==
[http://files.meetup.com/1590495/openembedded.pdf Introduction to OpenEmbedded] - Khem Raj

[http://www.slideshare.net/zenlinux/openembedded OpenEmbedded] - Scott Garman - PLUG Advanced Topics

[http://www.solutionslinux.fr/upload/file/linux%202010/oe_presentation.pdf OpenEmbedded Une solution GNU/Linux pour l'embarqué] - Cyril Romain - Solutions Linux - (presentation in French / présentation en Français)

[http://elinux.org/images/7/73/Openembedded.pdf The State of OpenEmbedded and Tooling to Make Life Easier] - Koen Kooi - ELCE - [[Media:Openembedded.pdf]]

[http://files.meetup.com/1590495/openembedded.pdf OpenEmbedded An Embedded Linux Distribution Framework] - Khem Raj - [[Media:2010_Khem_Openembedded.pdf‎]]

Presentations

2010-11-22T13:38:41Z

Thebohemian: /* 2010 */

List of presentations talking of OpenEmbedded and bitbake :

== 2004 ==
[http://uuu.enseirb.fr/~kadionik/rmll2004/presentation/philip_blundell.pdf Introduction to the GPE Palmtop Environment and the OpenEmbedded Project] - Phil Blundell - RMLL - [[Media:philip_blundell.pdf]]

== 2005 ==
Building Embedded Linux Distributions with BitBake and OpenEmbedded - Michael 'Mickey' Lauer - FOSDEM - [[Media:FOSDEM2005.pdf]]

== 2006 ==
[http://svn.gnumonks.org/trunk/presentation/2006/oe_simputer-foss.in-2006/oe_simputer.pdf OpenEmbedded on the Simputer] - Harald Welte - FOSS.in - [[Media:oe_simputer.pdf]]

== 2007 ==
[http://www.power.org/devcon/07/Session_Downloads/PADC07_Koroneos_OE-presentation-final.pdf Introduction to OE] - Stelios S. Koroneos - PowerArchitecture Developer Conference - [[Media:PADC07_Koroneos_OE-presentation-final.pdf]]

[http://elinux.org/images/7/7c/Koen-ELC2007.pdf OpenEmbedded Easy QA, repeatability and retargetting] - Koen Kooi, Michael 'Mickey' Lauer, Richard 'RP' Purdie, Holger 'zecke' Freyther - ELC - [[Media:Koen-ELC2007.pdf]]

== 2008 ==
[http://www.celinux.org/elc08_presentations/mlocke-elc2008-oe.pdf OpenEmbedded for Product Development] - Matthew Locke - ELC - [[Media:mlocke-elc2008-oe.pdf]]
[http://cgit.openembedded.org/cgit.cgi/openembedded/plain/contrib/presentations/cross-compilation_with_OpenEmbedded_-_LinuxTag2008_-_Robert_Schuster.odp Cross Compilation With OpenEmbedded] - Robert Schuster - LinuxTag [[Media:Cross-compilation with OpenEmbedded - LinuxTag2008 - Robert Schuster.pdf]]

== 2009 ==
[http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFile&do=get&target=ELC.klaasvangend.openembedded.v4.pdf Top 3 pains in professional use of bitbake] - Klaas van Gend - ELC - [[Media:ELC2009Presentations.pdf]]

[http://marcin.juszkiewicz.com.pl/download/presentations/2009-SCW-Poky_Linux_and_OpenEmbedded_based_environment.pdf Poky Linux & OpenEmbedded based environment] - Marcin Juszkiewicz - ST-Ericsson Community Workshop - [[Media:2009-SCW-Poky_Linux_and_OpenEmbedded_based_environment.pdf]]

[http://elinux.org/images/a/ac/Hombourger-Why_oe_good_foundation_for_mv.odp Why OpenEmbedded proved a good foundation for MontaVista] - Cedric Hombourger - ELCE - [[Media:Hombourger-Why_oe_good_foundation_for_mv.pdf]]

[http://elinux.org/images/e/e4/Juszkiewicz-HackingWithOpenEmbedded.pdf Hacking with OpenEmbedded] - Marcin Juszkiewicz - ELCE - [[Media:Juszkiewicz-HackingWithOpenEmbedded.pdf]]

[ftp://ftp.koansoftware.com/public/talks/Confsl-2009/KaeilOS-Confsl09.pdf KaeilOS e Openembedded Linux - paper] - Marco Cavallini - [http://www.confsl.org/confsl09/ CONFSL] (presentation in Italian / presentazione in italiano) - [[Media:KaeilOS-Confsl09.pdf]]

[ftp://ftp.koansoftware.com/public/talks/Confsl-2009/KaeilOS-Confsl09-slides.pdf KaeilOS e Openembedded Linux - slides] - Marco Cavallini - [http://www.confsl.org/confsl09/ CONFSL] (presentation in Italian / presentazione in italiano) - [[Media:KaeilOS-Confsl09-slides.pdf]]

== 2010 ==
[http://files.meetup.com/1590495/openembedded.pdf Introduction to OpenEmbedded] - Khem Raj

[http://www.slideshare.net/zenlinux/openembedded OpenEmbedded] - Scott Garman - PLUG Advanced Topics

[http://www.solutionslinux.fr/upload/file/linux%202010/oe_presentation.pdf OpenEmbedded Une solution GNU/Linux pour l'embarqué] - Cyril Romain - Solutions Linux - (presentation in French / présentation en Français)

[http://elinux.org/images/7/73/Openembedded.pdf The State of OpenEmbedded and Tooling to Make Life Easier] - Koen Kooi - ELCE - [[Media:Openembedded.pdf]]

Presentations

2010-11-22T13:38:31Z

Thebohemian: /* 2010 */

List of presentations talking of OpenEmbedded and bitbake :

== 2004 ==
[http://uuu.enseirb.fr/~kadionik/rmll2004/presentation/philip_blundell.pdf Introduction to the GPE Palmtop Environment and the OpenEmbedded Project] - Phil Blundell - RMLL - [[Media:philip_blundell.pdf]]

== 2005 ==
Building Embedded Linux Distributions with BitBake and OpenEmbedded - Michael 'Mickey' Lauer - FOSDEM - [[Media:FOSDEM2005.pdf]]

== 2006 ==
[http://svn.gnumonks.org/trunk/presentation/2006/oe_simputer-foss.in-2006/oe_simputer.pdf OpenEmbedded on the Simputer] - Harald Welte - FOSS.in - [[Media:oe_simputer.pdf]]

== 2007 ==
[http://www.power.org/devcon/07/Session_Downloads/PADC07_Koroneos_OE-presentation-final.pdf Introduction to OE] - Stelios S. Koroneos - PowerArchitecture Developer Conference - [[Media:PADC07_Koroneos_OE-presentation-final.pdf]]

[http://elinux.org/images/7/7c/Koen-ELC2007.pdf OpenEmbedded Easy QA, repeatability and retargetting] - Koen Kooi, Michael 'Mickey' Lauer, Richard 'RP' Purdie, Holger 'zecke' Freyther - ELC - [[Media:Koen-ELC2007.pdf]]

== 2008 ==
[http://www.celinux.org/elc08_presentations/mlocke-elc2008-oe.pdf OpenEmbedded for Product Development] - Matthew Locke - ELC - [[Media:mlocke-elc2008-oe.pdf]]
[http://cgit.openembedded.org/cgit.cgi/openembedded/plain/contrib/presentations/cross-compilation_with_OpenEmbedded_-_LinuxTag2008_-_Robert_Schuster.odp Cross Compilation With OpenEmbedded] - Robert Schuster - LinuxTag [[Media:Cross-compilation with OpenEmbedded - LinuxTag2008 - Robert Schuster.pdf]]

== 2009 ==
[http://www.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFile&do=get&target=ELC.klaasvangend.openembedded.v4.pdf Top 3 pains in professional use of bitbake] - Klaas van Gend - ELC - [[Media:ELC2009Presentations.pdf]]

[http://marcin.juszkiewicz.com.pl/download/presentations/2009-SCW-Poky_Linux_and_OpenEmbedded_based_environment.pdf Poky Linux & OpenEmbedded based environment] - Marcin Juszkiewicz - ST-Ericsson Community Workshop - [[Media:2009-SCW-Poky_Linux_and_OpenEmbedded_based_environment.pdf]]

[http://elinux.org/images/a/ac/Hombourger-Why_oe_good_foundation_for_mv.odp Why OpenEmbedded proved a good foundation for MontaVista] - Cedric Hombourger - ELCE - [[Media:Hombourger-Why_oe_good_foundation_for_mv.pdf]]

[http://elinux.org/images/e/e4/Juszkiewicz-HackingWithOpenEmbedded.pdf Hacking with OpenEmbedded] - Marcin Juszkiewicz - ELCE - [[Media:Juszkiewicz-HackingWithOpenEmbedded.pdf]]

[ftp://ftp.koansoftware.com/public/talks/Confsl-2009/KaeilOS-Confsl09.pdf KaeilOS e Openembedded Linux - paper] - Marco Cavallini - [http://www.confsl.org/confsl09/ CONFSL] (presentation in Italian / presentazione in italiano) - [[Media:KaeilOS-Confsl09.pdf]]

[ftp://ftp.koansoftware.com/public/talks/Confsl-2009/KaeilOS-Confsl09-slides.pdf KaeilOS e Openembedded Linux - slides] - Marco Cavallini - [http://www.confsl.org/confsl09/ CONFSL] (presentation in Italian / presentazione in italiano) - [[Media:KaeilOS-Confsl09-slides.pdf]]

== 2010 ==
[http://files.meetup.com/1590495/openembedded.pdf Introduction to OpenEmbedded] - Khem Raj

[http://www.slideshare.net/zenlinux/openembedded OpenEmbedded] - Scott Garman - PLUG Advanced Topics

[http://www.solutionslinux.fr/upload/file/linux%202010/oe_presentation.pdf OpenEmbedded Une solution GNU/Linux pour l'embarqué] - Cyril Romain - Solutions Linux - (presentation in French / présentation en Français)

[http://elinux.org/images/7/73/Openembedded.pdf The State of OpenEmbedded and Tooling to Make Life Easier] - Koen Kooi - ELCE - [[Media:Openembedded.pdf]]

Oedem/2010

2010-10-26T06:49:37Z

Thebohemian:

OpenEmbedded Developers' Meeting 2010 will be in Cambridge, UK on the 29th and 30th of October. This is after http://www.embeddedlinuxconference.com/elc_europe10/index.html and will be held in the same place, the University Arms Hotel (http://www.devere.co.uk/our-locations/university-arms).

All developers and other interested parties are welcome.

== Location ==
Darwin Suite in the [http://www.devere.co.uk/our-locations/university-arms.html University Arms Hotel] Cambridge, England.

== Registration ==

Due to restricted space at the venue, the number of attendees is limited to 30 poeple.

== Agenda Suggestions ==

* FM: I would like to suggest a discussion on recipe quality and how to improve it. I must say that I am somewhat disappointed by the number of recipes that do not fetch or do not patch. How are we going to handle this
* FM: related to the previous: how to deal with orphaned recipes, distros and machines
* FM: suggest to re-institute the MAINTAINERS field, at least for distro and machine conf files but preferably also in recipes. Currently it is often not clear who maintains what
* FM: review/commit/revert policy (e.g. formalize the suggestion that NAKs need to be motivated and that submitted patches can be pushed if there is no neg feedback within say 2 weeks (even if there is no feedback at all).
* FM: maybe discuss the testing branch/procedures
* FM: usage of DEFAULT_PREFERENCE = "-1" (and more concrete: the creation of new recipes with DP = -1, that never seem to loose its DP)
*Khem: Libtool 2.4 upgrade.
*Khem: bitbake world. What do we do ?
*Khem: patchwork workflow
*Khem: Security updates how to handle
*Khem: Make LICENSE field mandatory in recipes
*Khem: Time based releases ( one a year)
*Hrw: recipes/ subdirectories (all "inherit opie" or "inherit palmtop" -> recipes/opie/ dir etc)
*RP: srctree, srcrev mess, pain with linux-wrs - time to rework the scm fetchers?
*RP: Proposal - merge fetch and unpack tasks
*LW: the recipe owner needs to well understand class implementation details, no consistency, no documentation, and subject to change.
*LW: BB2 and OE2 from scratch?

== Agenda ==

=== Friday ===

====OpenEmbedded eV General Assembly====

This is the formal eV meeting. Principal topics are financial reports, the board election, and voting in of new members.
...

[[GA2010]]

=== Saturday ===

...

==Travel==

London Stansted airport is the nearest to Cambridge with regular service. (There is a small airport in Cambridge itself but I don't think any scheduled airlines operate from there anymore.)

For those travelling from Europe, Stansted is about a 30-minute train ride from Cambridge city centre and is served by Air Berlin, Ryanair and Germanwings among others. Luton airport is about 1 hour away by bus and is served by Easyjet.

For those travelling from further away, most long-haul flights arrive at Heathrow or Gatwick airports (although there is some transatlantic service into Stansted). Both Heathrow and Gatwick are about 2 hours from Cambridge by train or bus: the train is quicker but involves several changes in London, whereas the bus is slow but cheaper and less complicated.

If arriving at LHR airport, take the Piccadilly line from the Underground station and ride it all the way to Kings Cross St Pancras. Ascend to street level, follow signs to Kings Cross mainline station (not St Pancras: the two stations are different although they share a subway stop) and then look for trains to Cambridge or Kings Lynn on the departure board. There are usually two fast services and two slow services to Cambridge per hour: the slow trains are often overtaken by the fast ones en route so it may be best to wait for a fast service even if this is not the next to depart.

If arriving at LCY, take the DLR to Bank, then change to the Northern Line northbound. From Kings Cross St Pancras, proceed as for LHR, above.

http://nationalrail.co.uk

http://nationalexpress.co.uk/

Alternatively you can take the Eurostar to London St Pancras, which is 50 minutes from Cambridge by train.

See also the ELCE10 website for some travel informations: http://www.embeddedlinuxconference.com/elc_europe10/hotel.html

==Accommodation==

The nearest full-service hotel is ...

Cheapest accomodation is ...

==Food and drink==

...

==Attending for sure==

# Philip Balister
# Florian Boor
# Denys Dmytriyenko
# Mark Hatle
# Koen Kooi
# Fabio Mauri (friday until 15:00)
# Frans Meulenbroeks
# Jeff Polk
# Richard Purdie
# Raffaele Recalcati (friday until 15:00)
# Stefan Schmidt
# Leon Woestenberg
# Saul Wold
# Davide Bonfanti (only friday until 15:00)

==Attending not yet sure==

...

==Won't be able to attend==
# Michael Lauer -- really sorry :/
# Robert Schuster

[[Category:OEDEM]]

Java

2010-06-30T11:18:58Z

Thebohemian: typo

This page is here to answer all things Java related to OpenEmbedded.

=State of support=
==Virtual machine and class library==
Currently (since September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with either Cacao or Hotspot/Zero as the runtime) is available through the Jalimo overlay. This will be merged soon. Future additions will also include Hotspot/Shark which is a variant of Hotspot using a generic JIT compiler based on LLVM.

It is planned to use OpenJDK as the native Java runtime. That way Java packages will be compiled against this library.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+), a large bunch of the Jakarta commons libraries and stuff like BSF, POI, log4j, logkit and ORO are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you should prefer the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or a J2SE-like environment (JamVM/Cacao and GNU Classpath or any of the OpenJDK variants). If PhoneME is installed it is preferred.

==OpenJDK==
OpenJDK is the name of the F/OSS Java stack from Sun. It normally consists of the class library (often referred to as OpenJDK as well), the Hotspot runtime and many many tools (e.g. javah, rmic, javaws). OpenEmbedded support building OpenJDK with the CacaoVM. This gives many platforms which Hotspot does not directly support a fast Java VM. Please note that Cacao lacks many advanced features like JVMTI. Your only other option is the Zero port of Hotspot. Zero is a C++-based interpreter and can be run on any platform supporting libffi. This gives you a featurefull VM for many platforms at the cost of performance.

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=== Ant ===
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Despite all this troubles Ant (1.7.1) is available and supported as an application which can be run from build recipes.

=A word of warning=
Every so often people on the net suggest that in order to get Java stuff running in OpenEmbedded, you need to install a JDK, Kaffe or Jikes and then make modifications to the PATH variable in order to allow the
build use the runtime or compiler. '''These suggestions are wrong!''' The Java support in OpenEmbedded is (and strives to stay) ''completely'' self-hosting. You should not need a single bit of Java on your host OS to get the Java recipes to compile.

On the other hand the Java support in OE can happily co-exist with whatever 'java', 'javac' and other tools you might have installed in your OS. Due to the nature of some configure scripts, those will sometimes find these executables but in the end only the tools from OpenEmbedded's staging directory will be used (if not its a bug that needs to be fixed).

Please note that problem reports that are caused by pulling in native Java tools (those from your OS) into the OpenEmbedded build process will be closed as invalid. The reason is that the recipes are only supposed to work with the built-in toolchain.

=Configuring (add info about what and where)=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following line to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi. If you desperately need jamvm on your platform consider installing the development package for libffi of your distro.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Target virtual machine ==
'''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering multiple J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao, phoneme or openjdk recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

Additionally OpenJDK can be built using either Cacao (same properties as above) or the Zero port of Hotspot. Zero is an C++-based interpreter capable of running on any platform that is supported by libffi.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao, JamVM or OpenJDK packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

=Writing a Java recipe=
This section is going to tell you, how to write a proper recipe to build a Java library or program.

'''At the moment this is a stub and you will only find some scattered information which at a later point will be merged into a consistent whole.'''

==java-native.bbclass==
If you use the ''java-library'' bbclass in a recipe ''foo'' and generate a native variant (e.g. ''foo-native'') you should use

inherit java-native

instead of ''native''. By doing so, you make sure, that any jars created by the recipe are properly installed into staging.

==ant-native==
If you need Ant to build your recipe add ''ant-native'' to your recipes dependencies. This will allow you to call the built-in Ant executable.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the releases that appear to be stable.

PREFERRED_VERSION_jamvm-native = "1.5.3"
PREFERRED_VERSION_classpath-native = "0.98"

For the target device:

PREFERRED_VERSION_jamvm = "1.5.2"
PREFERRED_VERSION_classpath = "0.98"

=== cacao[-native] and classpath[-native] ===
These releases appear to be stable:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

For the target device take these:

PREFERRED_VERSION_cacao = "0.99.4"
PREFERRED_VERSION_classpath = "0.98"

=== libecj-bootstrap ===

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

Since December 2008 OpenJDK + Cacao can be crosscompiled with OpenEmbedded as demonstrated by Robert Schuster!
Check out http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/ and the answers http://rschuster.blogs.evolvis.org/2008/12/23/comments-on-latest-post-on-openjdk/

==Ant integration for build recipes==
Although ''ant'' can be used as a standalone tool there is no direct support for it in the recipe. E.g. the Debian buildsystem (CDBS) has support classes that can be used for Ant-based Java sourcepackages. It would be nice to have this too for OpenEmbedded.

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

== Q: I need to solve a specific Java problem in OE and want to throw money at this. Whom can I contact? ==
The [http://jalimo.org Jalimo] project has done a lot of Java work in OE and are available for contract work. You can also ask for experienced devs on the openembedded-devel mailing list.

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Template:Main page/news

2010-06-11T06:20:59Z

Thebohemian:

'''Recent News:'''
* '''''2010-06-09:''''' OpenEmbedded in Berlin! Meet us at our booth at [http://www.linuxtag.org LinuxTag 2010].
* '''''2010-02-06:''''' OpenEmbedded at [http://fosdem.org FOSDEM'10] - We have a booth at Europe's finest F/OSS event. [[Fosdem 2010|See you in Brussels]]!
See [[NewsArchive|News Archive]] for older news.

Template:Main page/news

2010-06-11T06:19:35Z

Thebohemian:

'''Recent News:'''
* '''''2010-06-09:''''' OpenEmbedded at [http://www.linuxtag.org LinuxTag'10] - Visit our booth at this F/OSS event in Berlin.
* '''''2010-02-06:''''' OpenEmbedded at [http://fosdem.org FOSDEM'10] - We have a booth at Europe's finest F/OSS event. [[Fosdem 2010|See you in Brussels]]!
See [[NewsArchive|News Archive]] for older news.

NewsArchive

2010-06-11T06:19:18Z

Thebohemian:

'''Older News:'''
* '''''2009-11-07:''''' [[Oedem/2009|Openembedded Developer Meeting 2009]] in Cambridge, UK
* '''''2009-08-12:''''' Openembedded gains ability to create [http://docs.openembedded.org/usermanual/html/ch05s08.html Qt Embedded Linux SDK]
* '''''2009-05-27:''''' Palm is using Openembedded to build Palm [http://developer.palm.com/ webOS]
* '''''2009-05-27:''''' MontaVista is using OpenEmbedded in their [http://mvista.com/product_detail_mvl6.php MontaVista Linux 6 product]
* '''''2009-03-31:''''' OpenEmbedded opens the stable/2009 [[Stable]] branch. Special procedure is applied to it which results in better support for our downstream users.
* '''''2009-03-24:''''' [http://www.foss-aalborg.dk/ FOSS Aalborg] in Aalborg, Denmark, with a focus on embedded software. [[User:Mickey|Mickey]] gives a talk about OpenEmbedded.
* '''''2009-03-06:''''' [http://www.alwaysinnovating.com Always Innovating] is using OE to build software for their Touch Book.
* '''''2009-02-19:''''' [http://koansoftware.com/index_en.php KOAN Software] company [http://thread.gmane.org/gmane.comp.handhelds.openembedded/21188 announces] it's [http://kaeilos.com/ KaeilOS] distribution will join the OpenEmbedded project.
* '''''2009-02-10:''''' OE has a new Logo -- Many thanks to [http://buglabs.com Bug Labs] who funded the logo development, and [http://mateozlatar.com/ Mateo Zlatar] for designing the logo.

Java

2009-06-19T11:57:30Z

Thebohemian: /* FAQ */

This page is here to answer all things Java related to OpenEmbedded.

=State of support=
==Virtual machine and class library==
Currently (since September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with either Cacao or Hotspot/Zero as the runtime) is available through the Jalimo overlay. This will be merged soon. Future additions will also include Hotspot/Shark which is a variant of Hotspot using a generic JIT compiler based on LLVM.

It is planned to use OpenJDK as the native Java runtime. That way Java packages will be compiled against this library.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you should prefer the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or a J2SE-like environment (JamVM/Cacao and GNU Classpath or any of the OpenJDK variants). If PhoneME is installed it is preferred.

==OpenJDK==
OpenJDK is the name of the F/OSS Java stack from Sun. It normally consists of the class library (often referred to as OpenJDK as well), the Hotspot runtime and many many tools (e.g. javah, rmic, javaws). OpenEmbedded support building OpenJDK with the CacaoVM. This gives many platforms which Hotspot does not directly support a fast Java VM. Please note that Cacao lacks many advanced features like JVMTI. Your only other option is the Zero port of Hotspot. Zero is a C++-based interpreter and can be run on any platform supporting libffi. This gives you a featurefull VM for many platforms at the cost of performance.

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=A word of warning=
Every so often people on the net suggest that in order to get Java stuff running in OpenEmbedded, you need to install a JDK, Kaffe or Jikes and then make modifications to the PATH variable in order to allow the
build use the runtime or compiler. '''These suggestions are wrong!''' The Java support in OpenEmbedded is (and strives to stay) ''completely'' self-hosting. You should not need a single bit of Java on your host OS to get the Java recipes to compile.

On the other hand the Java support in OE can happily co-exist with whatever 'java', 'javac' and other tools you might have installed in your OS. Due to the nature of some configure scripts, those will sometimes find these executables but in the end only the tools from OpenEmbedded's staging directory will be used (if not its a bug that needs to be fixed).

Please note that problem reports that are caused by pulling in native Java tools (those from your OS) into the OpenEmbedded build process will be closed as invalid. The reason is that the recipes are only supposed to work with the built-in toolchain.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi. If you desperately need jamvm on your platform consider installing the development package for libffi of your distro.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Target virtual machine ==
'''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering multiple J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao, phoneme or openjdk recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

Additionally OpenJDK can be built using either Cacao (same properties as above) or the Zero port of Hotspot. Zero is an C++-based interpreter capable of running on any platform that is supported by libffi.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao, JamVM or OpenJDK packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

=Writing a Java recipe=
This section is going to tell you, how to write a proper recipe to build a Java library or program.

'''At the moment this is a stub and you will only find some scattered information which at a later point will be merged into a consistent whole.'''

==java-native.bbclass==
If you use the ''java-library'' bbclass in a recipe ''foo'' and generate a native variant (e.g. ''foo-native'') you should use

inherit java-native

instead of ''native''. By doing so, you make sure, that any jars created by the recipe are properly installed into staging.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the releases that appear to be stable. Highly recommended on AMD64 systems where Cacao likes to fail:

PREFERRED_VERSION_jamvm-native = "1.5.3"
PREFERRED_VERSION_classpath-native = "0.98"

For the target device:

PREFERRED_VERSION_jamvm = "1.5.2"
PREFERRED_VERSION_classpath = "0.98"

=== cacao[-native] and classpath[-native] ===
These releases appear to be stable:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

For the target device take these:

PREFERRED_VERSION_cacao = "0.99.4"
PREFERRED_VERSION_classpath = "0.98"

=== libecj-bootstrap ===

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

Since December 2008 OpenJDK + Cacao can be crosscompiled with OpenEmbedded as demonstrated by Robert Schuster!
Check out http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/ and the answers http://rschuster.blogs.evolvis.org/2008/12/23/comments-on-latest-post-on-openjdk/

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

== Q: I need to solve a specific Java problem in OE and want to throw money at this. Whom can I contact? ==
The Java support in OpenEmbedded is provided by the [http://jalimo.org Jalimo] project. Either follow the 'commercial support' link on the home page or ask for help on the openembedded-devel mailing list.

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2009-06-19T11:53:24Z

Thebohemian: /* A word of warning */

This page is here to answer all things Java related to OpenEmbedded.

=State of support=
==Virtual machine and class library==
Currently (since September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with either Cacao or Hotspot/Zero as the runtime) is available through the Jalimo overlay. This will be merged soon. Future additions will also include Hotspot/Shark which is a variant of Hotspot using a generic JIT compiler based on LLVM.

It is planned to use OpenJDK as the native Java runtime. That way Java packages will be compiled against this library.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you should prefer the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or a J2SE-like environment (JamVM/Cacao and GNU Classpath or any of the OpenJDK variants). If PhoneME is installed it is preferred.

==OpenJDK==
OpenJDK is the name of the F/OSS Java stack from Sun. It normally consists of the class library (often referred to as OpenJDK as well), the Hotspot runtime and many many tools (e.g. javah, rmic, javaws). OpenEmbedded support building OpenJDK with the CacaoVM. This gives many platforms which Hotspot does not directly support a fast Java VM. Please note that Cacao lacks many advanced features like JVMTI. Your only other option is the Zero port of Hotspot. Zero is a C++-based interpreter and can be run on any platform supporting libffi. This gives you a featurefull VM for many platforms at the cost of performance.

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=A word of warning=
Every so often people on the net suggest that in order to get Java stuff running in OpenEmbedded, you need to install a JDK, Kaffe or Jikes and then make modifications to the PATH variable in order to allow the
build use the runtime or compiler. '''These suggestions are wrong!''' The Java support in OpenEmbedded is (and strives to stay) ''completely'' self-hosting. You should not need a single bit of Java on your host OS to get the Java recipes to compile.

On the other hand the Java support in OE can happily co-exist with whatever 'java', 'javac' and other tools you might have installed in your OS. Due to the nature of some configure scripts, those will sometimes find these executables but in the end only the tools from OpenEmbedded's staging directory will be used (if not its a bug that needs to be fixed).

Please note that problem reports that are caused by pulling in native Java tools (those from your OS) into the OpenEmbedded build process will be closed as invalid. The reason is that the recipes are only supposed to work with the built-in toolchain.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi. If you desperately need jamvm on your platform consider installing the development package for libffi of your distro.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Target virtual machine ==
'''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering multiple J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao, phoneme or openjdk recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

Additionally OpenJDK can be built using either Cacao (same properties as above) or the Zero port of Hotspot. Zero is an C++-based interpreter capable of running on any platform that is supported by libffi.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao, JamVM or OpenJDK packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

=Writing a Java recipe=
This section is going to tell you, how to write a proper recipe to build a Java library or program.

'''At the moment this is a stub and you will only find some scattered information which at a later point will be merged into a consistent whole.'''

==java-native.bbclass==
If you use the ''java-library'' bbclass in a recipe ''foo'' and generate a native variant (e.g. ''foo-native'') you should use

inherit java-native

instead of ''native''. By doing so, you make sure, that any jars created by the recipe are properly installed into staging.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the releases that appear to be stable. Highly recommended on AMD64 systems where Cacao likes to fail:

PREFERRED_VERSION_jamvm-native = "1.5.3"
PREFERRED_VERSION_classpath-native = "0.98"

For the target device:

PREFERRED_VERSION_jamvm = "1.5.2"
PREFERRED_VERSION_classpath = "0.98"

=== cacao[-native] and classpath[-native] ===
These releases appear to be stable:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

For the target device take these:

PREFERRED_VERSION_cacao = "0.99.4"
PREFERRED_VERSION_classpath = "0.98"

=== libecj-bootstrap ===

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

Since December 2008 OpenJDK + Cacao can be crosscompiled with OpenEmbedded as demonstrated by Robert Schuster!
Check out http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/ and the answers http://rschuster.blogs.evolvis.org/2008/12/23/comments-on-latest-post-on-openjdk/

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2009-06-19T11:53:08Z

Thebohemian: /* A word of warning */

This page is here to answer all things Java related to OpenEmbedded.

=State of support=
==Virtual machine and class library==
Currently (since September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with either Cacao or Hotspot/Zero as the runtime) is available through the Jalimo overlay. This will be merged soon. Future additions will also include Hotspot/Shark which is a variant of Hotspot using a generic JIT compiler based on LLVM.

It is planned to use OpenJDK as the native Java runtime. That way Java packages will be compiled against this library.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you should prefer the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or a J2SE-like environment (JamVM/Cacao and GNU Classpath or any of the OpenJDK variants). If PhoneME is installed it is preferred.

==OpenJDK==
OpenJDK is the name of the F/OSS Java stack from Sun. It normally consists of the class library (often referred to as OpenJDK as well), the Hotspot runtime and many many tools (e.g. javah, rmic, javaws). OpenEmbedded support building OpenJDK with the CacaoVM. This gives many platforms which Hotspot does not directly support a fast Java VM. Please note that Cacao lacks many advanced features like JVMTI. Your only other option is the Zero port of Hotspot. Zero is a C++-based interpreter and can be run on any platform supporting libffi. This gives you a featurefull VM for many platforms at the cost of performance.

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=A word of warning=
Every so often people on the net suggest that in order to get Java stuff running in OpenEmbedded, you need to install a JDK, Kaffe or Jikes and then make modifications to the PATH variable in order to allow the
build use the runtime or compiler. These suggestions are ''wrong''! The Java support in OpenEmbedded is (and strives to stay) ''completely'' self-hosting. You should not need a single bit of Java on your host OS to get the Java recipes to compile.

On the other hand the Java support in OE can happily co-exist with whatever 'java', 'javac' and other tools you might have installed in your OS. Due to the nature of some configure scripts, those will sometimes find these executables but in the end only the tools from OpenEmbedded's staging directory will be used (if not its a bug that needs to be fixed).

Please note that problem reports that are caused by pulling in native Java tools (those from your OS) into the OpenEmbedded build process will be closed as invalid. The reason is that the recipes are only supposed to work with the built-in toolchain.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi. If you desperately need jamvm on your platform consider installing the development package for libffi of your distro.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Target virtual machine ==
'''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering multiple J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao, phoneme or openjdk recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

Additionally OpenJDK can be built using either Cacao (same properties as above) or the Zero port of Hotspot. Zero is an C++-based interpreter capable of running on any platform that is supported by libffi.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao, JamVM or OpenJDK packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

=Writing a Java recipe=
This section is going to tell you, how to write a proper recipe to build a Java library or program.

'''At the moment this is a stub and you will only find some scattered information which at a later point will be merged into a consistent whole.'''

==java-native.bbclass==
If you use the ''java-library'' bbclass in a recipe ''foo'' and generate a native variant (e.g. ''foo-native'') you should use

inherit java-native

instead of ''native''. By doing so, you make sure, that any jars created by the recipe are properly installed into staging.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the releases that appear to be stable. Highly recommended on AMD64 systems where Cacao likes to fail:

PREFERRED_VERSION_jamvm-native = "1.5.3"
PREFERRED_VERSION_classpath-native = "0.98"

For the target device:

PREFERRED_VERSION_jamvm = "1.5.2"
PREFERRED_VERSION_classpath = "0.98"

=== cacao[-native] and classpath[-native] ===
These releases appear to be stable:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

For the target device take these:

PREFERRED_VERSION_cacao = "0.99.4"
PREFERRED_VERSION_classpath = "0.98"

=== libecj-bootstrap ===

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

Since December 2008 OpenJDK + Cacao can be crosscompiled with OpenEmbedded as demonstrated by Robert Schuster!
Check out http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/ and the answers http://rschuster.blogs.evolvis.org/2008/12/23/comments-on-latest-post-on-openjdk/

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2009-06-19T11:52:47Z

Thebohemian: /* A word of warning */

This page is here to answer all things Java related to OpenEmbedded.

=State of support=
==Virtual machine and class library==
Currently (since September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with either Cacao or Hotspot/Zero as the runtime) is available through the Jalimo overlay. This will be merged soon. Future additions will also include Hotspot/Shark which is a variant of Hotspot using a generic JIT compiler based on LLVM.

It is planned to use OpenJDK as the native Java runtime. That way Java packages will be compiled against this library.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you should prefer the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or a J2SE-like environment (JamVM/Cacao and GNU Classpath or any of the OpenJDK variants). If PhoneME is installed it is preferred.

==OpenJDK==
OpenJDK is the name of the F/OSS Java stack from Sun. It normally consists of the class library (often referred to as OpenJDK as well), the Hotspot runtime and many many tools (e.g. javah, rmic, javaws). OpenEmbedded support building OpenJDK with the CacaoVM. This gives many platforms which Hotspot does not directly support a fast Java VM. Please note that Cacao lacks many advanced features like JVMTI. Your only other option is the Zero port of Hotspot. Zero is a C++-based interpreter and can be run on any platform supporting libffi. This gives you a featurefull VM for many platforms at the cost of performance.

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=A word of warning=
Every so often people on the net suggest that in order to get Java stuff running in OpenEmbedded, you need to install a JDK, Kaffe or Jikes and then making modifications to the PATH variable in order to allow the
build use the runtime or compiler. These suggestions are ''wrong''! The Java support in OpenEmbedded is (and strives to stay) ''completely'' self-hosting. You should not need a single bit of Java on your host OS to get the Java recipes to compile.

On the other hand the Java support in OE can happily co-exist with whatever 'java', 'javac' and other tools you might have installed in your OS. Due to the nature of some configure scripts, those will sometimes find these executables but in the end only the tools from OpenEmbedded's staging directory will be used (if not its a bug that needs to be fixed).

Please note that problem reports that are caused by pulling in native Java tools (those from your OS) into the OpenEmbedded build process will be closed as invalid. The reason is that the recipes are only supposed to work with the built-in toolchain.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi. If you desperately need jamvm on your platform consider installing the development package for libffi of your distro.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Target virtual machine ==
'''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering multiple J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao, phoneme or openjdk recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

Additionally OpenJDK can be built using either Cacao (same properties as above) or the Zero port of Hotspot. Zero is an C++-based interpreter capable of running on any platform that is supported by libffi.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao, JamVM or OpenJDK packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

=Writing a Java recipe=
This section is going to tell you, how to write a proper recipe to build a Java library or program.

'''At the moment this is a stub and you will only find some scattered information which at a later point will be merged into a consistent whole.'''

==java-native.bbclass==
If you use the ''java-library'' bbclass in a recipe ''foo'' and generate a native variant (e.g. ''foo-native'') you should use

inherit java-native

instead of ''native''. By doing so, you make sure, that any jars created by the recipe are properly installed into staging.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the releases that appear to be stable. Highly recommended on AMD64 systems where Cacao likes to fail:

PREFERRED_VERSION_jamvm-native = "1.5.3"
PREFERRED_VERSION_classpath-native = "0.98"

For the target device:

PREFERRED_VERSION_jamvm = "1.5.2"
PREFERRED_VERSION_classpath = "0.98"

=== cacao[-native] and classpath[-native] ===
These releases appear to be stable:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

For the target device take these:

PREFERRED_VERSION_cacao = "0.99.4"
PREFERRED_VERSION_classpath = "0.98"

=== libecj-bootstrap ===

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

Since December 2008 OpenJDK + Cacao can be crosscompiled with OpenEmbedded as demonstrated by Robert Schuster!
Check out http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/ and the answers http://rschuster.blogs.evolvis.org/2008/12/23/comments-on-latest-post-on-openjdk/

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2009-06-19T11:52:12Z

Thebohemian: /* J2ME MIDP2.0 */

This page is here to answer all things Java related to OpenEmbedded.

=State of support=
==Virtual machine and class library==
Currently (since September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with either Cacao or Hotspot/Zero as the runtime) is available through the Jalimo overlay. This will be merged soon. Future additions will also include Hotspot/Shark which is a variant of Hotspot using a generic JIT compiler based on LLVM.

It is planned to use OpenJDK as the native Java runtime. That way Java packages will be compiled against this library.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you should prefer the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or a J2SE-like environment (JamVM/Cacao and GNU Classpath or any of the OpenJDK variants). If PhoneME is installed it is preferred.

==OpenJDK==
OpenJDK is the name of the F/OSS Java stack from Sun. It normally consists of the class library (often referred to as OpenJDK as well), the Hotspot runtime and many many tools (e.g. javah, rmic, javaws). OpenEmbedded support building OpenJDK with the CacaoVM. This gives many platforms which Hotspot does not directly support a fast Java VM. Please note that Cacao lacks many advanced features like JVMTI. Your only other option is the Zero port of Hotspot. Zero is a C++-based interpreter and can be run on any platform supporting libffi. This gives you a featurefull VM for many platforms at the cost of performance.

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=A word of warning=
Every so often people on the net suggest that in order to get Java stuff running in OpenEmbedded requires installing a JDK, Kaffe or Jikes and then making modifications to the PATH variable in order to allow the
build use the runtime or compiler. These suggestions are ''wrong''! The Java support in OpenEmbedded is (and strives to stay) ''completely'' self-hosting. You should not need a single bit of Java on your host OS to get the Java recipes to compile.

On the other hand the Java support in OE can happily co-exist with whatever 'java', 'javac' and other tools you might have installed in your OS. Due to the nature of some configure scripts, those will sometimes find these executables but in the end only the tools from OpenEmbedded's staging directory will be used (if not its a bug that needs to be fixed).

Please note that problem reports that are caused by pulling in native Java tools (those from your OS) into the OpenEmbedded build process will be closed as invalid. The reason is that the recipes are only supposed to work with the built-in toolchain.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi. If you desperately need jamvm on your platform consider installing the development package for libffi of your distro.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Target virtual machine ==
'''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering multiple J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao, phoneme or openjdk recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

Additionally OpenJDK can be built using either Cacao (same properties as above) or the Zero port of Hotspot. Zero is an C++-based interpreter capable of running on any platform that is supported by libffi.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao, JamVM or OpenJDK packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

=Writing a Java recipe=
This section is going to tell you, how to write a proper recipe to build a Java library or program.

'''At the moment this is a stub and you will only find some scattered information which at a later point will be merged into a consistent whole.'''

==java-native.bbclass==
If you use the ''java-library'' bbclass in a recipe ''foo'' and generate a native variant (e.g. ''foo-native'') you should use

inherit java-native

instead of ''native''. By doing so, you make sure, that any jars created by the recipe are properly installed into staging.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the releases that appear to be stable. Highly recommended on AMD64 systems where Cacao likes to fail:

PREFERRED_VERSION_jamvm-native = "1.5.3"
PREFERRED_VERSION_classpath-native = "0.98"

For the target device:

PREFERRED_VERSION_jamvm = "1.5.2"
PREFERRED_VERSION_classpath = "0.98"

=== cacao[-native] and classpath[-native] ===
These releases appear to be stable:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

For the target device take these:

PREFERRED_VERSION_cacao = "0.99.4"
PREFERRED_VERSION_classpath = "0.98"

=== libecj-bootstrap ===

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

Since December 2008 OpenJDK + Cacao can be crosscompiled with OpenEmbedded as demonstrated by Robert Schuster!
Check out http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/ and the answers http://rschuster.blogs.evolvis.org/2008/12/23/comments-on-latest-post-on-openjdk/

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2009-06-19T11:50:25Z

Thebohemian: /* PhoneME Advanced */

This page is here to answer all things Java related to OpenEmbedded.

=State of support=
==Virtual machine and class library==
Currently (since September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with either Cacao or Hotspot/Zero as the runtime) is available through the Jalimo overlay. This will be merged soon. Future additions will also include Hotspot/Shark which is a variant of Hotspot using a generic JIT compiler based on LLVM.

It is planned to use OpenJDK as the native Java runtime. That way Java packages will be compiled against this library.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you should prefer the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or JamVM/Cacao + GNU Classpath. If PhoneME is installed it is preferred

==OpenJDK==
OpenJDK is the name of the F/OSS Java stack from Sun. It normally consists of the class library (often referred to as OpenJDK as well), the Hotspot runtime and many many tools (e.g. javah, rmic, javaws). OpenEmbedded support building OpenJDK with the CacaoVM. This gives many platforms which Hotspot does not directly support a fast Java VM. Please note that Cacao lacks many advanced features like JVMTI. Your only other option is the Zero port of Hotspot. Zero is a C++-based interpreter and can be run on any platform supporting libffi. This gives you a featurefull VM for many platforms at the cost of performance.

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=A word of warning=
Every so often people on the net suggest that in order to get Java stuff running in OpenEmbedded requires installing a JDK, Kaffe or Jikes and then making modifications to the PATH variable in order to allow the
build use the runtime or compiler. These suggestions are ''wrong''! The Java support in OpenEmbedded is (and strives to stay) ''completely'' self-hosting. You should not need a single bit of Java on your host OS to get the Java recipes to compile.

On the other hand the Java support in OE can happily co-exist with whatever 'java', 'javac' and other tools you might have installed in your OS. Due to the nature of some configure scripts, those will sometimes find these executables but in the end only the tools from OpenEmbedded's staging directory will be used (if not its a bug that needs to be fixed).

Please note that problem reports that are caused by pulling in native Java tools (those from your OS) into the OpenEmbedded build process will be closed as invalid. The reason is that the recipes are only supposed to work with the built-in toolchain.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi. If you desperately need jamvm on your platform consider installing the development package for libffi of your distro.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Target virtual machine ==
'''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering multiple J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao, phoneme or openjdk recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

Additionally OpenJDK can be built using either Cacao (same properties as above) or the Zero port of Hotspot. Zero is an C++-based interpreter capable of running on any platform that is supported by libffi.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao, JamVM or OpenJDK packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

=Writing a Java recipe=
This section is going to tell you, how to write a proper recipe to build a Java library or program.

'''At the moment this is a stub and you will only find some scattered information which at a later point will be merged into a consistent whole.'''

==java-native.bbclass==
If you use the ''java-library'' bbclass in a recipe ''foo'' and generate a native variant (e.g. ''foo-native'') you should use

inherit java-native

instead of ''native''. By doing so, you make sure, that any jars created by the recipe are properly installed into staging.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the releases that appear to be stable. Highly recommended on AMD64 systems where Cacao likes to fail:

PREFERRED_VERSION_jamvm-native = "1.5.3"
PREFERRED_VERSION_classpath-native = "0.98"

For the target device:

PREFERRED_VERSION_jamvm = "1.5.2"
PREFERRED_VERSION_classpath = "0.98"

=== cacao[-native] and classpath[-native] ===
These releases appear to be stable:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

For the target device take these:

PREFERRED_VERSION_cacao = "0.99.4"
PREFERRED_VERSION_classpath = "0.98"

=== libecj-bootstrap ===

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

Since December 2008 OpenJDK + Cacao can be crosscompiled with OpenEmbedded as demonstrated by Robert Schuster!
Check out http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/ and the answers http://rschuster.blogs.evolvis.org/2008/12/23/comments-on-latest-post-on-openjdk/

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2009-06-19T11:48:59Z

Thebohemian: /* Virtual machine and class library */

This page is here to answer all things Java related to OpenEmbedded.

=State of support=
==Virtual machine and class library==
Currently (since September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with either Cacao or Hotspot/Zero as the runtime) is available through the Jalimo overlay. This will be merged soon. Future additions will also include Hotspot/Shark which is a variant of Hotspot using a generic JIT compiler based on LLVM.

It is planned to use OpenJDK as the native Java runtime. That way Java packages will be compiled against this library.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or JamVM/Cacao + GNU Classpath. If PhoneME is installed it is preferred

==OpenJDK==
OpenJDK is the name of the F/OSS Java stack from Sun. It normally consists of the class library (often referred to as OpenJDK as well), the Hotspot runtime and many many tools (e.g. javah, rmic, javaws). OpenEmbedded support building OpenJDK with the CacaoVM. This gives many platforms which Hotspot does not directly support a fast Java VM. Please note that Cacao lacks many advanced features like JVMTI. Your only other option is the Zero port of Hotspot. Zero is a C++-based interpreter and can be run on any platform supporting libffi. This gives you a featurefull VM for many platforms at the cost of performance.

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=A word of warning=
Every so often people on the net suggest that in order to get Java stuff running in OpenEmbedded requires installing a JDK, Kaffe or Jikes and then making modifications to the PATH variable in order to allow the
build use the runtime or compiler. These suggestions are ''wrong''! The Java support in OpenEmbedded is (and strives to stay) ''completely'' self-hosting. You should not need a single bit of Java on your host OS to get the Java recipes to compile.

On the other hand the Java support in OE can happily co-exist with whatever 'java', 'javac' and other tools you might have installed in your OS. Due to the nature of some configure scripts, those will sometimes find these executables but in the end only the tools from OpenEmbedded's staging directory will be used (if not its a bug that needs to be fixed).

Please note that problem reports that are caused by pulling in native Java tools (those from your OS) into the OpenEmbedded build process will be closed as invalid. The reason is that the recipes are only supposed to work with the built-in toolchain.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi. If you desperately need jamvm on your platform consider installing the development package for libffi of your distro.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Target virtual machine ==
'''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering multiple J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao, phoneme or openjdk recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

Additionally OpenJDK can be built using either Cacao (same properties as above) or the Zero port of Hotspot. Zero is an C++-based interpreter capable of running on any platform that is supported by libffi.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao, JamVM or OpenJDK packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

=Writing a Java recipe=
This section is going to tell you, how to write a proper recipe to build a Java library or program.

'''At the moment this is a stub and you will only find some scattered information which at a later point will be merged into a consistent whole.'''

==java-native.bbclass==
If you use the ''java-library'' bbclass in a recipe ''foo'' and generate a native variant (e.g. ''foo-native'') you should use

inherit java-native

instead of ''native''. By doing so, you make sure, that any jars created by the recipe are properly installed into staging.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the releases that appear to be stable. Highly recommended on AMD64 systems where Cacao likes to fail:

PREFERRED_VERSION_jamvm-native = "1.5.3"
PREFERRED_VERSION_classpath-native = "0.98"

For the target device:

PREFERRED_VERSION_jamvm = "1.5.2"
PREFERRED_VERSION_classpath = "0.98"

=== cacao[-native] and classpath[-native] ===
These releases appear to be stable:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

For the target device take these:

PREFERRED_VERSION_cacao = "0.99.4"
PREFERRED_VERSION_classpath = "0.98"

=== libecj-bootstrap ===

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

Since December 2008 OpenJDK + Cacao can be crosscompiled with OpenEmbedded as demonstrated by Robert Schuster!
Check out http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/ and the answers http://rschuster.blogs.evolvis.org/2008/12/23/comments-on-latest-post-on-openjdk/

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2009-06-19T11:47:35Z

Thebohemian: added word of warning

This page is here to answer all things Java related to OpenEmbedded.

=State of support=
==Virtual machine and class library==
Currently (September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with either Cacao or Hotspot/Zero as the runtime) is available through the Jalimo overlay. This will be merged soon. Future additions will also include Hotspot/Shark which is a variant of Hotspot using a generic JIT compiler based on LLVM.

It is planned to use OpenJDK as the native Java runtime. That way Java packages will be compiled against this library.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or JamVM/Cacao + GNU Classpath. If PhoneME is installed it is preferred

==OpenJDK==
OpenJDK is the name of the F/OSS Java stack from Sun. It normally consists of the class library (often referred to as OpenJDK as well), the Hotspot runtime and many many tools (e.g. javah, rmic, javaws). OpenEmbedded support building OpenJDK with the CacaoVM. This gives many platforms which Hotspot does not directly support a fast Java VM. Please note that Cacao lacks many advanced features like JVMTI. Your only other option is the Zero port of Hotspot. Zero is a C++-based interpreter and can be run on any platform supporting libffi. This gives you a featurefull VM for many platforms at the cost of performance.

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=A word of warning=
Every so often people on the net suggest that in order to get Java stuff running in OpenEmbedded requires installing a JDK, Kaffe or Jikes and then making modifications to the PATH variable in order to allow the
build use the runtime or compiler. These suggestions are ''wrong''! The Java support in OpenEmbedded is (and strives to stay) ''completely'' self-hosting. You should not need a single bit of Java on your host OS to get the Java recipes to compile.

On the other hand the Java support in OE can happily co-exist with whatever 'java', 'javac' and other tools you might have installed in your OS. Due to the nature of some configure scripts, those will sometimes find these executables but in the end only the tools from OpenEmbedded's staging directory will be used (if not its a bug that needs to be fixed).

Please note that problem reports that are caused by pulling in native Java tools (those from your OS) into the OpenEmbedded build process will be closed as invalid. The reason is that the recipes are only supposed to work with the built-in toolchain.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi. If you desperately need jamvm on your platform consider installing the development package for libffi of your distro.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Target virtual machine ==
'''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering multiple J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao, phoneme or openjdk recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

Additionally OpenJDK can be built using either Cacao (same properties as above) or the Zero port of Hotspot. Zero is an C++-based interpreter capable of running on any platform that is supported by libffi.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao, JamVM or OpenJDK packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

=Writing a Java recipe=
This section is going to tell you, how to write a proper recipe to build a Java library or program.

'''At the moment this is a stub and you will only find some scattered information which at a later point will be merged into a consistent whole.'''

==java-native.bbclass==
If you use the ''java-library'' bbclass in a recipe ''foo'' and generate a native variant (e.g. ''foo-native'') you should use

inherit java-native

instead of ''native''. By doing so, you make sure, that any jars created by the recipe are properly installed into staging.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the releases that appear to be stable. Highly recommended on AMD64 systems where Cacao likes to fail:

PREFERRED_VERSION_jamvm-native = "1.5.3"
PREFERRED_VERSION_classpath-native = "0.98"

For the target device:

PREFERRED_VERSION_jamvm = "1.5.2"
PREFERRED_VERSION_classpath = "0.98"

=== cacao[-native] and classpath[-native] ===
These releases appear to be stable:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

For the target device take these:

PREFERRED_VERSION_cacao = "0.99.4"
PREFERRED_VERSION_classpath = "0.98"

=== libecj-bootstrap ===

PREFERRED_VERSION_libecj-bootstrap = "3.4"

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

Since December 2008 OpenJDK + Cacao can be crosscompiled with OpenEmbedded as demonstrated by Robert Schuster!
Check out http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/ and the answers http://rschuster.blogs.evolvis.org/2008/12/23/comments-on-latest-post-on-openjdk/

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Template:Main page/news

2009-03-31T21:09:45Z

Thebohemian: stable branch news

'''Recent News:'''
* '''''2009-03-31:''''' OpenEmbedded opens the stable/2009 [[Stable]] branch. Special procedure is applied to it which results in better support for our downstream users.
* '''''2009-03-24:''''' [http://www.foss-aalborg.dk/ FOSS Aalborg] in Aalborg, Denmark, with a focus on embedded software. [[User:Mickey|Mickey]] gives a talk about OpenEmbedded.
* '''''2009-03-06:''''' [http://www.alwaysinnovating.com Always Innovating] is using OE to build software for their Touch Book.
* '''''2009-02-19:''''' KOAN Software [http://thread.gmane.org/gmane.comp.handhelds.openembedded/21188 announces] it's KaeilOS distribution will join the OpenEmbedded project.
* '''''2009-02-10:''''' OE has a new Logo -- Many thanks to [http://buglabs.com Bug Labs] who funded the logo development, and [http://mateozlatar.com/ Mateo Zlatar] for designing the logo.

Success stories

2009-03-29T00:47:55Z

Thebohemian: /* Open Source */

A list of projects, companies and other people using OE as well as some quotes from OE users.

== Commercial ==
* 4G-Systems are using it for the [http://meshcube.org Meshcube], see [http://www.meshcube.org/meshwiki/OpenEmbeddedDevelopment]
* Dream Multimedia TV are using it for their Dreambox 702x, see [http://developer.elitedvb.net/listprojects.php?curr_dir=80]
* [http://www.mn-solutions.de M&N Solutions] is using it for it's MNCI "Ramses" device for software release 5.4. They use a local derivate of OE for their radio hand-held terminals RT3000 and RT4000 and for their fork-lift terminal RT2100.
* [http://www.toradex.com Toradex] are using it for their Colibri development boards
* [http://www.axon.tv/ Axon Digital Design] builds small Linux based firmwares for some of their modular HDTV boards.
* [http://www.emqbit.com/ emQbit] is using it for their development boards
* [http://openmoko.com/ OpenMoko] is using it for the OpenMoko SmartPhone Distribution
* Techsol is using it for their [http://www.medallionsystem.com/ Medallion] boards.
* [http://www.gumstix.com/ Gumstix] is using OpenEmbedded for their small form factor Basix, Connex, and Verdex motherboards
* [http://buglabs.net Bug Labs] is using Poky Linux on the [http://buglabs.net/products BUG] device, a portable and modular Linux platform.
* [http://bec-systems.com BEC Systems] is helping customers use OE in commercial projects.
* [http://www.sidebranch.com Sidebranch] uses OE to help companies get on speed with embedded Linux in an open manner.
* Hark Technologies uses OE for their [http://linuxdevices.com/news/NS7648514863.html AT91SAM9260 SBC]

== Inhouse Usage ==
* AMD: internal work on distributions for a thin client
* [http://www.openedhand.com Openedhand] : Internal development work and custom images
* Siemens: internal work in R&D
* TI: internal work on distributions for developer boards
* [http://www.digital-cube.co.kr Digitalcube] : internal work in R&D for developer boards and PMP
* [http://www.kernelconcepts.de/en kernel concepts] : Internal R&D tasks and demo images for customers.
* NXP Semiconductors: Custom images & distributions for research purposes with third parties.
* [http://www.tid.es/netvehicles/tools.htm Telefonica I+D Networked Vehicles Division] : R&D tasks in automotive field. OE is used for vehicle On Board Units and infrastructure Road Side Units.
* [http://www.atmel.com Atmel]: demos and documentation on all AT91 ARM based products available on [http://www.linux4sam.org www.linux4sam.org] : are using [http://www.angstrom-distribution.org Ångström]/OE.
* [http://www.mentorel.com Mentorel]: demo images for customers using [http://www.angstrom-distribution.org Ångström]/OE.

== Education and Research ==
* University of Twente: http://www.freeband.nl/project.cfm?id=494&language=en
* University of California, San Diego: https://wiisard.org/
* University of Frankfurt: ELAN Project (E-Learning in Mobile Ad-hoc Networks)

== Open Source ==
* All [http://www.angstrom-distribution.org Ångström] releases are based on OE
* All [http://openzaurus.org OpenZaurus] releases >= 3.5.1 are based on OE
* All [http://opensimpad.org OpenSIMpad] releases >= 0.9.1 are based on OE
* [http://www.nslu2-linux.org/wiki/OpenSlug/HomePage OpenSlug] distribution for the Linksys NSLU2 and the [http://www.nslu2-linux.org/wiki/Unslung/HomePage Unslung] distribution for the NSLU2 as well.
* [http://owmnr.ifaistos.awmn.net OWMNR] - Open Wireless Metropolitan Network Router. OE based distribution for creating a wireless router.
* [http://gpephone.linuxtogo.org GPE Phone Edition] uses OE for VMWare demo images and to build SDKs.
* The [http://jlime.com JLime] Linux distribution uses OE for all current releases.
* All [http://dev.openbossa.org/mamona Mamona] releases are based on OE
* [http://jalimo.org Jalimo] maintains the Java build recipes in OE and provides binary packages for Maemo-based devices.

== Open Hardware ==
* [http://wiki.emqbit.com/free-ecb-at91 Free ECB_AT91] - An open Single Board computer that [http://wiki.emqbit.com/openembedded runs openembedded].

== Quotes ==
''Well, looks like openembedded has really sorted out my install/setup nightmare for this eval board... thanks you guys. In the last 4 hours, i've gotten more done with this board than i have in 6 months.''

''I will try and add an smdk2410.conf machine file to the setup soon... not that i expect it'll be useful to a lot of people, but i'll try to at least document it so that other machines can be supported easily enough.''

''Well I just got OE set up and I've been really impressed so far.''

''OE takes all of the hassle out of cross-compiling.''

[[Category:Community]]

Documentation

2009-03-28T20:47:21Z

Thebohemian:

Documentation that relates to Openembedded.

* OE User manual [http://docs.openembedded.org/usermanual/usermanual.pdf (pdf)] [http://docs.openembedded.org/usermanual/html (html)] [http://docs.openembedded.org/usermanual/usermanual.html (html single-page)]
* [http://bitbake.berlios.de/manual/ Bitbake Manual]
* [http://www.pokylinux.org/doc/poky-handbook.html Poky Handbook]

Articles about Openembedded:
* [http://bec-systems.com/site/tag/openembedded articles at BEC Systems]

Guides and HowTos:
* [http://www.kernel-labs.org/files/openembedded-guide/openembedded-guide.html OpenEmbedded Guide by Example]
* [http://www.uv-ac.de/openembedded/ OpenEmbedded HowTo]
* [http://free-electrons.com/docs/openembedded/ Using OpenEmbedded to build embedded Linux distributions]

[[Category:User]]
[[Category:Dev]]

Template:Main page/news

2009-03-27T16:53:40Z

Thebohemian:

'''Recent News:'''
* '''''2009-03-24:''''' [http://www.foss-aalborg.dk/ FOSS Aalborg] in Aalborg, Denmark, with a focus on embedded software. [[User:Mickey|Mickey]] gives a talk about OpenEmbedded.
* '''''2009-03-06:''''' [http://www.alwaysinnovating.com Always Innovating] is using OE to build software for their Touch Book.
* '''''2009-02-19:''''' KOAN Software [http://thread.gmane.org/gmane.comp.handhelds.openembedded/21188 announces] it's KaeilOS distribution will join the OpenEmbedded project.
* '''''2009-02-10:''''' OE has a new Logo -- Many thanks to [http://buglabs.com Bug Labs] who funded the logo development, and [http://mateozlatar.com/ Mateo Zlatar] for designing the logo.

Required software

2009-01-30T13:20:35Z

Thebohemian: /* Tools to unpack sources */

= OpenEmbedded's Software Requirements =

This page is the reference of what software is needed. But [[OEandYourDistro]] is likely much faster in getting you that software actually installed.

To use the OE build system the following software is required on your system:
* [http://www.python.org/ Python] (Version 2.4.0 or later)
** Note that you may also need certain development files for Python e.g. for bitbake's setup.py to work. Depending on the distribution you use you may want to look for a package called "python-dev", "python-devel", or similar.
* [http://www.gnu.org/software/patch/patch.html GNU Patch] (Version 2.5.9 or later, see ftp://alpha.gnu.org/gnu/diffutils/ . It is a "testing release" and is not mirrored on the GNU mirrors.)
* [http://www.gnu.org/software/m4/m4.html GNU m4]
* [http://www.gnu.org/software/make/ GNU make] (Version 3.80 or later for hh.org kernels)
* [http://psyco.sourceforge.net/ Psyco JIT Compiler] is recommended to increase performance
* [http://ccache.samba.org/ ccache]
* [http://www.perl.org/ perl] (needs newer than 5.0, how much newer? probably at least 5.6.2)
* [http://invisible-island.net/diffstat/diffstat.html diffstat]
* [http://developer.berlios.de/projects/bitbake bitbake]

== Tools to download source files ==
* wget
* curl
* ftp
* [http://www.nongnu.org/cvs/ cvs]
* [http://subversion.tigris.org/ subversion]
* [http://git.or.cz/index.html git]

== Tools to verify integrity of the downloaded sources ==
* md5sum
* sha256sum

== Tools to unpack sources ==
* tar
* bzip2
* gzip
* unzip

== Tools to build the various *-doc packages==
* [http://www.jclark.com/jade/ Jade] or [http://www.netfolder.com/DSSSL/ OpenJade]
** I don't know which of these is preferred
* [http://sourceforge.net/projects/docbook/ Docbook] DTDs and DSSSL stylesheets
* [http://sgmltools-lite.sourceforge.net/ sgmltools], called "sgmltools-lite" too
* [http://sources.redhat.com/docbook-tools/ docbook-utils]
** docbook-utils download is hard to find; look in ftp://sources.redhat.com/pub/docbook-tools/new-trials/SOURCES
* [ftp://ftp.gnu.org/pub/gnu/texinfo/ Texinfo]
* [http://www.nongnu.org/texi2html/ texi2html] (Perl script that converts Texinfo to HTML)

== Other packages ==
* [http://www.gnu.org/software/sed/sed.html GNU sed] 4.x
* [http://www.gnu.org/software/bison/bison.html Bison]
* bc (binary calculator), if you want to build a Zaurus 2.4 or any of the collie kernels
* glibc headers (libc6-dev in Debian, glibc-devel in RPM based (in PLD also glibc-static is needed))
* [http://www.pcre.org/ pcre headers] (Perl 5 Compatible Regular Expression Library, required for e.g. konqueror-embedded)
* SDL headers to build qemu-native (apt-get install libsdl1.2-dev under Ubuntu/Debian)
* [http://www.mktemp.org/mktemp/ mktemp] (required by quilt and used in some package patches)
* help2man - Create simple man pages from --help output

There is an ongoing effort to accurately document the required software within the OpenEmbedded and ultimately, this will be reflected in the ASSUME_PROVIDED variable.

Required software

2009-01-30T13:20:27Z

Thebohemian: /* Tools to unpack sources */

= OpenEmbedded's Software Requirements =

This page is the reference of what software is needed. But [[OEandYourDistro]] is likely much faster in getting you that software actually installed.

To use the OE build system the following software is required on your system:
* [http://www.python.org/ Python] (Version 2.4.0 or later)
** Note that you may also need certain development files for Python e.g. for bitbake's setup.py to work. Depending on the distribution you use you may want to look for a package called "python-dev", "python-devel", or similar.
* [http://www.gnu.org/software/patch/patch.html GNU Patch] (Version 2.5.9 or later, see ftp://alpha.gnu.org/gnu/diffutils/ . It is a "testing release" and is not mirrored on the GNU mirrors.)
* [http://www.gnu.org/software/m4/m4.html GNU m4]
* [http://www.gnu.org/software/make/ GNU make] (Version 3.80 or later for hh.org kernels)
* [http://psyco.sourceforge.net/ Psyco JIT Compiler] is recommended to increase performance
* [http://ccache.samba.org/ ccache]
* [http://www.perl.org/ perl] (needs newer than 5.0, how much newer? probably at least 5.6.2)
* [http://invisible-island.net/diffstat/diffstat.html diffstat]
* [http://developer.berlios.de/projects/bitbake bitbake]

== Tools to download source files ==
* wget
* curl
* ftp
* [http://www.nongnu.org/cvs/ cvs]
* [http://subversion.tigris.org/ subversion]
* [http://git.or.cz/index.html git]

== Tools to verify integrity of the downloaded sources ==
* md5sum
* sha256sum

== Tools to unpack sources ==
* tar
* bzip2
* gzip
* unzip
* unzip

== Tools to build the various *-doc packages==
* [http://www.jclark.com/jade/ Jade] or [http://www.netfolder.com/DSSSL/ OpenJade]
** I don't know which of these is preferred
* [http://sourceforge.net/projects/docbook/ Docbook] DTDs and DSSSL stylesheets
* [http://sgmltools-lite.sourceforge.net/ sgmltools], called "sgmltools-lite" too
* [http://sources.redhat.com/docbook-tools/ docbook-utils]
** docbook-utils download is hard to find; look in ftp://sources.redhat.com/pub/docbook-tools/new-trials/SOURCES
* [ftp://ftp.gnu.org/pub/gnu/texinfo/ Texinfo]
* [http://www.nongnu.org/texi2html/ texi2html] (Perl script that converts Texinfo to HTML)

== Other packages ==
* [http://www.gnu.org/software/sed/sed.html GNU sed] 4.x
* [http://www.gnu.org/software/bison/bison.html Bison]
* bc (binary calculator), if you want to build a Zaurus 2.4 or any of the collie kernels
* glibc headers (libc6-dev in Debian, glibc-devel in RPM based (in PLD also glibc-static is needed))
* [http://www.pcre.org/ pcre headers] (Perl 5 Compatible Regular Expression Library, required for e.g. konqueror-embedded)
* SDL headers to build qemu-native (apt-get install libsdl1.2-dev under Ubuntu/Debian)
* [http://www.mktemp.org/mktemp/ mktemp] (required by quilt and used in some package patches)
* help2man - Create simple man pages from --help output

There is an ongoing effort to accurately document the required software within the OpenEmbedded and ultimately, this will be reflected in the ASSUME_PROVIDED variable.

Create an intermediate binary tool

2009-01-16T00:50:43Z

Thebohemian: Create an intermediate binary tool moved to BestPractices: Want to add more stuff to this page.

#REDIRECT [[BestPractices]]

Java

2008-11-14T08:43:29Z

Thebohemian: removed "Cacao and GCC 4.3": miscompilation problems have been fixed in OE

This page is here to answer all things Java related to OpenEmbedded.

=Where to get answers about Java support in OpenEmbedded?=
The Java support in OpenEmbedded is maintained through the [http://jalimo.org Jalimo] project. As such we encourage you to subscribe to this project's mailing list and post your question there. Developers of OpenEmbedded-derived distributions like Angstrom are also encouraged to delegate questions of their users to Jalimo.

You can also use the mailing list to discuss new recipes prior to putting them into OpenEmbedded's bug tracker.

=State of support=
==Virtual machine and class library==
Currently (September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with Cacao as the runtime) and one day Hotspot is planned.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or JamVM/Cacao + GNU Classpath. If PhoneME is installed it is preferred

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi. If you desperately need jamvm on your platform consider installing the development package for libffi of your distro.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-boostrap = "3.3"

ECJ 3.3 is recommended over the later releases as those seem to cause trouble.

== Target virtual machine ==
'''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering both J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao and phoneme recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao or JamVM packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_jamvm-native = "1.5.1"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_jamvm = "1.5.1"
PREFERRED_VERSION_classpath = "0.97.2"

=== cacao[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_cacao = "0.99.3"
PREFERRED_VERSION_classpath = "0.97.2"

=== libecj-bootstrap ===
Troubles have been experienced when compiling with ecj 3.4. Therefore prefer 3.3:

PREFERRED_VERSION_libecj-bootstrap = "3.3"

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2008-11-14T08:40:26Z

Thebohemian: /* Target virtual machine */

This page is here to answer all things Java related to OpenEmbedded.

=Where to get answers about Java support in OpenEmbedded?=
The Java support in OpenEmbedded is maintained through the [http://jalimo.org Jalimo] project. As such we encourage you to subscribe to this project's mailing list and post your question there. Developers of OpenEmbedded-derived distributions like Angstrom are also encouraged to delegate questions of their users to Jalimo.

You can also use the mailing list to discuss new recipes prior to putting them into OpenEmbedded's bug tracker.

=State of support=
==Virtual machine and class library==
Currently (September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with Cacao as the runtime) and one day Hotspot is planned.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or JamVM/Cacao + GNU Classpath. If PhoneME is installed it is preferred

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi. If you desperately need jamvm on your platform consider installing the development package for libffi of your distro.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-boostrap = "3.3"

ECJ 3.3 is recommended over the later releases as those seem to cause trouble.

== Target virtual machine ==
'''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering both J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao and phoneme recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao or JamVM packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_jamvm-native = "1.5.1"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_jamvm = "1.5.1"
PREFERRED_VERSION_classpath = "0.97.2"

=== cacao[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_cacao = "0.99.3"
PREFERRED_VERSION_classpath = "0.97.2"

=== libecj-bootstrap ===
Troubles have been experienced when compiling with ecj 3.4. Therefore prefer 3.3:

PREFERRED_VERSION_libecj-bootstrap = "3.3"

== Cacao and GCC 4.3 ==
It seems to me that Cacao (especially 0.99.3) is miscompiled when using GCC 4.3. You will experience that ecj-bootstrap-native will produce spurious errors when compiling classes. If that happens to you switch to JamVM for 'virtual/java-native'.

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2008-11-14T08:39:52Z

Thebohemian: /* Native virtual machine aka virtual/java-native */

This page is here to answer all things Java related to OpenEmbedded.

=Where to get answers about Java support in OpenEmbedded?=
The Java support in OpenEmbedded is maintained through the [http://jalimo.org Jalimo] project. As such we encourage you to subscribe to this project's mailing list and post your question there. Developers of OpenEmbedded-derived distributions like Angstrom are also encouraged to delegate questions of their users to Jalimo.

You can also use the mailing list to discuss new recipes prior to putting them into OpenEmbedded's bug tracker.

=State of support=
==Virtual machine and class library==
Currently (September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with Cacao as the runtime) and one day Hotspot is planned.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or JamVM/Cacao + GNU Classpath. If PhoneME is installed it is preferred

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi. If you desperately need jamvm on your platform consider installing the development package for libffi of your distro.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-boostrap = "3.3"

ECJ 3.3 is recommended over the later releases as those seem to cause trouble.

== Target virtual machine ==
''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering both J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao and phoneme recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao or JamVM packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_jamvm-native = "1.5.1"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_jamvm = "1.5.1"
PREFERRED_VERSION_classpath = "0.97.2"

=== cacao[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_cacao = "0.99.3"
PREFERRED_VERSION_classpath = "0.97.2"

=== libecj-bootstrap ===
Troubles have been experienced when compiling with ecj 3.4. Therefore prefer 3.3:

PREFERRED_VERSION_libecj-bootstrap = "3.3"

== Cacao and GCC 4.3 ==
It seems to me that Cacao (especially 0.99.3) is miscompiled when using GCC 4.3. You will experience that ecj-bootstrap-native will produce spurious errors when compiling classes. If that happens to you switch to JamVM for 'virtual/java-native'.

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2008-11-14T08:34:06Z

Thebohemian: /* Toolchain */

This page is here to answer all things Java related to OpenEmbedded.

=Where to get answers about Java support in OpenEmbedded?=
The Java support in OpenEmbedded is maintained through the [http://jalimo.org Jalimo] project. As such we encourage you to subscribe to this project's mailing list and post your question there. Developers of OpenEmbedded-derived distributions like Angstrom are also encouraged to delegate questions of their users to Jalimo.

You can also use the mailing list to discuss new recipes prior to putting them into OpenEmbedded's bug tracker.

=State of support=
==Virtual machine and class library==
Currently (September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with Cacao as the runtime) and one day Hotspot is planned.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or JamVM/Cacao + GNU Classpath. If PhoneME is installed it is preferred

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-boostrap = "3.3"

ECJ 3.3 is recommended over the later releases as those seem to cause trouble.

== Target virtual machine ==
''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering both J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao and phoneme recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao or JamVM packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_jamvm-native = "1.5.1"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_jamvm = "1.5.1"
PREFERRED_VERSION_classpath = "0.97.2"

=== cacao[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_cacao = "0.99.3"
PREFERRED_VERSION_classpath = "0.97.2"

=== libecj-bootstrap ===
Troubles have been experienced when compiling with ecj 3.4. Therefore prefer 3.3:

PREFERRED_VERSION_libecj-bootstrap = "3.3"

== Cacao and GCC 4.3 ==
It seems to me that Cacao (especially 0.99.3) is miscompiled when using GCC 4.3. You will experience that ecj-bootstrap-native will produce spurious errors when compiling classes. If that happens to you switch to JamVM for 'virtual/java-native'.

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2008-11-14T08:31:25Z

Thebohemian: /* Native Java compiler aka virtual/javac-native */

This page is here to answer all things Java related to OpenEmbedded.

=Where to get answers about Java support in OpenEmbedded?=
The Java support in OpenEmbedded is maintained through the [http://jalimo.org Jalimo] project. As such we encourage you to subscribe to this project's mailing list and post your question there. Developers of OpenEmbedded-derived distributions like Angstrom are also encouraged to delegate questions of their users to Jalimo.

You can also use the mailing list to discuss new recipes prior to putting them into OpenEmbedded's bug tracker.

=State of support=
==Virtual machine and class library==
Currently (September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with Cacao as the runtime) and one day Hotspot is planned.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or JamVM/Cacao + GNU Classpath. If PhoneME is installed it is preferred

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== ECJ ===
Instead of Sun's Java Compiler 'javac' most packages in OpenEmbedded are compiled with the command-line version of the Eclipse project's ECJ. You need the package ecj-bootstrap-native to get access to the 'javac' and 'ecj' binary that are provided by it.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. A 'javac' binary can be provided by either 'ecj-bootstrap-native' or 'openjdk-javac-native' (the latter just creates a symlink). Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

There are two recipes which provide this functionality:

ecj-bootstrap-native uses the commandline variant of the Eclipse IDE's integrated compiler. In order to use that compiler add the following to your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

The second option is OpenJDK's Java compiler which is the F/OSS variant of good old 'javac'. If you experience trouble with ecj you should try OpenJDK's
Java compiler by setting the following in your configuration:

PREFERRED_PROVIDER_virtual/javac-native = "openjdk-javac-native"

'''Note:''' OpenJDK's javac is actually build in the package openjdk-language-tools-native (provides a 'sun-javac' binary). The reason for this is to allow 'ecj-bootstrap-native' and 'openjdk-language-tools-native' to coexist in the staging dir.

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-boostrap = "3.3"

ECJ 3.3 is recommended over the later releases as those seem to cause trouble.

== Target virtual machine ==
''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering both J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao and phoneme recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao or JamVM packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_jamvm-native = "1.5.1"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_jamvm = "1.5.1"
PREFERRED_VERSION_classpath = "0.97.2"

=== cacao[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_cacao = "0.99.3"
PREFERRED_VERSION_classpath = "0.97.2"

=== libecj-bootstrap ===
Troubles have been experienced when compiling with ecj 3.4. Therefore prefer 3.3:

PREFERRED_VERSION_libecj-bootstrap = "3.3"

== Cacao and GCC 4.3 ==
It seems to me that Cacao (especially 0.99.3) is miscompiled when using GCC 4.3. You will experience that ecj-bootstrap-native will produce spurious errors when compiling classes. If that happens to you switch to JamVM for 'virtual/java-native'.

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2008-11-14T08:23:39Z

Thebohemian: /* OpenJDK language tools */

This page is here to answer all things Java related to OpenEmbedded.

=Where to get answers about Java support in OpenEmbedded?=
The Java support in OpenEmbedded is maintained through the [http://jalimo.org Jalimo] project. As such we encourage you to subscribe to this project's mailing list and post your question there. Developers of OpenEmbedded-derived distributions like Angstrom are also encouraged to delegate questions of their users to Jalimo.

You can also use the mailing list to discuss new recipes prior to putting them into OpenEmbedded's bug tracker.

=State of support=
==Virtual machine and class library==
Currently (September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with Cacao as the runtime) and one day Hotspot is planned.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or JamVM/Cacao + GNU Classpath. If PhoneME is installed it is preferred

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== ECJ ===
Instead of Sun's Java Compiler 'javac' most packages in OpenEmbedded are compiled with the command-line version of the Eclipse project's ECJ. You need the package ecj-bootstrap-native to get access to the 'javac' and 'ecj' binary that are provided by it.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. A 'javac' binary can be provided by either 'ecj-bootstrap-native' or 'openjdk-javac-native' (the latter just creates a symlink). Refer to the [[#Native Java compiler aka virtual/javac-native|virtual/javac-native discussion]] for details.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

At the moment only the package ecj-bootstrap-native provides virtual/javac-native but it is planned that in the future Sun's javac will be available.

Add the following lines to your configuration to make the Java compiler setting fixed:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-boostrap = "3.3"

ECJ 3.3 is recommended over the later releases as those seem to cause trouble.

== Target virtual machine ==
''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering both J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao and phoneme recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao or JamVM packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_jamvm-native = "1.5.1"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_jamvm = "1.5.1"
PREFERRED_VERSION_classpath = "0.97.2"

=== cacao[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_cacao = "0.99.3"
PREFERRED_VERSION_classpath = "0.97.2"

=== libecj-bootstrap ===
Troubles have been experienced when compiling with ecj 3.4. Therefore prefer 3.3:

PREFERRED_VERSION_libecj-bootstrap = "3.3"

== Cacao and GCC 4.3 ==
It seems to me that Cacao (especially 0.99.3) is miscompiled when using GCC 4.3. You will experience that ecj-bootstrap-native will produce spurious errors when compiling classes. If that happens to you switch to JamVM for 'virtual/java-native'.

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2008-11-14T08:23:14Z

Thebohemian: /* OpenJDK language tools */

This page is here to answer all things Java related to OpenEmbedded.

=Where to get answers about Java support in OpenEmbedded?=
The Java support in OpenEmbedded is maintained through the [http://jalimo.org Jalimo] project. As such we encourage you to subscribe to this project's mailing list and post your question there. Developers of OpenEmbedded-derived distributions like Angstrom are also encouraged to delegate questions of their users to Jalimo.

You can also use the mailing list to discuss new recipes prior to putting them into OpenEmbedded's bug tracker.

=State of support=
==Virtual machine and class library==
Currently (September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with Cacao as the runtime) and one day Hotspot is planned.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or JamVM/Cacao + GNU Classpath. If PhoneME is installed it is preferred

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== ECJ ===
Instead of Sun's Java Compiler 'javac' most packages in OpenEmbedded are compiled with the command-line version of the Eclipse project's ECJ. You need the package ecj-bootstrap-native to get access to the 'javac' and 'ecj' binary that are provided by it.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. A 'javac' binary can be provided by either 'ecj-bootstrap-native' or 'openjdk-javac-native' (the latter just creates a symlink). Refer to the [[#Native virtual machine aka virtual/java-native|virtual/javac-native discussion]] for details.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

At the moment only the package ecj-bootstrap-native provides virtual/javac-native but it is planned that in the future Sun's javac will be available.

Add the following lines to your configuration to make the Java compiler setting fixed:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-boostrap = "3.3"

ECJ 3.3 is recommended over the later releases as those seem to cause trouble.

== Target virtual machine ==
''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering both J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao and phoneme recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao or JamVM packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_jamvm-native = "1.5.1"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_jamvm = "1.5.1"
PREFERRED_VERSION_classpath = "0.97.2"

=== cacao[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_cacao = "0.99.3"
PREFERRED_VERSION_classpath = "0.97.2"

=== libecj-bootstrap ===
Troubles have been experienced when compiling with ecj 3.4. Therefore prefer 3.3:

PREFERRED_VERSION_libecj-bootstrap = "3.3"

== Cacao and GCC 4.3 ==
It seems to me that Cacao (especially 0.99.3) is miscompiled when using GCC 4.3. You will experience that ecj-bootstrap-native will produce spurious errors when compiling classes. If that happens to you switch to JamVM for 'virtual/java-native'.

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]

Java

2008-11-14T08:22:59Z

Thebohemian:

This page is here to answer all things Java related to OpenEmbedded.

=Where to get answers about Java support in OpenEmbedded?=
The Java support in OpenEmbedded is maintained through the [http://jalimo.org Jalimo] project. As such we encourage you to subscribe to this project's mailing list and post your question there. Developers of OpenEmbedded-derived distributions like Angstrom are also encouraged to delegate questions of their users to Jalimo.

You can also use the mailing list to discuss new recipes prior to putting them into OpenEmbedded's bug tracker.

=State of support=
==Virtual machine and class library==
Currently (September 2008) you will be able to build packages for your target system that use a many VMs and their class libraries. For a full J2SE environment on the target you can build JamVM and Cacao as the virtual machine and GNU Classpath as the class library.

For J2ME you can have the "Connected Device Configuration" (CDC) in either the "Foundation" or "Personal" profile using the GPLed PhoneME Advanced virtual machine. See below for details.

For J2ME's "Mobile Information Device Profile" (MIDP2.0) you can use MIDPath.

Support for OpenJDK (with Cacao as the runtime) and one day Hotspot is planned.

==Java libraries==
The number of available Java libraries is still small but can grow quickly as the necessary infrastructure is in place. Currently libraries such as dbus-java, kxml2, libmatthew, librxtx, sqlitejdbc, javasqlite, woodstox, xmlpull, SWT (3.4, Gtk+) are available.

For the Maemo platform's "hildon" environment special SWT packages are available which allow a better integration (i.e. hildon menus, hildon file chooser dialog).

== PhoneME Advanced ==
PhoneME Advanced is provided in the 'Foundation' and 'Personal' profile through the recipes phoneme-advanced-foundation and (surprise!) phoneme-advanced-personal. The way the recipes are written both can be compiled and installed at the same time on the target device.

''Note:'' At the moment the personal profile's AWT support relies on Qt3 which is heavily outdated. If possible you the foundation profile with SWT for the GUI or contribute to [https://phoneme.dev.java.net PhoneME] to fix this. :)

When a PhoneME Advanced package is installed you will find the VM in $libdir_jvm (which is ''/usr/lib/jvm'' by default). The package provides a java-cdc symlink which is changeable through update-alternatives and a cvm-<profile name> symlink.

==J2ME MIDP2.0==
J2ME MIDP2.0 is supported through the MIDPath project. MIDPath provides the neccessary libraries (taken from PhoneME and/or the respective JSRs) and OpenEmbedded has direct support for a few devices (e.g. button mappings). Please note that while MIDPath can run most MIDP2.0 programs it is no official MIDP2.0 implementation.

MIDPath can be run on top of either PhoneME Advanced or JamVM/Cacao + GNU Classpath. If PhoneME is installed it is preferred

==Toolchain==
In order to build Java packages no virtual machine needs to be installed on the build machine. OpenEmbedded builds everything on its own.

Missing but planned to be included are popular Java build tools like Ant.

=== GNU Classpath Tools ===
Included in the package classpath-native are the tools 'gjar', 'gjavah', 'gjavap', 'gjarsigner' (and soon gjdoc). Those tools usually work without problems and should be fully compatible to the ones provided by OpenJDK.

=== ECJ ===
Instead of Sun's Java Compiler 'javac' most packages in OpenEmbedded are compiled with the command-line version of the Eclipse project's ECJ. You need the package ecj-bootstrap-native to get access to the 'javac' and 'ecj' binary that are provided by it.

=== OpenJDK language tools ===
OpenEmbedded supports the OpenJDK language tools consisting of 'sun-javac', 'javap', 'javah' and 'apt'. Put 'openjdk-langtools-native' to the dependencies of your recipe to use those binaries. Albeit the tools are from OpenJDK they run on Cacao/JamVM and GNU Classpath.

'''Note:''' openjdk-langtools-native is not a provider of 'virtual/javac-native' it only provides a 'sun-javac' binary. A 'javac' binary can be provided by either 'ecj-bootstrap-native' or 'openjdk-javac-native' (the latter just creates a symlink). Refer to the [[#Native virtual machine aka virtual/java-native virtual/javac-native discussion]] for details.

=Configuring=
In this section you learn about the things you can set up. In many OpenEmbedded-based distributions some or most of these decision may have already been made for you so there is no need to specify them. However in case you want to provide the Java support in your distribution you need to know which knobs are available.

==Bootstrap process==
As told in the toolchain support section the whole Java support in OpenEmbedded is self-hosting. This mean you do not need to have any bit of Java on your build machine as OpenEmbedded will build this itself.

This bootstrap process contains the following steps: At first jikes-native is compiled which is a Java 1.4-capable compiler that does not need a runtime or (strictly) a class library to work. With this compiler we compile the initial runtime (package virtual/java-initial).

virtual/java-initial is a preliminary runtime. This virtual package is currently provided by cacao-initial or jamvm-initial. After that ecj-initial is built. At that point we have a 1.5-capable compiler running on a Java 1.4 compatible VM.

The compiler is then used to build virtual/java-native and finally virtual/javac-native. The former virtual package is provided by either cacao-native or jamvm-native. The latter package is currently only provided through ecj-bootstrap-native. Having built these packages provides the OpenEmbedded build environment with a Java5-capable compiler and runtime. At that point we are ready to compile any other Java package.

==Bootstrap virtual machine aka virtual/java-initial==
The bootstrap virtual machine has the sole purpose of running ecj-initial (the bootstrap compiler) to compile a 1.5-capable runtime and library. The bootstrap VM runs on your build host and is therefore a -native package. Inside the native staging directory the VM provides a 'java-initial' executable.

As told above there are currently two packages that provide 'virtual/java-native'. Add

PREFERRED_PROVIDER_virtual/java-initial = "cacao-initial"
PREFERRED_VERSION_cacao-initial = "0.98"

to your local or site configuration to choose the Cacao VM. This virtual machine has a JIT compiler and is generally faster but takes a bit longer to compile. Furthermore this VM is only tested to work correctly on X86 build hosts. If you chose Cacao there will also be a 'cacao-initial' binary in your native staging directory.

'''Note:''' There is a problem with Cacao 0.98 running on recent distributions where mmaping the zero page is not allowed. Chose jamvm-initial (see below) if you do not want to change the vm_mmap_min_adr restriction on your system.

In case Cacao is unsuitable for you add

PREFERRED_PROVIDER_virtual/java-initial = "jamvm-initial"
PREFERRED_VERSION_jamvm-initial = "1.4.5"

to your configuration. JamVM is an interpreting Java virtual machine. Despite interpreting only it is very fast (implements many modern interpreter techniques) and compiles quickly. Furthermore it is known to work on X86 and PowerPC build hosts.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

==Native virtual machine aka virtual/java-native==
As for virtual/java-initial this virtual package provides a Java virtual machine which runs on your build host. Its purpose is to run any Java programs that are needed during your build process. The most prominent program that it is supposed to run is the compiler ECJ. The virtual/java-native package provides a 'java' binary inside the native staging directory. At the moment you can chose between two runtimes: Cacao and JamVM.

As for the general features it is the same as for java-initial. However for virtual/java-native later versions of the VMs are used so stability and platform support is better. For instance you can use cacao-native on PowerPC as well since the version of Cacao used properly supports it.

To chose Cacao add the following lines to your configuration:

PREFERRED_PROVIDER_virtual/java-native = "cacao-native"
PREFERRED_VERSION_cacao-native = "0.99.3"

Besides 'java' cacao-native install a 'cacao' binary into the native staging directory.

If you favor JamVM (or are having trouble with Cacao) use:

PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_VERSION_jamvm-native = "1.5.1"

There will also be a 'jamvm' binary in native staging directory besides the 'java' one with jamvm-native.

'''Note:''' Native versions of jamvm are unsupported on amd64/x86_64 hosts since OpenEmbedded lacks a native libffi.

== Native Java compiler aka virtual/javac-native ==
The virtual/javac-native package provides the 'javac' binary which is to be found within the native staging directory. This compiler is used to build all of the Java packages within OpenEmbedded.

At the moment only the package ecj-bootstrap-native provides virtual/javac-native but it is planned that in the future Sun's javac will be available.

Add the following lines to your configuration to make the Java compiler setting fixed:

PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

=== ecj-bootstrap-native, ecj-initial and libecj-bootstrap ===
Since ecj-initial and ecj-bootstrap-native use the same jar file the compilation step for both packages is done through in the libecj-bootstrap recipe. Therefore in order to decide which ECJ version to use for compilation you need to set a version preference for that recipe:

PREFERRED_VERSION_libecj-boostrap = "3.3"

ECJ 3.3 is recommended over the later releases as those seem to cause trouble.

== Target virtual machine ==
''Note:''' There used to be a virtual/java package. It turned out that by having this it prevented offering both J2SE-compatible VMs for the target device.

From a distributors point of view you can build the jamvm, cacao and phoneme recipes and provide them to your users. Those can then either install the packages directly by its name or rely
on a chosing of the packaging.

At the moment Cacao and JamVM are supported runtimes. Cacao is ready for x86, PowerPC and ARM systems (others are untested and AVR32 is not suppported) and has a JIT compiler. JamVM can be used on x86, PowerPC, ARM and MIPS. PhoneME Advanced should support x86, PowerPC, ARM, MIPS and Sparc.

When installed all J2SE runtimes provide the 'java' executable (chosen through update-alternatives). PhoneME Advanced gives you a 'java-cdc' executable.

=== Runtime provider ===
'''Warning:''' When we talk of 'runtime provider' here this is meant in the OpenEmbedded sense (PROVIDES = build provides, RPROVIDES = runtime provides)
The Cacao or JamVM packages are set to provide 'java2-runtime'. Packages which need a J2SE-capable VM should RDEPEND on this. By inheriting the 'java-library' class in your recipe this is done automatically.

PhoneME on the other hand is set to provide 'java-cdc-runtime'.

== GNU Classpath for headless machines aka classpath-minimal ==
Through setting the provider for 'classpath' you can decide whether you build a full class library with support for AWT/Swing (having a gtk+ dependency) or a variant that works without that and is primarily meant for headless devices. It might also be handy if you decide not to use AWT/Swing and use SWT instead. To chose the minimal variant add this to your configuration:

PREFERRED_PROVIDER_classpath = "classpath-minimal"

Otherwise you need to add this line:

PREFERRED_PROVIDER_classpath = "classpath"

Currently the Angstrom distribution does not set a preference and you have to provide your own.

= Information on specific libraries =
== swt3.4-gtk and swt3.4-gtk-hildon ==
Some effort has been done to integrate Gtk+-based SWT 3.4 into the Hildon environment (that is what Maemo provides). Distributions targeting Maemo should set the preferred provider for swt3.4-gtk like this:

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk-hildon"

''Important'': If you do not want the hildon variant it is best to declare

PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"

as well. So bitbake will not chose the wrong one by accident (which would otherwise pull in all kinds of unwanted dependencies).

= Caveats, known issues, hints, miscellaneous information =
== Version suggestions ==
Everyone and his dog knows that combining glibc 2.8, gcc 2.95 and Linux kernel 2.6.26 is not going to work. In the GNU Classpath realm we also have a set of versions that do not fit together. Here are some suggestions for your PREFERRED_VERSIONs. Stick to these if you are unsure. You can always find out which version are ''supposed'' to be compatible by reading the READMEs of the VMs.

=== jamvm-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_jamvm-initial = "1.4.5"
PREFERRED_VERSION_classpath-initial = "0.93"

=== cacao-initial and classpath-initial ===
Use this and nothing else:

PREFERRED_VERSION_cacao-initial = "0.98"
PREFERRED_VERSION_classpath-initial = "0.93"

=== jamvm[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_jamvm-native = "1.5.1"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_jamvm = "1.5.1"
PREFERRED_VERSION_classpath = "0.97.2"

=== cacao[-native] and classpath[-native] ===
These are the latest releases and they seem to be stable. Highly recommended:

PREFERRED_VERSION_cacao-native = "0.99.3"
PREFERRED_VERSION_classpath-native = "0.97.2"

The same goes for the target device:

PREFERRED_VERSION_cacao = "0.99.3"
PREFERRED_VERSION_classpath = "0.97.2"

=== libecj-bootstrap ===
Troubles have been experienced when compiling with ecj 3.4. Therefore prefer 3.3:

PREFERRED_VERSION_libecj-bootstrap = "3.3"

== Cacao and GCC 4.3 ==
It seems to me that Cacao (especially 0.99.3) is miscompiled when using GCC 4.3. You will experience that ecj-bootstrap-native will produce spurious errors when compiling classes. If that happens to you switch to JamVM for 'virtual/java-native'.

== Extra binaries and symlinks ==
Since both Cacao and JamVM can be installed in staging you can use this and modify the 'java' or 'java-initial' symlink if you want to switch to a certain VM.

== Debugging Cacao on the target ==
You need to debug the Cacao JVM on your target device using GDB and need some pointers on how to get started? Read [https://wiki.evolvis.org/jalimo/index.php/CacaoDebugging this] page from the Jalimo Wiki.

=Future plans =
==Default Bytecode compliance level==
Soon an option will be introduced to set the default bytecode compliance level. For any Java package that does not explicitly provide this level (not many do this) the one you set in your configuration will be used.

==OpenJDK + Cacao==
The flexibility of the Cacao runtime allows it to run it with OpenJDK's class library. This allows you to use the official class library and a JIT-capable runtime on an ARM device (as of today Hotspot has no JIT on ARM).

Since the middle of August 2008 OpenJDK + Cacao can be build and is included in the Debian armel sid repositories (package cacao-oj6-sdk). Xerxes Rånby is showing some webbapplets running using OpenJDK + CACAO on his blog: http://labb.zafena.se/?p=1

==ant-native==
Ant is an often used tool in the Java world. Even OpenJDK uses it. Unfortunately it is also a complex beast with many dependencies (many of which use Ant itself). Still there is work in progress to build and use it inside OpenEmbedded.

Preliminary work has been done in the Jalimo Subversion repository. There is an 'ant-native' recipe exists which actually works. :)

= FAQ =
This space is for *your* questions and those that appeared more often on the mailing list. Things will be added here by the Jalimo folk/OE-Java maintainers or by you asking a question.

== Q: I do get all these editions, configurations and profiles that exist in the Java world wrong. Any pointer on this? ==
I found these articles in Wikipedia helpful to clarify the situation [http://en.wikipedia.org/wiki/Java_platform Java platform], [http://en.wikipedia.org/wiki/Java_ME Java ME].

[[Category:FAQ]]
[[Category:Software Components]]
[[Category:Java]]