Use more general Map interface for setOptions()

[jukzi]

and log any error

[jukzi]

00:05:24.187  org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-apitools-plugin:4.0.11-SNAPSHOT:verify (verify) on project org.eclipse.jdt.core: There are API errors:
00:05:24.187  model/org/eclipse/jdt/core/JavaCore.java:172 The method org.eclipse.jdt.core.JavaCore.setOptions(Hashtable<String,String>) has been removed
00:05:24.187  model/org/eclipse/jdt/core/JavaCore.java:6419 Missing @since tag on setOptions(Map<String,String>)
00:05:24.187  META-INF/MANIFEST.MF:5 The major version should be incremented in version 3.41.0, since API breakage occurred since version 3.40.0

[jukzi]

@carstenartur is this what you want?

[carstenartur]

@carstenartur is this what you want?

Basically, yes - something like this.

The code itself still is creating copies of maps in some situations that popped up as performance hotspot back when I investigated using the sap hana tools on Eclipse years ago.

I barely remember any details and don't have the time to investigate again right now. And imho you are a better java and Eclipse developer than me anyway ;)

What might be helpful is to put the recipe to reproduce an issue with multithreading and options into a junit test:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=360711#c37

[jukzi]

There are callers like org.eclipse.jdt.core.ICompilationUnit.getOptions(boolean) which would try to modify the returned map, so one has to be careful in refactoring to use a unmodifiable map.

[jukzi]

For example the BasApiAnalyzer during full build of platform workspace spends ~3s in getOptions()

[jukzi]

I don't know any action/test where setOptions/getOptions is a crucial hotspot. But for example when building our product it takes totally ~3 sec, which may be worth some improvement. There the crucial caller is org.eclipse.jdt.core.dom.ASTParser.setSource(ICompilationUnit) -> org.eclipse.jdt.core.ICompilationUnit.getOptions(boolean)