Community
Participate
Working Groups
Created attachment 260660 [details] Trivial application demonstrating the problem This bug started its life as Tycho Bug 490589, but I have managed to distill it down to a minimal example (attached) using a trivial org.eclipse.equinox.app.IApplication: public class Application implements IApplication { public Object start(IApplicationContext context) throws Exception { Properties original = System.getProperties(); Properties clone = (Properties) original.clone(); final Properties replacement; replacement = clone; // (1) Causes the exit code of 255 to be ignored // replacement = new Properties(original); // (2) Not ignored // replacement = new Properties(clone); // (3) Ignored System.err.println(replacement.equals(original)); System.err.println(replacement.hashCode() == original.hashCode()); System.setProperties(replacement); } public void stop() { } } For some reason, replacing the system properties with a clone of themselves (see Bug 490866 comment 9 for why one may want to do this) causes the return value of IApplication.start to be ignored; the exit code of the JVM is always 0. Just changing the identity of the system properties (case (2)) doesn't have this effect, so it's something about the cloning that causes the problem (note that Properties implements Cloneable), not about the change in object identity. BTW, the attached trivial application also implements a fourth alternative that uses Properties.load/store rather then Object.clone to create a replacement copy; this alternative also sees the exit code stuck at 0, even though this copy (like the clone) is equal to (and has the same hashCode as) the original.
New Gerrit change created: https://git.eclipse.org/r/69731
(In reply to Eclipse Genie from comment #1) > New Gerrit change created: https://git.eclipse.org/r/69731 I have a gerrit review going to resolve this issue. The issue is that the framework obtains the system properties object (from System.getProperties()) and holds onto that properties object for use later. This is done only when osgi.framework.useSystemProperties=true which is set by default when using the Equinox launcher. When using the new Properties(original); copy it "works" because that properties object will use the original properties object as defaults. So when we set property values on the original properties object that we hold in the framework it effectively sets the default value used by the copy you set. But if you clone or manually copy the values into a new Properties object that Properties object no longer delegates to the original to get the default values. To work around this in your tests I would create a copy of the system properties key->values at the start and do not replace the properties object. Then on test exit I would call System.getProperties().clear(); System.getProperties.putAll(origCopiedEntries);
Gerrit change https://git.eclipse.org/r/69731 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=996537033657df4dd4505606efdd752114a2e097
Fixed in master.
(In reply to Thomas Watson from comment #2) > (In reply to Eclipse Genie from comment #1) > > New Gerrit change created: https://git.eclipse.org/r/69731 > > I have a gerrit review going to resolve this issue. The issue is that the > framework obtains the system properties object (from System.getProperties()) > and holds onto that properties object for use later. This is done only when > osgi.framework.useSystemProperties=true which is set by default when using > the Equinox launcher. > > When using the new Properties(original); copy it "works" because that > properties object will use the original properties object as defaults. So > when we set property values on the original properties object that we hold > in the framework it effectively sets the default value used by the copy you > set. > > But if you clone or manually copy the values into a new Properties object > that Properties object no longer delegates to the original to get the > default values. Yes, that's why I had the different alternatives in my example IApplication: to test whether object identity is an issue (it is) and what object exactly the framework holds a reference to. > To work around this in your tests I would create a copy of the system > properties key->values at the start and do not replace the properties > object. Then on test exit I would call System.getProperties().clear(); > System.getProperties.putAll(origCopiedEntries); Yes, that will work (and even preserve the defaults, as clear and putAll don't touch them). I'll make that change in the meantime, while the Equinox fix trickles downstream. Thank you very much for the fix.
*** Bug 490589 has been marked as a duplicate of this bug. ***
*** Bug 319679 has been marked as a duplicate of this bug. ***
