${releaseName} (${releaseNumberSDK})]]>
Eclipse JDT 4.31 Plug-in Migration FAQ
+ +-
+
- None +
Incompatibilities between Eclipse 4.30 and 4.31
+ ++ So far Eclipse did not change incompatibly between 4.30 and 4.31 in ways that affect + plug-ins. Plug-ins that ran on 4.30 should run on 4.31 without any problems. +
+ + + \ No newline at end of file diff --git a/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.31/recommended.html b/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.31/recommended.html new file mode 100644 index 00000000000..7d49edd6bbd --- /dev/null +++ b/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting/4.31/recommended.html @@ -0,0 +1,23 @@ + + + + + + + +Adopting JDT 4.31 mechanisms and APIs
++ This section describes changes that are required if you are trying to change + your 4.30 plug-in to adopt the 4.31 mechanisms and APIs. +
+ +-
+
- None +
Eclipse JDT 4.31 Plug-in Migration Guide
+This guide covers migrating Eclipse JDT 4.30 plug-ins to Eclipse JDT 4.31.
+One of the goals of Eclipse 4.31 was to move Eclipse forward while remaining compatible + with previous versions to the greatest extent possible. That is, plug-ins written + against the Eclipse 4.30 APIs should continue to work in 4.31 in spite of the + API changes.
+The key kinds of compatibility are API contract compatibility and binary compatibility. + API contract compatibility means that valid use of 4.30 APIs remains valid for + 4.31, so there is no need to revisit working code. Binary compatibility means + that the API method signatures, etc. did not change in ways that would cause + existing compiled ("binary") code to no longer link and run with the + new 4.31 libraries.
+While every effort was made to avoid breakage, there are a few areas of incompatibility or new + APIs that should be adopted by clients. + This document describes those areas and provides instructions for migrating 4.30 plug-ins to + 4.31.
+-
+
- Eclipse JDT 4.31 Plug-in Migration FAQ +
- Incompatibilities between Eclipse JDT 4.30 and 4.31 +
- Adopting 4.31 mechanisms and API +
What's New in Eclipse 4.30 (JDT)
+Java Development Tools
Here are descriptions of some of the more interesting or significant changes made to the Java development tools (JDT) -for the 4.30 release of Eclipse. +for the 4.31 release of Eclipse. They are grouped into:
-
-
- New Java™ Language Features - +
- Java Editor +
- Java Compiler - +
- Java Formatter -
- JDT Developers +
See also the Eclipse Platform What's New @@ -49,32 +49,24 @@
What's New in Eclipse 4.30 (JDT)
- + + -
- The release notably includes the following Java features:
-
- JEP 440: Record Patterns.
-
- JEP 441: Pattern Matching for Switch.
-
JUnit
Java Editor
-default case to an enhanced switch statement. For example,
- 
default case when it is present with unconditional pattern in a switch. For example,
- 
break statement when there is an illegal fall-through to a pattern in a switch statement.
- For example,
- 
-
-
- The deprecated method has Javadoc that specifies a @deprecated tag which ends with "use {@link ...}" or "replace by {@link ...}" -
- The {@link ...} tag refers to a method -
- The linked method is actually called in the implementation of the deprecated method -
- Methods and fields accessed in the linked method are visible at the location it will be inlined (e.g. using a package private method is ok to call if in same package) -
The functionality is also available as a quick fix for an individual call to a deprecated method that is marked with warning or error. One can also select a deprecated method call and initiate as a quick assist (select call and click CTRL + 1).
-
A new refactoring called 'Make Static' has been added to Eclipse's Java Development Tools (JDT), which converts instance methods into static methods, when possible. This refactoring adds an extra parameter to the method declarations to handle references to instance fields, methods, or classes in the original method. Existing calls to the method are altered accordingly, and if the extra parameter is necessary, the refactoring passes 'this' or the specific instance originally used to access the method.
+To apply this refactoring, the following conditions must be met:
+-
+
- The method is not a constructor. +
- The method does not override a method from the parent type nor is overridden in any child types. +
- The type in which the method is declared is not a local type, an anonymous type, or an annotation. +
The refactoring can be executed by selecting a method invocation, except in cases where a super method invocation is selected.
+
AutoCloseable) are not properly closed
+ has been enhanced.
+ + Previously, flow analysis for resource leaks was focused on resources that are created and closed within the same method. + It could not deal well with resources that are shared between different methods, + perhaps even different objects. +
+
+ The compiler now interprets an annotation @Owning to understand data flows of resources by way of the
+ following concepts:
+
-
+
- A source of resources
- Here a resource will come into the focus of the current method, + along with a responsibility to close it. +
- A sink for resources
- Here a resource will be consumed, either by closing, or by delegation + to other code which then will be responsible +
Resource allocation is the primordial source, and a call to AutoCloseable.close() is the final sink.
+ When allocation and closing do not happen within the same method, then annotation @Owning should be used to create
+ connections through which responsibility for a resource can be transferred from one method to another.
+ The inverse annotation @NotOwning, on the other hand, signals that no such connection is made;
+ the original holder of the resource is still responsible for sending it to a suitable sink.
+
+ 
+
+ It's in method produce() where a new resource is allocated.
+ The return statement in that method is governed by the @Owning annotation on the method.
+ This implies that returning this value is a sink from the point of view of produce().
+ By this method produce() is considered safe.
+ But looking from the outside this sink is in fact the source by which the resource arrives in method test().
+
+ After method test() receives the resource, the responsibility to close is fulfilled by passing it down into consume().
+ In method consume() it's the annotation on parameter in that creates the connection:
+ test() has done its part and now consume() is responsible.
+ Protecting the resource with a try-with-resources statement is the preferred way to fulfill the responsibility, its implicit close() call is the ultimate sink.
+ Thus the given combination of method calls indeed creates a provably safe data flow from initial source to final sink,
+ because both calls are governed by @Owning.
+
+ The body of produce() also shows another detail:
+ just like test() it passes the resource as a parameter to another method, here: skipHeader().
+ The parameter of skipHeader(), however, is annotated as @NotOwning
+ by which the method rejects any responsibility.
+ Indeed there's no close call to be found here, but that's OK under the @NotOwning annotation - this parameter is not a source.
+ As a result, still after the call to skipHeader() it is produce() who is responsible.
+ For that reason saying return in; is indeed necessary for produce() to demonstrate obedience to the contract.
+
+ Additional rules exist for fields holding a resource and for methods other than close() that perform mandatory clean-up.
+ Details on those can be found in the documentation of org.eclipse.jdt.annotation.Owning.
+
+ To enable this feature select Java Compiler > Errors/Warnings > Enable annotation based resource analysis in the project preferences:
+
+ 
+
Indentation > Align items in columns > Arrows in switch statements/expressions.
+ 
${releaseName} (${releaseNumberSDK})]]>
Eclipse 4.31 Plug-in Migration FAQ
+ + \ No newline at end of file diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/4.31/incompatibilities.html b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/4.31/incompatibilities.html new file mode 100644 index 00000000000..05da5168293 --- /dev/null +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/4.31/incompatibilities.html @@ -0,0 +1,24 @@ + + + + + + + +Incompatibilities between Eclipse 4.30 and 4.31
+ ++ Eclipse changed in incompatible ways between 4.30 and 4.31 in ways that affect + plug-ins. The following entries describe the areas that changed and provide + instructions for migrating 4.30 plug-ins to 4.31. Note that you only need to look + here if you are experiencing problems running your 4.30 plug-in on 4.31. +
++See also the list of deprecated API removals for this release. +
+ + + \ No newline at end of file diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/4.31/recommended.html b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/4.31/recommended.html new file mode 100644 index 00000000000..bcf4b0c0543 --- /dev/null +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/4.31/recommended.html @@ -0,0 +1,25 @@ + + + + + + + + +Adopting 4.31 mechanisms and APIs
+ +This section describes changes that are required if you are + trying to change your 4.30 plug-in to adopt the 4.31 mechanisms and + APIs.
+ + + + + + \ No newline at end of file diff --git a/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/eclipse_4_31_porting_guide.html b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/eclipse_4_31_porting_guide.html new file mode 100644 index 00000000000..089e8dcc087 --- /dev/null +++ b/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv/porting/eclipse_4_31_porting_guide.html @@ -0,0 +1,35 @@ + + + + + + + +Eclipse 4.31 Plug-in Migration Guide
+This guide covers migrating Eclipse 4.30 plug-ins to Eclipse 4.31.
+One of the goals of Eclipse 4.31 was to move Eclipse forward while remaining compatible + with previous versions to the greatest extent possible. That is, plug-ins written + against the Eclipse 4.30 APIs should continue to work in 4.31 in spite of any API changes.
+The key kinds of compatibility are API contract compatibility and binary compatibility. + API contract compatibility means that valid use of 4.30 APIs remains valid for + 4.31, so there is no need to revisit working code. Binary compatibility means + that the API method signatures, etc. did not change in ways that would cause + existing compiled ("binary") code to no longer link and run with the + new 4.31 libraries.
+While every effort was made to avoid breakage, there are a few areas of incompatibility or new + APIs that should be adopted by clients. + This document describes those areas and provides instructions for migrating 4.30 plug-ins to + 4.31.
+-
+
- Eclipse 4.31 Plug-in Migration FAQ +
- Incompatibilities between Eclipse 4.30 and 4.31 +
- Adopting 4.31 mechanisms and API +
3. org.eclipse.core.launcher#Main and WebStartMain and
API removals after June 2021
-1. Delete deprecated contents of org.eclipse.ui.commands package
-
-The following deprecated contents of org.eclipse.ui.commands are not used anymore by the platform and will be deleted.
-
- - AbstractHandler
- - ActionHandler
- - CategoryEvent
- - CommandEvent
- - CommandException
- - CommandManagerEvent
- - ExecutionException
- - HandlerEvent
- - HandlerSubmission
- - ICategory
- - ICategoryListener
- - ICommand
- - ICommandListener
- - ICommandManager
- - ICommandManagerListener
- - IHandler
- - IHandlerListener
- - IKeyConfiguration
- - IKeyConfigurationListener
- - IKeySequenceBinding
- - IWorkbenchCommandSupport
- - KeyConfigurationEvent
- - NotDefinedException
- - NotHandledException
- - Priority
- - org.eclipse.ui.IWorkbench.getCommandSupport()
-
-
-
-For further details or to provide feedback on this change, see bug 431177. -
- -API removals after May 2022
@@ -251,9 +214,6 @@4. Remove IModelProviderEvent's fields TARGET_CHANG
For further details or to provide feedback on this change, see bug 570549.
-Removed API in previous releases
-
-
API removals after December 2025
@@ -272,6 +232,29 @@ 1. Support for javax-annotation by the E4 InjectorEclipse 4.30 - New and Noteworthy: Support for Jakarta Annotations by Eclipse E4.
+
+
+API removals after March 2026
+
+1. Bundle org.eclipse.osgi.services
+
+The bundle org.eclipse.osgi.services is deprecated for removal.
+Its content has already been replaced by the official OSGi bundles published to Maven-Central and it only reexports these org.osgi.service.* bundles.
+
API removals after March 2026
+ +1. Bundle org.eclipse.osgi.services
+ +The bundleorg.eclipse.osgi.services is deprecated for removal.
+Its content has already been replaced by the official OSGi bundles published to Maven-Central and it only reexports these org.osgi.service.* bundles.
+
+Consumers are encouraged to replace their requirements on the bundle org.eclipse.osgi.services by imports of the used org.osgi.service.* packages already now.
+This allows the OSGi runtime to choose any suitable provider of the package that is available.
+
2. PluginVersionIdentifier
+ +The classorg.eclipse.core.runtime.PluginVersionIdentifier is deprecated for removal.
+As replacement org.osgi.framework.Version should be used.
+
+
+
+Removed API in previous releases
+ +@@ -607,5 +590,46 @@
2. Remove MultiPageEditor and related API
For further details or to provide feedback on this change, see Issue 1155.
+ + +API removals in the Eclipse 4.31 release
+1. Delete deprecated contents of org.eclipse.ui.commands package
+ +The following deprecated contents of org.eclipse.ui.commands are not used anymore by the platform and will be deleted. + +- AbstractHandler +
- ActionHandler +
- CategoryEvent +
- CommandEvent + +
- CommandException +
- CommandManagerEvent +
- ExecutionException +
- HandlerEvent +
- HandlerSubmission +
- ICategory +
- ICategoryListener +
- ICommand +
- ICommandListener +
- ICommandManager +
- ICommandManagerListener +
- IHandler +
- IHandlerListener +
- IKeyConfiguration +
- IKeyConfigurationListener +
- IKeySequenceBinding +
- IWorkbenchCommandSupport +
- KeyConfigurationEvent +
- NotDefinedException +
- NotHandledException +
- Priority +
- org.eclipse.ui.IWorkbench.getCommandSupport() +
+For further details or to provide feedback on this change, see bug 431177. +
+ +