Community
Participate
Working Groups
== Simplified steps: == 1. Create some executable Java code: e.g. paste the string "return;" into the package explorer view 2. Place a breakpoint in the code and debug it. 3. In the 'Display' view, enter the text "(char) -1" and press Ctrl+Shift+D to evaluate and display the result of the expression == Observed == a) Errors start appearing periodically that the automatic workbench save is failing, and again on close. b) The workbench file is zero-length: ...\.metadata\.plugins\org.eclipse.e4.workbench\workbench.xmi c) The layout is lost & reverts to default I'd like to comment that I've encountered various problems with the workspace layout being lost and corrupted over the years, so this is another chapter in the ongoing saga. I consider this a serious "loss of user data" type of bug. == Requests == A. Could you please save the workspace layout data to a temporary file & rename it into place only if everything succeeds? That would then be robust against a whole class of such problems. (I'm happy for the errors to still be displayed visibly, but just not to lose my hand-crafted layouts.) B. Plug holes in escaping of characters which can be printed to the Display when debugging == Diagnostics == The following can be found in the log: !ENTRY org.eclipse.osgi 4 0 2016-07-31 12:40:50.540 !MESSAGE Application error !STACK 1 java.lang.RuntimeException: An invalid XML character (Unicode: 0xffff) was found in the element content:<?xml version="1.0" encoding="UTF-8"?> <view>(char) 65535
	 (char) </view> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl$Escape.convert(XMLSaveImpl.java:3417) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.getDatatypeValue(XMLSaveImpl.java:3113) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveDataTypeSingle(XMLSaveImpl.java:1698) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1280) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1224) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2716) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1181) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1042) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2417) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1553) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1224) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2716) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1181) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1042) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2417) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1553) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1224) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2716) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1181) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement(XMLSaveImpl.java:1042) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany(XMLSaveImpl.java:2417) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1553) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures(XMLSaveImpl.java:1224) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID(XMLSaveImpl.java:2716) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.writeTopObject(XMLSaveImpl.java:683) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse(XMLSaveImpl.java:591) at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save(XMLSaveImpl.java:251) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave(XMLResourceImpl.java:389) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:1430) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:999) at org.eclipse.e4.ui.internal.workbench.ResourceHandler.save(ResourceHandler.java:218) at org.eclipse.e4.ui.internal.workbench.swt.E4Application.saveModel(E4Application.java:187) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:693) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:604) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610) at org.eclipse.equinox.launcher.Main.run(Main.java:1519) !SESSION 2016-07-31 12:47:12.298 ----------------------------------------------- eclipse.buildId=4.6.0.I20160606-1100 java.version=1.8.0_92 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_NZ Command-line arguments: -os win32 -ws win32 -arch x86_64
On re-read I sound very negative there, sorry! Just trying to be brief but accurate. On the whole I'm very happy with all the effort that's gone into e4 & the improvements its brought. :-)
Sounds like something JDT should catch. Moving to them for investigation.
I could not reproduce it. Lars, you were able to reproduce it ? Luke, Are you able to reproduce it on a new Workspace with Eclipse SDK ?
Yes I reproduced it in a clean workspace, getting an error message when shutting down. I'm using "Eclipse SDK" Neon as my base, with various other plugins. Is text encoding relevant? Being on Windows, I see these preferences... [General > Workspace] Text file encoding: Default, Cp1251 [XML > XML Files] Encoding: UTF-8
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
FWIW, retested to see if it was still there. It is. Should have known by now to backup my workspace xml file again - D'oh!
:) version retested with: Eclipse SDK 2019-06
I think I understand it now. (char) -1; (char) An internal error occurred during: "Workbench Auto-Save Background Job". An invalid XML character (Unicode: 0xffff) was found in the element content:<?xml version="1.0" encoding="UTF-8"?> <view>(char) -1;
	 (char) </view>
Moving to EMF.
I'm not sure what EMF itself can be expected to do. There are some characters that simply cannot be used in XML, even in XML 1.1, which supports more control characters but does not support 0x0. Such things cannot be supported. In other places, such as in Oomph, where we must represent such arbitrary characters, e.g., in preference property values, where 0x0 is used as a separator, we are forced to define our own EDataType, e.g., EscapedString: https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/plugins/org.eclipse.oomph.preferences/model/Preferences.ecore#n65 Then we need to convert to/from the escaped representation (which is serializeable), to the "bar/raw" representation in the factory implementation: https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/plugins/org.eclipse.oomph.preferences/src/org/eclipse/oomph/preferences/impl/PreferencesFactoryImpl.java#n158 Somewhere JDT or the E4 model must do the same.
