[23] Add implementation for Types#stripAnnotations() #3439

[jarthana]

What it does

Fixes #3439

How to test

Author checklist

• I have thoroughly tested my changes
• The change is following the coding conventions
• I have signed the Eclipse Contributor Agreement (ECA)

[eclipse-jdt-bot]

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

org.eclipse.jdt.compiler.tool.tests/META-INF/MANIFEST.MF
org.eclipse.jdt.compiler.tool.tests/pom.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 e8c0e23800ddc6dcacbc1673d734a5ee650f0f07 Mon Sep 17 00:00:00 2001
From: Eclipse JDT Bot <jdt-bot@eclipse.org>
Date: Thu, 12 Dec 2024 09:51:12 +0000
Subject: [PATCH] Version bump(s) for 4.35 stream


diff --git a/org.eclipse.jdt.compiler.tool.tests/META-INF/MANIFEST.MF b/org.eclipse.jdt.compiler.tool.tests/META-INF/MANIFEST.MF
index 935a43ecfd..c5f3056e24 100644
--- a/org.eclipse.jdt.compiler.tool.tests/META-INF/MANIFEST.MF
+++ b/org.eclipse.jdt.compiler.tool.tests/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.jdt.compiler.tool.tests
-Bundle-Version: 1.4.600.qualifier
+Bundle-Version: 1.4.700.qualifier
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
 Bundle-RequiredExecutionEnvironment: JavaSE-17
diff --git a/org.eclipse.jdt.compiler.tool.tests/pom.xml b/org.eclipse.jdt.compiler.tool.tests/pom.xml
index 9f094788a4..06a6878a01 100644
--- a/org.eclipse.jdt.compiler.tool.tests/pom.xml
+++ b/org.eclipse.jdt.compiler.tool.tests/pom.xml
@@ -19,7 +19,7 @@
     <relativePath>../tests-pom/</relativePath>
   </parent>
   <artifactId>org.eclipse.jdt.compiler.tool.tests</artifactId>
-  <version>1.4.600-SNAPSHOT</version>
+  <version>1.4.700-SNAPSHOT</version>
   <packaging>eclipse-test-plugin</packaging>
   <properties>
   	<testSuite>${project.artifactId}</testSuite>
-- 
2.47.1

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

[stephan-herrmann]

@jarthana I was wondering if version bumps like in this MR could contribute to the build failures in BETA_JAVA24 (until those changes are merged into the branch).

Which lets me ask if such interference could possibly be avoided by smart use of different increments? I recall precise rules when to use +100, +50 or even just +1 in the service segment, but I can't remember where I should look for such rules. Since BETA_JAVA24 will be released after the current master stream, would it make sense to ensure that all versions in the beta branch are and remain greater than those in master?

[jarthana]

@jarthana I was wondering if version bumps like in this MR could contribute to the build failures in BETA_JAVA24 (until those changes are merged into the branch).

Which lets me ask if such interference could possibly be avoided by smart use of different increments? I recall precise rules when to use +100, +50 or even just +1 in the service segment, but I can't remember where I should look for such rules. Since BETA_JAVA24 will be released after the current master stream, would it make sense to ensure that all versions in the beta branch are and remain greater than those in master?

You know, before I fixed the version wondering about the same. I first added 50 and then thought it would be better if we kept n(100) on master and so we can have n(100) + 50 on the BETA branch if it changes. But I don't understand why you said all versions should be greater than master? We have always only done that for the bundles that changed.

Edit: And you are right about the build failures. It's been a pain usually. This time I will merge more frequently as we discuss the merits of bumping up versions on all bundles in the BETA branch.

[stephan-herrmann]

But I don't understand why you said all versions should be greater than master? We have always only done that for the bundles that changed.

My idea was, if bundles in beta have +100 then master can remain at +0 or increment +50 at any time without impacting beta builds. And since beta spans two regular release cycles, master could even do another +10 to still remain below beta. Perhaps this strategy makes most sense to test bundles, which hardly ever increase the minor segment, and micro-bumps are spread more over the release cycle. Also most test bundles have no clients to which these version bumps would ripple etc., i.e. a preemptive bump for test bundles shouldn't harm, should it?

Anyway, if more frequent merges - at least after each version change in master - is not too much of a burden then this is fine. I was just trying to minimize the need for this.