Clean Code for bundles/org.eclipse.equinox.http.jetty

[eclipse-equinox-bot]

The following cleanups were applied:

• Add final modifier to private fields
• Add missing '@Deprecated' annotations
• Add missing '@Override' annotations
• Add missing '@Override' annotations to implementations of interface methods
• Convert control statement bodies to block
• Make inner classes static where possible
• Remove trailing white spaces on all lines
• Remove unnecessary array creation for varargs
• Remove unnecessary suppress warning tokens
• Remove unused imports
• Remove unused private constructors
• Remove unused private fields
• Remove unused private methods
• Remove unused private types
• Replace deprecated calls with inlined content where possible
• Use pattern matching for instanceof

The following Manifest cleanups where applied:

• Calculate 'uses' directive for public packages
• Remove unused dependencies

[github-actions]

Test Results

  810 files  ±0    810 suites  ±0   1h 35m 51s ⏱️ + 2m 13s
2 222 tests ±0  2 173 ✅ ±0   49 💤 ±0  0 ❌ ±0 
6 678 runs  ±0  6 529 ✅ ±0  149 💤 ±0  0 ❌ ±0 

Results for commit 7613e81. ± Comparison against base commit add2865.

♻️ This comment has been updated with latest results.

[laeubi]

This needs to be fixed in PDE (or bnd...) as it leads to

Access restriction: The method 'AbstractLifeCycle.stop()' is not API (restriction on classpath entry '/home/jenkins/agent/workspace/equinox_PR-1080/.m2/repository/org/eclipse/jetty/jetty-util/12.0.23/jetty-util-12.0.23.jar')

I have not yet found out why bndlib thing the package is not referenced, maybe because the method is overriden in a subclass and the compiler emits a reference to the subclass.

[laeubi]

I have now created

• Do not emit restriction warning on inherited method eclipse-jdt/eclipse.jdt.core#4293

the reason for the restriction errors is that JDT handles methods inherited from super class different from those directly overridden.

[eclipse-equinox-bot]

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

bundles/org.eclipse.equinox.http.jetty/META-INF/MANIFEST.MF
features/org.eclipse.equinox.server.jetty/feature.xml

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 9690760fd94f6171989c3e9daf99e8ac11f9b445 Mon Sep 17 00:00:00 2001
From: Eclipse Equinox Bot <equinox-bot@eclipse.org>
Date: Wed, 3 Sep 2025 03:08:44 +0000
Subject: [PATCH] Version bump(s) for 4.38 stream


diff --git a/bundles/org.eclipse.equinox.http.jetty/META-INF/MANIFEST.MF b/bundles/org.eclipse.equinox.http.jetty/META-INF/MANIFEST.MF
index a35c8a37d..46740e1b0 100644
--- a/bundles/org.eclipse.equinox.http.jetty/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.equinox.http.jetty/META-INF/MANIFEST.MF
@@ -4,7 +4,7 @@ Bundle-Name: %bundleName
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
 Bundle-SymbolicName: org.eclipse.equinox.http.jetty
-Bundle-Version: 3.9.500.qualifier
+Bundle-Version: 3.9.600.qualifier
 Bundle-Activator: org.eclipse.equinox.http.jetty.internal.Activator
 Import-Package: javax.servlet;version="[3.1.0,5.0.0)",
  javax.servlet.http;version="[3.1.0,5.0.0)",
diff --git a/features/org.eclipse.equinox.server.jetty/feature.xml b/features/org.eclipse.equinox.server.jetty/feature.xml
index 7deca534b..ef4a5d29d 100644
--- a/features/org.eclipse.equinox.server.jetty/feature.xml
+++ b/features/org.eclipse.equinox.server.jetty/feature.xml
@@ -2,7 +2,7 @@
 <feature
       id="org.eclipse.equinox.server.jetty"
       label="%featureName"
-      version="1.11.800.qualifier"
+      version="1.11.900.qualifier"
       provider-name="%providerName"
       license-feature="org.eclipse.license"
       license-feature-version="0.0.0">
-- 
2.51.0

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

[laeubi]

The JDT change was merged, so lets see how far we get now!

[laeubi]

Seems to still using 3.44.0.v20251023-0518 so from Oct 23 ... @HannesWell should the jdt compiler not automatically deployed and used?

[HannesWell]

should the jdt compiler not automatically deployed and used?

In general yes, but not if the build is unstable (because ECJ changes are regularly the cause of comparator-errors and then it should be investigated). And we had a few unstable builds.

[laeubi]

It all seems fine now!