Can Eclipse benefit from Project Leyden?

[danthe1st]

Project Leyden aims to improve startup and warmup time of Java applications.
With Eclipse being a very commonly used Open Source Java application, I think it makes sense to analyze how Eclipse can benefit from these improvements to the JDK.

Test setup

I have performed a few preliminary tests with Eclipse Platform (installed via the Eclipse Installer), Eclipse IDE for Java Developers and Eclipse IDE for Enterprise Java and Web Developers.
These tests were run with JDK 24.0.1 (Temurin) and JDK26 EA build 6.

I compared 3 different scenarios:

• Starting Eclipse normally
  • ./eclipse/eclipse -vm $JAVA_HOME/bin/java -debug
• Starting Eclipse with AppCDS
  • I ran ./eclipse/eclipse -vm /home/dan1st/.sdkman/candidates/java/26.ea.6-open/bin/java -debug -vmargs -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=app.cds consecutively but ignore the time of the first run (which creates the archive).
• Starting Eclipse with Ahead of Time Class-Loading and Linking
  • first record an AOT archive configuration: ./eclipse/eclipse -vm /home/dan1st/.sdkman/candidates/java/26.ea.6-open/bin/java -debug -vmargs -XX:AOTConfiguration=app.aotconf -XX:AOTMode=record
  • then create the AOT archive: ./eclipse/eclipse -vm /home/dan1st/.sdkman/candidates/java/26.ea.6-open/bin/java -debug -vmargs -XX:AOTConfiguration=app.aotconf -XX:AOTMode=create -XX:AOTCache=app.aot
  • run ./eclipse/eclipse -vm /home/dan1st/.sdkman/candidates/java/26.ea.6-open/bin/java -debug -vmargs -XX:AOTCache=app.aot and measure the time

I ran these tests on Kubuntu 25.04.

Operating System: Kubuntu 25.04
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.12.0
Qt Version: 6.8.3
Kernel Version: 6.14.0-15-generic (64-bit)
Graphics Platform: Wayland
Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz
Memory: 14.9 GiB of RAM
Graphics Processor: Intel® Iris® Xe Graphics
Manufacturer: HUAWEI
Product Name: KLVD-WXX9
System Version: M1260

Note that my system is very noisy.

Due to the -debug parameter, Eclipse prints the startup time in a line starting with Application started in :. This is what I used here.

Java versions:

openjdk version "24.0.1" 2025-04-15
OpenJDK Runtime Environment Temurin-24.0.1+9 (build 24.0.1+9)
OpenJDK 64-Bit Server VM Temurin-24.0.1+9 (build 24.0.1+9, mixed mode, sharing)

openjdk version "26-ea" 2026-03-17
OpenJDK Runtime Environment (build 26-ea+6-582)
OpenJDK 64-Bit Server VM (build 26-ea+6-582, mixed mode, sharing)

My expectations

• I have used CDS with Eclipse for quite some time by now and I consider it to be an improvement for my main installation. I expected it to be the same with other installations.
• I wasn't sure whether the AOT compilation would even succeed because Eclipse does a bunch of class loading and other things with OSGi.

My results

Eclipse installation	Java version	type	time 1	time 2	time 3	average time
Java	26-ea	normal	4847ms	4767ms	4620ms	4745ms
Java	26-ea	CDS	3872ms	3877ms	4088ms	3946ms
Java	26-ea	AOT	3876ms	3932ms	3815ms	3874ms
JEE	26-ea	normal	4888ms	5323ms	4857ms	5023ms
JEE	26-ea	CDS	4367ms	4903ms	4407ms	4559ms
JEE	26-ea	AOT	4424ms	4773ms	4514ms	4570ms
Platform	26-ea	normal	3517ms	3175ms	3225ms	3306ms
Platform	26-ea	CDS	2833ms	2798ms	2638ms	2755ms
Platform	26-ea	AOT	2755ms	2731ms	2729ms	2738ms
Java	24	normal	5064ms	5494ms	5264ms	5274ms
Java	24	CDS	4534ms	4586ms	4195ms	4438ms
Java	24	AOT	5179ms	4843ms	5221ms	5081ms
JEE	24	normal	7363ms	5525ms	5807ms	6031ms
JEE	24	CDS	4581ms	5287ms	4879ms	4916ms
JEE	24	AOT	5331ms	5876ms	5879ms	5695ms
Platform	24	normal	3637ms	3260ms	3124ms	3340ms
Platform	24	CDS	2827ms	2926ms	2703ms	2819ms
Platform	24	AOT	3306ms	3218ms	3241ms	3255ms

For every combination of Eclipse installation and JDK version, I marked the best installation type (by average time) in bold.

It seems like using AppCDS consistently results in faster startup of Eclipse compared to not using it.
With the JDK 26 EA build, it seems like CDS and AOT are pretty similar (maybe AOT failed and it "just" did CDS in the AOT archive?) but not really with JDK 24 (there were also issues creating the archive, see the next section)

With CDS (which is available with -XX:+AutoCreateSharedArchive since JDK 19), I got an ~500-1000ms startup improvement which seems pretty good.

Issues

The create face of the AOT phase didn't run cleanly but the errors were "worse" with JDK 24. In both cases, it did create a "usable" archive but (at least with JDK 24) it couldn't process a lot of it as it seems.

With JDK 26, I am getting similar logs to:

[0.074s][error][aot] An error has occurred while processing the AOT configuration file. Run with -Xlog:aot for details.
[0.074s][error][aot] archivedBootLayer not available, disabling full module graph
AOTCache creation is complete: app.aot 106397696 bytes

With JDK, I am getting a lot of warnings (even without -Xlog:aot) like and it takes a comparatively long time to create:

[1.442s][warning][cds] Preload Warning: Verification failed for org.apache.felix.scr.impl.manager.ExtendedServiceEvent
[5.721s][warning][cds] Preload Warning: Verification failed for org.eclipse.ui.forms.widgets.ExpandableComposite
[6.012s][warning][cds] Preload Warning: Verification failed for org.eclipse.core.internal.resources.ProjectPreferences
[6.097s][warning][cds] Preload Warning: Verification failed for org.eclipse.core.internal.events.AutoBuildJob
[7.666s][warning][cds] Preload Warning: Verification failed for org.eclipse.egit.core.RepositoryHandle
[8.496s][warning][cds] Preload Warning: Verification failed for org.eclipse.emf.ecore.impl.EClassImpl$1EAllStructuralFeaturesList
[8.720s][warning][cds] Preload Warning: Verification failed for ch.qos.logback.classic.pattern.PrefixCompositeConverter
[9.295s][warning][cds] Preload Warning: Verification failed for org.eclipse.ui.internal.commands.CommandStateProxy
...

See the following output with -Xlog:aot (the order of stdout and stderr might be a bit messed up due to me using 2>&1 | xclip -selection clipboard):
AOT_logs_26ea.txt
AOT_logs_24.txt

Discussion

I think it would be good if more people test these things.
If CDS results is a general improvement for most people, it might be a good idea to eventually add the CDS option to the eclipse.ini by default. However, care should be taken with lombok (it strikes/causes issues once more) as that attaches an agent which requires the use of -XX:+UnlockDiagnosticVMOptions and -XX:+AllowArchivingWithJavaAgent which is unstable (it does work for me without issues but it would probably be a good idea to not enable CDS if Lombok (or any agent) is installed into Eclipse). Also, if Eclipse is updated, it might be worth considering to remove the CDS files (so that they are regenerated).
If CDS gets added by default at some point, I should still be easy to disable it (e.g. if someone wants to use the AOT capabilities (which don't seem to work together with the normal CDS) or if CDS causes some issues).

For AOT, the setup is a bit more complicated. While JEP 514 simplifies that process by only requiring two commands, it's still not where it could be. I don't think AOT is ready to be used in Eclipse by default (especially since it is only available in newer JDKs and doesn't seem to provide that big of an improvement over CDS yet).

[vogella]

Adding @jonahgraham and @merks to the discussion. The Eclipse packages use a pre-packaged JRE which AFAIK are based on Temurin.

[merks]

Adding @jonahgraham and @merks to the discussion. The Eclipse packages use a pre-packaged JRE which AFAIK are based on Temurin.

We generate a CDS archive when we generate the JustJ JREs from the Temurin JDKs.

https://github.com/eclipse-justj/justj/blob/9a29ae2d3b99211dbf32c2d2197435165fe83453/releng/org.eclipse.justj.releng/build-jre.sh#L293

[danthe1st]

We generate a CDS archive when we generate the JustJ JREs from the Temurin JDKs.

While the default archive is already a significant benefit, it only includes JDK classes and nothing specific to the Eclipse IDE AFAIK. When I said CDS, I was talking about AppCDS which allows archiving application classes.

[laeubi]

I think it all depends on how much one would invest (in terms of initial efforts and maintenance) to safe a few (milli)seconds. For me I usually start the IDE in the morning and close it in the evening. If it takes a few seconds longer is not relevant to me.

But if you are dedicated to this, the best is create a PR, show whats needed and that it works and then it might gets integrated. Also keep in mind that startup time is usually irrelevant, e.g. resolving a target from a slow server can take several decades longer and an building large projects as well. So for me time between starting the IDE and being able to start coding is the only relevant measure. Also responsiveness and speed on changes does much more affects me than the IDE taking 1 or 10 second to load.

[danthe1st]

I think it all depends on how much one would invest (in terms of initial efforts and maintenance) to safe a few (milli)seconds. For me I usually start the IDE in the morning and close it in the evening. If it takes a few seconds longer is not relevant to me.

I generally agree but I think that at least CDS (IMO AOT is currently at a point where it is not worth getting through the effort for Eclipse but CDS is easy to use) is worth considering (even if it is not implemented):

• Not all people use Eclipse in the same way. If someone e.g. uses Eclipse Platform with a few plugins as a better text editor (in which case they might start it as well), the increase would be more noticable (2.7 instead of 3.3 seconds if I take the averages).
• I think it would not just be the direct startup time but also e.g. time until the first editor loads.
• With AOT (especially with things like Ahead-of-Time Method Profiling (I think that's not in the EA build I was using?) and the planned Ahead-of-Time Code Compilation), this can not just improve startup but also warmup time and making it responsive before everything is JITed (e.g. this could make the editors faster at the beginning).
• In my opinion, startup time is something people notice. While I agree that responsiveness is (at least for applications like Eclipse) more important, having to wait for an application to start is time where people actively wait seeing that the application is "slow"/I think this can make a big difference in perceived performance.
• As mentioned by @HeikoKlare, RCP applications could benefit from that as well.

Given these points, I think it's good to have public discussion about this even if it is too early to add anything to the Eclipse IDE already. If Vector is successful with it, I think it could benefit everyone to have a common place of discussion and have one solution instead of many.

[HeikoKlare]

Thank you for raising the topic and sharing the great analysis, @danthe1st! This is a topic we have on the list for investigation for our RCP product for quite some time, so it's great to see those refernece result based on the IDE as another RCP product.

It might be true that for usual IDE setups the impact of improved startup time is not that high, but it might be different for other RCP products (like it is for ours). That's why I would not only see benefit in improving the IDE startup time but also in testing/demonstrating that and how it works for other RCP products.
Still, even for the IDE, every improvement in startup time that we can make with low effort is worth it is basically a low-hanging fruit to improve UX. Why wouldn't anyone want that if it does not have any other negative impact?
I remember that we discussed about the potential negative impact of on-the-fly rasterization of SVGs on the startup time, where something in the range of hundreds of milliseconds was considered as potentially severe, so if we can reach hundreds of milliseconds or even seconds of improvement easily with this, it would be strange to consider that irrelevant.

[danthe1st]

Still, even for the IDE, every improvement in startup time that we can make with low effort is worth it is basically a low-hanging fruit to improve UX. Why wouldn't anyone want that if it does not have any other negative impact?

There are a few things that could still cause issues, two coming to my mind:

• Changes to the loaded classes: With updates of plugins, the IDE or whatever, parts of the archive. It might be necessary to regenerate it or do similar things.
  • While this works for AppCDS, I am not sure how well AOT deals with it.
• It might not work in some cases. For example, if you are using agents (with lombok probably being the most prominent example of injecting agents into Eclipse), you need to add -XX:+UnlockDiagnosticVMOptions -XX:+AllowArchivingWithJavaAgent to the VM arguments when starting Eclipse and when creating the AOT archive (-XX:AOTMode=create).
• Since AOT is still pretty new, there are quite a few changes on the way with new JDK versions (I think AOT is not available with JDK 21 and some stuff is in JDK 24, 25 or not integrated yet).

If you have any analysis to share (and can share it) for your RCP application, I would be glad to see it.

[danthe1st]

Also I think that creating an AOT archive may be easier to achieve for RCP applications compared to the Eclipse IDE in general assuming these AOT applications typically don't update some components and not others (i.e. that one would typically update the whole application to the latest version in which case the AOT archive could be distributed with the application).

With AppCDS, it would be pretty easy to just generate it when first running the application (that's also possible with the AOT archive but currently more difficult). But I am not sure how well all of that work with switching between different JVMs (probably not but ideally, it should at least not prevent the application from starting).

[HeikoKlare]

Also I think that creating an AOT archive may be easier to achieve for RCP applications compared to the Eclipse IDE in general assuming these AOT applications typically don't update some components and not others (i.e. that one would typically update the whole application to the latest version in which case the AOT archive could be distributed with the application).

Indeed. It's just that for many of them AOT is probably much more a future topic as it requires an update to a Java LTS version that has not even been released by now :-)

I was so hyped by your results that I just took a bit of time to make some initial testing with our product, just based on setting the properties required for AppCDS. Measurements are made with a JDK 21. I measured different checkpoints of our overall startup process with the following very rough results (average of three runs with only slight variation in execution times):

	Without AppCDS	With AppCDS
Checkpoint 1	60 seconds	45 seconds
Checkpoint 2	75 seconds	49 seconds

I have to properly verify again, but if the measurements are at least correct to a certain degree, such an improvement would be awesome.

[danthe1st]

I also tried using it with my personal Eclipse installation (based on Eclipse for Java EE and Web Developers including Lombok, Spring Tools (that actually loads Spring or parts of it, but I'm not sure whether that happens in the same JVM or in a language server JVM) and other things - my "Installed Software" tab has 124 entries).

Java version	type	time 1	time 2	time 3	average time
26-ea	normal	10279ms	9803ms	10830ms	10304ms
26-ea	CDS	8285ms	8454ms	9495ms	8745ms
26-ea	AOT	8103ms	7839ms	8448ms	8130ms

This allows me to shave off around 1300ms with CDS or around 1900ms with AOT in that very limited test.

I am not able to create an AOT archive for that Eclipse installation with JDK 24 (seems to fail due to Lombok's agent, see the following output).

[52.191s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime:
[52.191s][warning][cds,heap] Field: org/lombokweb/asm/Opcodes::INTEGER
[52.191s][warning][cds,heap] Value: java.lang.Integer 
[52.191s][warning][cds,heap] {0x000000071161ad30} - klass: 'java/lang/Integer' - flags: 
[52.191s][warning][cds,heap] 
[52.191s][warning][cds,heap]  - ---- fields (total size 2 words):
[52.191s][warning][cds,heap]  - private final 'value' 'I' @12  1 (0x00000001)
[52.191s][warning][cds,heap] --- trace begin ---
[52.191s][warning][cds,heap] [ 0] {0x00000007119723d0} [Ljava.lang.Integer; @[129]
[52.191s][warning][cds,heap] [ 1] {0x000000071161ad30} java.lang.Integer
[52.191s][warning][cds,heap] --- trace end ---
[52.191s][warning][cds,heap] 
[52.191s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime:
[52.191s][warning][cds,heap] Field: org/lombokweb/asm/Opcodes::TOP
[52.191s][warning][cds,heap] Value: java.lang.Integer 
[52.191s][warning][cds,heap] {0x000000071161ad40} - klass: 'java/lang/Integer' - flags: 
[52.191s][warning][cds,heap] 
[52.191s][warning][cds,heap]  - ---- fields (total size 2 words):
[52.191s][warning][cds,heap]  - private final 'value' 'I' @12  0 (0x00000000)
[52.191s][warning][cds,heap] --- trace begin ---
[52.191s][warning][cds,heap] [ 0] {0x00000007119723d0} [Ljava.lang.Integer; @[128]
[52.191s][warning][cds,heap] [ 1] {0x000000071161ad40} java.lang.Integer
[52.191s][warning][cds,heap] --- trace end ---
[52.191s][warning][cds,heap] 
[52.192s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime:
[52.192s][warning][cds,heap] Field: org/lombokweb/asm/Opcodes::LONG
[52.192s][warning][cds,heap] Value: java.lang.Integer 
[52.192s][warning][cds,heap] {0x00000007116d6670} - klass: 'java/lang/Integer' - flags: 
[52.192s][warning][cds,heap] 
[52.192s][warning][cds,heap]  - ---- fields (total size 2 words):
[52.192s][warning][cds,heap]  - private final 'value' 'I' @12  4 (0x00000004)
[52.192s][warning][cds,heap] --- trace begin ---
[52.192s][warning][cds,heap] [ 0] {0x00000007119723d0} [Ljava.lang.Integer; @[132]
[52.192s][warning][cds,heap] [ 1] {0x00000007116d6670} java.lang.Integer
[52.192s][warning][cds,heap] --- trace end ---
[52.192s][warning][cds,heap] 
[52.193s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime:
[52.193s][warning][cds,heap] Field: org/lombokweb/asm/Opcodes::FLOAT
[52.193s][warning][cds,heap] Value: java.lang.Integer 
[52.193s][warning][cds,heap] {0x00000007116d4b40} - klass: 'java/lang/Integer' - flags: 
[52.193s][warning][cds,heap] 
[52.193s][warning][cds,heap]  - ---- fields (total size 2 words):
[52.193s][warning][cds,heap]  - private final 'value' 'I' @12  2 (0x00000002)
[52.193s][warning][cds,heap] --- trace begin ---
[52.193s][warning][cds,heap] [ 0] {0x00000007119723d0} [Ljava.lang.Integer; @[130]
[52.193s][warning][cds,heap] [ 1] {0x00000007116d4b40} java.lang.Integer
[52.193s][warning][cds,heap] --- trace end ---
[52.193s][warning][cds,heap] 
[52.193s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime:
[52.193s][warning][cds,heap] Field: org/lombokweb/asm/Opcodes::DOUBLE
[52.193s][warning][cds,heap] Value: java.lang.Integer 
[52.193s][warning][cds,heap] {0x00000007116d4a88} - klass: 'java/lang/Integer' - flags: 
[52.193s][warning][cds,heap] 
[52.193s][warning][cds,heap]  - ---- fields (total size 2 words):
[52.193s][warning][cds,heap]  - private final 'value' 'I' @12  3 (0x00000003)
[52.193s][warning][cds,heap] --- trace begin ---
[52.193s][warning][cds,heap] [ 0] {0x00000007119723d0} [Ljava.lang.Integer; @[131]
[52.193s][warning][cds,heap] [ 1] {0x00000007116d4a88} java.lang.Integer
[52.193s][warning][cds,heap] --- trace end ---
[52.193s][warning][cds,heap] 
[52.194s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime:
[52.194s][warning][cds,heap] Field: org/lombokweb/asm/Opcodes::UNINITIALIZED_THIS
[52.194s][warning][cds,heap] Value: java.lang.Integer 
[52.194s][warning][cds,heap] {0x0000000711712460} - klass: 'java/lang/Integer' - flags: 
[52.194s][warning][cds,heap] 
[52.194s][warning][cds,heap]  - ---- fields (total size 2 words):
[52.194s][warning][cds,heap]  - private final 'value' 'I' @12  6 (0x00000006)
[52.194s][warning][cds,heap] --- trace begin ---
[52.194s][warning][cds,heap] [ 0] {0x00000007119723d0} [Ljava.lang.Integer; @[134]
[52.194s][warning][cds,heap] [ 1] {0x0000000711712460} java.lang.Integer
[52.194s][warning][cds,heap] --- trace end ---
[52.194s][warning][cds,heap] 
[52.194s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime:
[52.194s][warning][cds,heap] Field: org/lombokweb/asm/Opcodes::NULL
[52.194s][warning][cds,heap] Value: java.lang.Integer 
[52.194s][warning][cds,heap] {0x0000000711712470} - klass: 'java/lang/Integer' - flags: 
[52.194s][warning][cds,heap] 
[52.194s][warning][cds,heap]  - ---- fields (total size 2 words):
[52.194s][warning][cds,heap]  - private final 'value' 'I' @12  5 (0x00000005)
[52.194s][warning][cds,heap] --- trace begin ---
[52.194s][warning][cds,heap] [ 0] {0x00000007119723d0} [Ljava.lang.Integer; @[133]
[52.194s][warning][cds,heap] [ 1] {0x0000000711712470} java.lang.Integer
[52.194s][warning][cds,heap] --- trace end ---
[52.194s][warning][cds,heap] 
[52.194s][error  ][cds,heap] Scanned 95695 objects. Found 7 case(s) where an object points to a static field that may hold a different value at runtime.
[52.194s][error  ][cds     ] An error has occurred while writing the shared archive file.

[danthe1st]

I also mentioned my tests on the leyden-dev mailing list and got a suggestion to remove --add-modules=ALL-SYSTEM from the eclipse.ini file. With that, I'm getting rid of the error and I got the following results (only tested the normal Eclipse Java installation and my personal one):

Java version	type	time 1	time 2	time 3	average time
26-ea	normal	4692ms	4941ms	4686ms	4773ms
26-ea	CDS	4099ms	4022ms	4294ms	4205ms
26-ea	AOT	3418ms	3541ms	3538ms	3499ms
26-ea	normal	10789ms	11603ms	12493ms	11628ms
26-ea	CDS	10878ms	10613ms	10752ms	10744ms
26-ea	AOT	8604ms	7496ms	8373ms	8158ms

So it seems like AOT works best without --add-modules=ALL-SYSTEM (specifically without incubator modules) if this is possible. With this, I can also see an improvement with AOT over CDS.
What is the reason for Eclipse using --add-modules=ALL-SYSTEM in the packages I tried? I assume so that plugin developers can just make use of all of the JDK modules (it being difficult to provide them with OSGi?)

(I guess there are some differences in my results due to me running these tests on another day.)

[merks]

FYI. The JustJ JREs exclude the incubators.

[danthe1st]

Since the first JDK 25 release candidate is out, I ran my tests with that.
I used the following test setup:

• JDK 25 RC1 from https://openjdk.org/projects/jdk/25/
• same machine as before
• I created a script running Eclipse for Java Developers and Eclipse IDE for Enterprise Java and Web Developers normally, with CDS and AOT 5 times each
  • I removed the --add-modules=ALL-SYSTEM from the eclipse.ini files
• This script automatically measures the startup time but I still need to manually close all of the Eclipse windows

Script:

#!/bin/bash

set -e
set -o pipefail

JDK_BIN='/home/dan1st/dev/tools/jdk-25rc1/bin/java'

ECLIPSES_DIR='/home/dan1st/dev/tools/eclipse_test'

CACHE_DIR='/tmp/eclipse_cache'

REPORT_FILE="$PWD/eclipse_startup_report.md"

rm -rf "$CACHE_DIR" || true
mkdir -p "$CACHE_DIR"
cd "$CACHE_DIR"
rm "$REPORT_FILE" || true

function measure() {
	eclipse_name="$1"
	eclipse_bin="$ECLIPSES_DIR/$eclipse_name/eclipse"
	mode="$2"
	eclipse_args="$3"
	result_file="eclipse_${eclipse_name}_${mode}_results.txt"

	echo "testing $eclipse_name with $mode..."
	for run in {1..5}; do
		runtime="$("$eclipse_bin" -vm "$JDK_BIN" -debug -vmargs $eclipse_args 2>&1 | tee "eclipse_${eclipse_name}_measure.log" | grep 'Application started in :'|cut -d':' -f2|sed 's/[^0-9]//g')"
		echo "took ${runtime}ms to start"
		echo "$runtime" >> "$result_file"
	done
	sum_time="$(paste -sd+ "$result_file" | bc)"
	n_runs=5
	average_time=$((sum_time / n_runs))
	min_time="$(sort -n < "$result_file" | head -n 1)"
	max_time="$(sort -rn < "$result_file" | head -n 1)"
	echo "|$eclipse_name|$mode|$average_time|$min_time|$max_time|" >> "$REPORT_FILE"
}


echo "|installation|type|avg time|min time|max time|" >> "$REPORT_FILE"
echo "|---|---|---|---|--|" >> "$REPORT_FILE"
for eclipseDir in $(ls "$ECLIPSES_DIR"); do
	
	rm app.cds app.aot 2>/dev/null || true
	echo "preparing $eclipseDir..."
	"$ECLIPSES_DIR/$eclipseDir/eclipse" -vm "$JDK_BIN" -vmargs -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=app.cds > "eclipse_${eclipseDir}_prep.log" 2>&1
	"$ECLIPSES_DIR/$eclipseDir/eclipse" -vm "$JDK_BIN" -vmargs -XX:AOTConfiguration=app.aotconf -XX:AOTMode=record > "eclipse_${eclipseDir}_prep.log" 2>&1
	"$ECLIPSES_DIR/$eclipseDir/eclipse" -vm "$JDK_BIN" -vmargs -XX:AOTConfiguration=app.aotconf -XX:AOTMode=create -XX:AOTCache=app.aot > "eclipse_${eclipseDir}_prep.log" 2>&1

	[ -f "app.cds" ]
	[ -f "app.aot" ]

	echo "run measurements for $eclipseDir..."
	measure "$eclipseDir" "normal" ""
	measure "$eclipseDir" "CDS" "-XX:SharedArchiveFile=app.cds"
	measure "$eclipseDir" "AOT" "-XX:AOTCache=app.aot"

done

Results:

installation	type	avg time	min time	max time
java	normal	5043	4845	5261
java	CDS	4572	4332	4815
java	AOT	3997	3878	4263
jee	normal	6054	5706	6367
jee	CDS	5347	5025	5823
jee	AOT	4851	4537	5200

With these results, I can somewhat confidently (despite my measurements not being scientific) say that AOT is better than (App)CDS is better than nothing when it comes to Eclipse startup time (and the AOT cache would likely also improve performance of the IDE in general at the beginning of a run).

For RCP products that come with a JDK, I think it should be doable to ship with an AOT cache already built. Alternatively, I also think that building a CDS archive/an AOT cache if it doesn't exist (and delete it after every update) should be doable.

individual startup times:

preparing java...
run measurements for java...
testing java with normal...
took 4845ms to start
took 5084ms to start
took 5063ms to start
took 5261ms to start
took 4964ms to start
testing java with CDS...
took 4673ms to start
took 4332ms to start
took 4615ms to start
took 4428ms to start
took 4815ms to start
testing java with AOT...
took 3966ms to start
took 3999ms to start
took 3882ms to start
took 4263ms to start
took 3878ms to start
preparing jee...
run measurements for jee...
testing jee with normal...
took 6084ms to start
took 5706ms to start
took 6367ms to start
took 5778ms to start
took 6337ms to start
testing jee with CDS...
took 5025ms to start
took 5525ms to start
took 5210ms to start
took 5823ms to start
took 5155ms to start
testing jee with AOT...
took 5200ms to start
took 4537ms to start
took 5078ms to start
took 4555ms to start
took 4888ms to start