Helidon - Revision history

JaroslavTulach: /* Helidon MP 2.0 supports GraalVM NativeImage */

JaroslavTulach — Mon, 29 Jun 2020 19:16:13 GMT

Helidon MP 2.0 supports GraalVM NativeImage

←Older revision		Revision as of 19:16, 29 June 2020
Line 3:		Line 3:
	=== [[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]].

JaroslavTulach at 15:34, 29 June 2020

JaroslavTulach — Mon, 29 Jun 2020 15:34:24 GMT

←Older revision		Revision as of 15:34, 29 June 2020
Line 5:		Line 5:
	[[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]] ===

JaroslavTulach: /* Helidon MP 2.0 supports GraalVM NativeImage */

JaroslavTulach — Mon, 29 Jun 2020 15:30:51 GMT

Helidon MP 2.0 supports GraalVM NativeImage

←Older revision		Revision as of 15:30, 29 June 2020
Line 3:		Line 3:
	=== [[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]] ===

JaroslavTulach: /* Helidon MP 2.0 supports GraalVM NativeImage */

JaroslavTulach — Mon, 29 Jun 2020 15:18:04 GMT

Helidon MP 2.0 supports GraalVM NativeImage

←Older revision		Revision as of 15:18, 29 June 2020
Line 3:		Line 3:
	=== [[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]] ===

JaroslavTulach: /* Debugging */

JaroslavTulach — Mon, 29 Jun 2020 15:14:56 GMT

Debugging

←Older revision		Revision as of 15:14, 29 June 2020
Line 9:		Line 9:
	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.

JaroslavTulach: /* Debugging */

JaroslavTulach — Mon, 29 Jun 2020 15:13:39 GMT

Debugging

←Older revision		Revision as of 15:13, 29 June 2020
Line 9:		Line 9:
	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.

JaroslavTulach: /* Debugging */

JaroslavTulach — Mon, 29 Jun 2020 15:12:28 GMT

Debugging

←Older revision		Revision as of 15:12, 29 June 2020
Line 7:		Line 7:
	=== [[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.

JaroslavTulach: /* Helidon MP 2.0 supports GraalVM NativeImage */

JaroslavTulach — Mon, 29 Jun 2020 15:11:36 GMT

Helidon MP 2.0 supports GraalVM NativeImage

←Older revision		Revision as of 15:11, 29 June 2020
Line 3:		Line 3:
	=== [[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]] ===

JaroslavTulach: /* Debugging */

JaroslavTulach — Mon, 29 Jun 2020 15:04:30 GMT

Debugging

←Older revision		Revision as of 15:04, 29 June 2020
Line 7:		Line 7:
	=== [[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.

JaroslavTulach at 14:57, 29 June 2020

JaroslavTulach — Mon, 29 Jun 2020 14:57:18 GMT

←Older revision		Revision as of 14:57, 29 June 2020
Line 1:		Line 1:
-	[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.	+	=== [[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.
		+
		+	=== 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.