AbstractBundleContainer.java - Caching & Performance

[vogella]

Optimizations:

• Line 72: Renamed poorly-named static field hash to fVMArgsCache with proper documentation - much clearer intent
• Line 229-233: Replaced inefficient loop through hash entries (for (Entry<...> entry : hash.entrySet())) with direct HashMap get() - O(n) → O(1) lookup
• Line 268, 271: Updated all references to use the renamed fVMArgsCache

Impact:

• Major performance improvement: Changed from O(n) iteration through all cache entries to O(1) HashMap lookup
• Better code clarity with descriptive naming
• No API changes - purely internal optimization

[laeubi]

@vogella I don't think that such "modernization" currently bring us forward, if you absolute want this can you place make sure that:

1. We can not cover it by cleanup action, if we can, enable them and let it happen automatically
2. Batch other changes in one PR after cleanups where run.

[vogella]

@vogella I don't think that such "modernization" currently bring us forward, if you absolute want this can you place make sure that:

1. We can not cover it by cleanup action, if we can, enable them and let it happen automatically
2. Batch other changes in one PR after cleanups where run.

I'm currently not looking into clean-up actions and have no plans to do so. Thanks for the suggestions but AFAIK according to the Eclipse policy you are not entitled to tell other committers how to work.

[vogella]

I assume the build will fail (PDE build is currently not working), so I plan to leave this here and return to it, once PDE build are green again.

[laeubi]

I'm currently not looking into clean-up actions and have no plans to do so. Thanks for the suggestions but AFAIK according to the Eclipse policy you are not entitled to tell other committers how to work.

You can work as you like, but as soon as you open a PR you need to accept to get it reviewed and probably there are some discussion, suggestions and best practices.

For a while we have enabled cleanups to get a consistent codebase and to improve JDT leanups and you even agreed and asked it to rool out to platform, so it feel a bit odd now to complain.

So if cleaning up the codebase is important to you I can only ask to follow what is established as it works on a larger scale and we are already familiar with that and it makes sure the same style is applied also in the future.

[github-actions]

Test Results

   771 files  ±0     771 suites  ±0   58m 2s ⏱️ + 3m 4s
 3 648 tests ±0   3 594 ✅ ±0   54 💤 ±0  0 ❌ ±0 
10 878 runs  ±0  10 715 ✅ ±0  163 💤 ±0  0 ❌ ±0 

Results for commit e4b5d8d. ± Comparison against base commit ca484e5.

♻️ This comment has been updated with latest results.

[HannesWell]

This performance optimazation seems useful.

But for my taste this adds too many comments and I also think the commit message isn't suitable.
Instead of listing the changes line-by-line it should give an high level overview over the change and/or explain the rational behind it.
The headline could also be more expressive, like
Speed-up vm-arguments lookup in AbstractBundleContainer or similar.

Due to this style I assume this change is AI generated, isn't it?
I know they are good at generating text, but I think we should still only add what's necessary and avoid what's not. Even comments have to be maintained.

[HannesWell]

I think this comment is superflous and should be removed. IMHO comments only should be added if the code itself isn't clear or needs further explaination about its background.
In this case I think the use of this map is is obvious enough and I would just remove this comment.
The renmaing clearly helps to make the purpose obvious.

[HannesWell]

This comment is IMO also superflous.

Suggested change

// Check cache first for faster lookup

Obsolete now, hand review over to hannes

[akurtakov]

A general statement: As much as automated optimizations/cleanups/modernizations/etc. are preferred, if someone feels like doing such a thing manually or via some other tool - It's equally welcome. We can make use of all the improvements in whatever way someone might decide to deliver them.

[vogella]

Thanks @HannesWell update the PR according to your comments

[HannesWell]

Thanks for the update.
This looks good to me now.

[eclipse-pde-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

ui/org.eclipse.pde.core/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From c12c21ce294a2e9cd2ea3fa1a12982ed0b783173 Mon Sep 17 00:00:00 2001
From: Eclipse PDE Bot <pde-bot@eclipse.org>
Date: Mon, 1 Dec 2025 14:16:04 +0000
Subject: [PATCH] Version bump(s) for 4.39 stream


diff --git a/ui/org.eclipse.pde.core/META-INF/MANIFEST.MF b/ui/org.eclipse.pde.core/META-INF/MANIFEST.MF
index a83a7c3f04..d1d5acc8e3 100644
--- a/ui/org.eclipse.pde.core/META-INF/MANIFEST.MF
+++ b/ui/org.eclipse.pde.core/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %name
 Bundle-SymbolicName: org.eclipse.pde.core; singleton:=true
-Bundle-Version: 3.21.100.qualifier
+Bundle-Version: 3.21.200.qualifier
 Bundle-Activator: org.eclipse.pde.internal.core.PDECore
 Bundle-Vendor: %provider-name
 Bundle-Localization: plugin
-- 
2.51.2

Further information are available in Common Build Issues - Missing version increments.