Community
Participate
Working Groups
As this code is called every time you run a quickfix and in different other situations it should be as fast as possible. Unfortunately it is creating a complete copy of the preferences using the synchronized Hashtable each time it is called in case of using the cached version. public Map<String, String> getOptions() { // return cached options if already computed Hashtable<String, String> cachedOptions; // use a local variable to avoid race condition (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=256329 ) if ((cachedOptions = this.optionsCache) != null) { return new Hashtable<>(cachedOptions); } The Hashtable.putAll() caused by this adds unnecessary to the processing time.
As you can see, the code was added to avoid a race condition. It will be nice to have a solution that addresses both the issues. Do you have a proposal?
(In reply to Jayaprakash Arthanareeswaran from comment #1) > As you can see, the code was added to avoid a race condition. It will be > nice to have a solution that addresses both the issues. Do you have a > proposal? I tried to find a specification that describes the architecture regarding the lifecycle of different components in jdt. So far I found nothing. I don't know how many concurrent different(!) copies of the options can live in the system and which objects there lifecycle is bound to. It looks like there is no way to run two quickfixes/cleanups at the same time on eclipse. So for this usage this code does not make sense, does it? But the build, as described in the referenced bugzilla is affected by this and so it looks like there are some situations where several option-Hashtables can be in the system at the same time with possible (?) different settings. At the moment I wonder in which situations it is needed and in which it is not needed to have a copy. Maybe we can have another getOptions() method "getOriginalOptions" where you can get the reference to the original datastructure without creating a copy at all? As it is synchronized already even changes were possible. So a caller could choose the right method based on the usage. Not sure about the right approach..
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
