=== [[Helidon]] MP 2.0 supports [[GraalVM]] [[NativeImage]] ===

=== [[Helidon]] MP 2.0 supports [[GraalVM]] [[NativeImage]] ===

[[Helidon]] MP implements the [[MicroProfile]] specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us move forward. Tomáš prepared various trivial [[CDI]] sample projects and [[I]] was then able to get them running on [[NativeImage]] by writing a dedicated '''WeldFeature'''. Once the initial road block was gone the [[Helidon]] team was able to move forward on their own and get their enhanced [[Weld]] running on top of [[NativeImage]].

[[Helidon]] MP implements the [[MicroProfile]] specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us get started. Tomáš prepared various trivial [[CDI]] sample projects and [[I]] was then able to get them running on [[NativeImage]] by writing a dedicated '''WeldFeature'''. Once the initial road block was gone the [[Helidon]] team was able to move forward on their own and get their enhanced [[Weld]] running on top of [[NativeImage]].

[[Helidon]] 2.0 [https://medium.com/helidon/announcing-helidon-2-0-19c245f5488a was released] on June 24, 2020. It's [[MicroProfile]] edition (including compatible [[CDI]] implementation) works with [[NativeImage]].

[[Helidon]] 2.0 [https://medium.com/helidon/announcing-helidon-2-0-19c245f5488a was released] on June 24, 2020. It's [[MicroProfile]] edition (including compatible [[CDI]] implementation) works with [[NativeImage]].

[[Helidon]] MP implements the [[MicroProfile]] specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us move forward. Tomáš prepared various trivial [[CDI]] sample projects and [[I]] was then able to get them running on [[NativeImage]] by writing a dedicated '''WeldFeature'''. Once the initial road block was gone the [[Helidon]] team was able to move forward on their own and get their enhanced [[Weld]] running on top of [[NativeImage]].

[[Helidon]] MP implements the [[MicroProfile]] specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us move forward. Tomáš prepared various trivial [[CDI]] sample projects and [[I]] was then able to get them running on [[NativeImage]] by writing a dedicated '''WeldFeature'''. Once the initial road block was gone the [[Helidon]] team was able to move forward on their own and get their enhanced [[Weld]] running on top of [[NativeImage]].

[[Helidon]] 2.0 was released on June 24, 2020. It's [[MicroProfile]] edition (including compatible [[CDI]] implementation) works with [[NativeImage]].

[[Helidon]] 2.0 [https://medium.com/helidon/announcing-helidon-2-0-19c245f5488a was released] on June 24, 2020. It's [[MicroProfile]] edition (including compatible [[CDI]] implementation) works with [[NativeImage]].

=== [[Debugging]] ===

=== [[Debugging]] ===

=== [[Helidon]] MP 2.0 supports [[GraalVM]] [[NativeImage]] ===

=== [[Helidon]] MP 2.0 supports [[GraalVM]] [[NativeImage]] ===

[[Helidon]] MP implements the [[MicroProfile]] specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us move forward. Tomáš prepared various trivial [[CDI]] sample projects and [[I]] was then able to get them running on [[NativeImage]] by writing a dedicated '''WeldFeature'''. Once the initial road block was gone the [[Helidon]] team was able to move forward on their own and implement the whole [[CDI]] specification. [[Helidon]] 2.0 was released on June 24, 2020. It's [[MicroProfile]] edition works with [[NativeImage]].

[[Helidon]] MP implements the [[MicroProfile]] specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us move forward. Tomáš prepared various trivial [[CDI]] sample projects and [[I]] was then able to get them running on [[NativeImage]] by writing a dedicated '''WeldFeature'''. Once the initial road block was gone the [[Helidon]] team was able to move forward on their own and get their enhanced [[Weld]] running on top of [[NativeImage]].

 

[[Helidon]] 2.0 was released on June 24, 2020. It's [[MicroProfile]] edition (including compatible [[CDI]] implementation) works with [[NativeImage]].

=== [[Debugging]] ===

=== [[Debugging]] ===

=== [[Helidon]] MP 2.0 supports [[GraalVM]] [[NativeImage]] ===

=== [[Helidon]] MP 2.0 supports [[GraalVM]] [[NativeImage]] ===

[[Helidon]] MP implements the [[MicroProfile]] specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us move forward. Tomáš prepared various trivial [[CDI]] sample projects and [[I]] was then able to get them running on [[NativeImage]] by writing a dedicated '''WeldFeature'''. Once the initial road block was gone the [[Helidon]] team was able to move forward. [[Helidon]] 2.0 was released on June 24, 2020. It's [[MicroProfile]] edition works with [[NativeImage]].

[[Helidon]] MP implements the [[MicroProfile]] specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us move forward. Tomáš prepared various trivial [[CDI]] sample projects and [[I]] was then able to get them running on [[NativeImage]] by writing a dedicated '''WeldFeature'''. Once the initial road block was gone the [[Helidon]] team was able to move forward on their own and implement the whole [[CDI]] specification. [[Helidon]] 2.0 was released on June 24, 2020. It's [[MicroProfile]] edition works with [[NativeImage]].

=== [[Debugging]] ===

=== [[Debugging]] ===

Particularly tricky issue related to [[NativeImage]] is [[debugging]]. It is not easy to debug [[Java]] code with [[gdb]]. People tend to avoid doing so as much as possible. In certain situations that's however unavoidable and [[I]] tried to be as helpful as possible. I remember spending a week in [[debugging]] a [[race condition]] in the database connection driver just to find out that the sample is buggy and works in [[HotSpot]] mode just because [[HotSpot]] [[JVM]] is too slow when booting up.

Particularly tricky issue related to [[NativeImage]] is [[debugging]]. It is not easy to debug [[Java]] code with [[gdb]]. People tend to avoid doing so as much as possible. In certain situations that's however unavoidable and [[I]] tried to be as helpful as possible. I remember spending a week in [[debugging]] a [[race condition]] in the database connection driver just to find out that the sample is buggy and works in [[HotSpot]] mode just because [[HotSpot]] [[JVM]] is too slow when booting up.

One thread was connecting to a database to re-create sample table. E.g. dropping the previous one and creating new one. This worked without issues on [[HotSpot]] [[JVM]]. However with [[NativeImage]] generated executable (that boots and executes in microseconds), it was failing in 50% of cases. At the end, it turned out that while the first thread was re-populating new content of the table, another thread was querying the table and might get empty results, if it queried too fast. The [race condition]] was always there, but it only manifested on [[NativeImage]] as the second thread was ready to run at full speed since beginning and ''run ahead'' the initializing code - something that never happened with classing [[JVM]] setup.

One thread was connecting to a database to re-create sample table. E.g. dropping the previous one and creating new one. This worked without issues on [[HotSpot]] [[JVM]]. However with [[NativeImage]] generated executable (that boots and executes in microseconds), it was failing in 50% of cases. At the end, it turned out that while the first thread was re-populating new content of the table, another thread was querying the table and might get empty results, if it queried too fast. The [[race condition]] was always there, but it only manifested on [[NativeImage]] as the second thread was ready to run at full speed since beginning and ''run ahead'' the initializing code - something that never happened with classing [[JVM]] setup.

=== Related ===

=== Related ===

[[GraalVM]] offers not only [[NativeImage]] compilation, but also [[polyglot]] capabilities. During the [[FifthGraalAdventures]] we also prepared sample [[Helidon]] application that successfully use [[GraalVM]]'s [[Ruby]] and [[JavaScript]] interpreters to handle incoming connections.

[[GraalVM]] offers not only [[NativeImage]] compilation, but also [[polyglot]] capabilities. During the [[FifthGraalAdventures]] we also prepared sample [[Helidon]] application that successfully use [[GraalVM]]'s [[Ruby]] and [[JavaScript]] interpreters to handle incoming connections.

Particularly tricky issue related to [[NativeImage]] is [[debugging]]. It is not easy to debug [[Java]] code with [[gdb]]. People tend to avoid doing so as much as possible. In certain situations that's however unavoidable and [[I]] tried to be as helpful as possible. I remember spending a week in [[debugging]] a [[race condition]] in the database connection driver just to find out that the sample is buggy and works in [[HotSpot]] mode just because [[HotSpot]] [[JVM]] is too slow when booting up.

Particularly tricky issue related to [[NativeImage]] is [[debugging]]. It is not easy to debug [[Java]] code with [[gdb]]. People tend to avoid doing so as much as possible. In certain situations that's however unavoidable and [[I]] tried to be as helpful as possible. I remember spending a week in [[debugging]] a [[race condition]] in the database connection driver just to find out that the sample is buggy and works in [[HotSpot]] mode just because [[HotSpot]] [[JVM]] is too slow when booting up.

One thread was connecting to a database to re-create sample table. E.g. dropping the previous one and creating new one. This worked without issues on [[HotSpot]] [[JVM]]. However with [[NativeImage]] generated executable (that boots and executes in microseconds), it was failing in 50% of cases. At the end, it turned out that while the first thread was re-populating new content of the table, another one was querying the table and might get empty results. The [race condition]] was always there, but it only manifested on [[NativeImage]] as the second thread was ready to run at full speed since beginning and ''run ahead'' the initializing code - something that never happened with classing [[JVM]] setup.

One thread was connecting to a database to re-create sample table. E.g. dropping the previous one and creating new one. This worked without issues on [[HotSpot]] [[JVM]]. However with [[NativeImage]] generated executable (that boots and executes in microseconds), it was failing in 50% of cases. At the end, it turned out that while the first thread was re-populating new content of the table, another thread was querying the table and might get empty results, if it queried too fast. The [race condition]] was always there, but it only manifested on [[NativeImage]] as the second thread was ready to run at full speed since beginning and ''run ahead'' the initializing code - something that never happened with classing [[JVM]] setup.

=== Related ===

=== Related ===

[[GraalVM]] offers not only [[NativeImage]] compilation, but also [[polyglot]] capabilities. During the [[FifthGraalAdventures]] we also prepared sample [[Helidon]] application that successfully use [[GraalVM]]'s [[Ruby]] and [[JavaScript]] interpreters to handle incoming connections.

[[GraalVM]] offers not only [[NativeImage]] compilation, but also [[polyglot]] capabilities. During the [[FifthGraalAdventures]] we also prepared sample [[Helidon]] application that successfully use [[GraalVM]]'s [[Ruby]] and [[JavaScript]] interpreters to handle incoming connections.

=== [[Debugging]] ===

=== [[Debugging]] ===

Particularly tricky issue related to [[NativeImage]] is [[debugging]]. It is not easy to debug [[Java]] code with [[gdb]]. People tend to avoid doing so as much as possible. In certain situations that's however unavoidable and [[I]] tried to be as helpful as possible. I remember spending a week in [[debugging]] a [[race condition]] in the database connection driver just to find out that the test is buggy and works in [[HotSpot]] mode just because [[HotSpot]] is too slow when booting up.

Particularly tricky issue related to [[NativeImage]] is [[debugging]]. It is not easy to debug [[Java]] code with [[gdb]]. People tend to avoid doing so as much as possible. In certain situations that's however unavoidable and [[I]] tried to be as helpful as possible. I remember spending a week in [[debugging]] a [[race condition]] in the database connection driver just to find out that the sample is buggy and works in [[HotSpot]] mode just because [[HotSpot]] [[JVM]] is too slow when booting up.

One thread was connecting to a database to re-create sample table. E.g. dropping the previous one and creating new one. This worked without issues on [[HotSpot]] [[JVM]]. However with [[NativeImage]] generated executable (that boots and executes in microseconds), it was failing in 50% of cases. At the end, it turned out that while the first thread was re-populating new content of the table, another one was querying the table and might get empty results. The [race condition]] was always there, but it only manifested on [[NativeImage]] as the second thread was ready to run at full speed since beginning and ''run ahead'' the initializing code - something that never happened with classing [[JVM]] setup.

One thread was connecting to a database to re-create sample table. E.g. dropping the previous one and creating new one. This worked without issues on [[HotSpot]] [[JVM]]. However with [[NativeImage]] generated executable (that boots and executes in microseconds), it was failing in 50% of cases. At the end, it turned out that while the first thread was re-populating new content of the table, another one was querying the table and might get empty results. The [race condition]] was always there, but it only manifested on [[NativeImage]] as the second thread was ready to run at full speed since beginning and ''run ahead'' the initializing code - something that never happened with classing [[JVM]] setup.

=== [[Helidon]] MP 2.0 supports [[GraalVM]] [[NativeImage]] ===

=== [[Helidon]] MP 2.0 supports [[GraalVM]] [[NativeImage]] ===

[[Helidon]] MP implements the [[MicroProfile]] specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us move forward. Tomáš prepared various trivial [[CDI]] sample projects and [[I]] was then able to get them running on [[NativeImage]] by writing a dedicated '''WeldFeature'''. Once the initial road block was gone the [[Helidon]] team was able to move forward. [[Helidon]] 2.0 has been released on June 24, 2020. It's [[MicroProfile]] edition works with [[NativeImage]].

[[Helidon]] MP implements the [[MicroProfile]] specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us move forward. Tomáš prepared various trivial [[CDI]] sample projects and [[I]] was then able to get them running on [[NativeImage]] by writing a dedicated '''WeldFeature'''. Once the initial road block was gone the [[Helidon]] team was able to move forward. [[Helidon]] 2.0 was released on June 24, 2020. It's [[MicroProfile]] edition works with [[NativeImage]].

=== [[Debugging]] ===

=== [[Debugging]] ===

=== [[Debugging]] ===

=== [[Debugging]] ===

Particularly tricky issue related to [[NativeImage]] is [[debugging]]. It is not easy to debug [[Java]] code with [[gdb]]. People tend to avoid doing so as much as possible. In certain situations that's however unavoidable and [[I]] tried to be as helpful as possible. I remember spending a week in [[debugging]] a race condition in the database connection driver just to find out that the test is buggy and works in [[HotSpot]] mode just because [[HotSpot]] is too slow when booting up.

Particularly tricky issue related to [[NativeImage]] is [[debugging]]. It is not easy to debug [[Java]] code with [[gdb]]. People tend to avoid doing so as much as possible. In certain situations that's however unavoidable and [[I]] tried to be as helpful as possible. I remember spending a week in [[debugging]] a [[race condition]] in the database connection driver just to find out that the test is buggy and works in [[HotSpot]] mode just because [[HotSpot]] is too slow when booting up.

 

One thread was connecting to a database to re-create sample table. E.g. dropping the previous one and creating new one. This worked without issues on [[HotSpot]] [[JVM]]. However with [[NativeImage]] generated executable (that boots and executes in microseconds), it was failing in 50% of cases. At the end, it turned out that while the first thread was re-populating new content of the table, another one was querying the table and might get empty results. The [race condition]] was always there, but it only manifested on [[NativeImage]] as the second thread was ready to run at full speed since beginning and ''run ahead'' the initializing code - something that never happened with classing [[JVM]] setup.

=== Related ===

=== Related ===

[[GraalVM]] offers not only [[NativeImage]] compilation, but also [[polyglot]] capabilities. During the [[FifthGraalAdventures]] we also prepared sample [[Helidon]] application that successfully use [[GraalVM]]'s [[Ruby]] and [[JavaScript]] interpreters to handle incoming connections.

[[GraalVM]] offers not only [[NativeImage]] compilation, but also [[polyglot]] capabilities. During the [[FifthGraalAdventures]] we also prepared sample [[Helidon]] application that successfully use [[GraalVM]]'s [[Ruby]] and [[JavaScript]] interpreters to handle incoming connections.

[http://helidon.io helidon.io] is a microservices framework developed four meters away from me (my seat in [[Oracle]] Prague office). As such [[I]] am the natural fit for solving complex tasks that require understanding of both sides - the [[JavaEE]] landscape as well as the [[GraalVM]] internals.

[http://helidon.io helidon.io] is a microservices framework developed ''four meters away from me'' (my seat in [[Oracle]] Prague office). As such [[I]] felt as the natural fit for solving complex tasks that require understanding of both sides - the [[JavaEE]] landscape as well as the [[GraalVM]] internals.

[[Helidon]] MP implements the ''Java Micro Profile'' specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us move forward. Tomáš prepared various trivial [[CDI]] sample projects and [[I]] was then able to get them running on [[NativeImage]] by writing a dedicated '''WeldFeature'''. Once the initial road block was gone the [[Helidon]] team was able to move forward and is now about to release [[Helidon]] 2.0. It's Micro Profile edition is going to work with [[NativeImage]].

=== [[Helidon]] MP 2.0 supports [[GraalVM]] [[NativeImage]] ===

Particularly tricky issue related to [[NativeImage]] is [[debugging]]. It is not easy debug [[Java]] code with [[gdb]] people tend to avoid it as much as possible. In certain situations that's however unavoidable and [[I]] tried to be as helpful as possible. I remember spending week in debugging a race condition in the database connection driver just to find out that the test is buggy and works in [[HotSpot]] mode just because [[HotSpot]] is too slow when booting up.

[[Helidon]] MP implements the [[MicroProfile]] specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us move forward. Tomáš prepared various trivial [[CDI]] sample projects and [[I]] was then able to get them running on [[NativeImage]] by writing a dedicated '''WeldFeature'''. Once the initial road block was gone the [[Helidon]] team was able to move forward. [[Helidon]] 2.0 has been released on June 24, 2020. It's [[MicroProfile]] edition works with [[NativeImage]].

[[GraalVM]] offers not only [[NativeImage]] compilation, but also polyglot capabilities. During the [[FifthGraalAdventures]] we also modified [[Helidon]] to successfully use [[Ruby]] and [[JavaScript]] to handle incoming connections.

 

 

 

[[GraalVM]] offers not only [[NativeImage]] compilation, but also [[polyglot]] capabilities. During the [[FifthGraalAdventures]] we also prepared sample [[Helidon]] application that successfully use [[GraalVM]]'s [[Ruby]] and [[JavaScript]] interpreters to handle incoming connections.