Community
Participate
Working Groups
Created attachment 120993 [details] ISO-Latin-1 encoded java file Build ID: I20080617-2000 Steps To Reproduce: Create a file using ISO-8859-1 characters Loading it into an Eclipse using UTF-8 as it's default encoding. No warning or error is given SUN's javac gives a warning $ javac Bad.java Bad.java:2: warning: unmappable character for encoding UTF8 String foo = "�"; // A with ring on top ^ 1 warning More information:
The batch compiler doesn't report the problem either, whereas javac 6 does report the problem.
Pls investigate. I was hoping an encoding error to be surfaced.
You want to consider the batch mode or the IDE mode or both.
The API we use to get the file contents doesn't report any encoding error in this case. We could change the way we retrieve the contents, but since the compiler needs to be compliant with 1.3 API, we cannot use nio API. We could envision using the reflect API in order to know if nio are available. javac doesn't have this limitation. For the builder, we get the contents through the IFile API that doesn't report encoding errors. This would be an issue for Platform/Resources.
In fact, IFile.getContents() only returns an InputStream. So the code to diagnose encoding errors is inside the jdt.core bundle. We could fix the builder to use nio code since the builder can use 1.4 code. Only the batch compiler still has an issue.
Created attachment 124187 [details] Proposed fix Simple fix for the java builder. With this change, the java builder will abort the compilation because the source file can no longer be read. This doesn't fix the batch compiler due to the nio usage limitation.
Note that the patch now prevents the file from being read inside the java builder. This might be too strong. We might want to report only a warning. Let me know the way you prefer the error from being reported.
This bug also causes problems when initiating an Ant build from Eclipse. When the compiler encounters problem characters, in this case 0x92 and 0x93, the compiler bails but the error is not reported because the console throws an Exception. See below. The result is that the Ant build hangs until it is manually terminated. Here is the only stack trace I found for this problem. Eclipse Platform Version: 3.4.2 Build id: M20090211-1700 !ENTRY org.eclipse.ui.console 4 2 2009-03-17 17:51:27.894 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.ui.console". !STACK 0 org.eclipse.swt.SWTException: Device is disposed at org.eclipse.swt.SWT.error(SWT.java:3777) at org.eclipse.swt.SWT.error(SWT.java:3695) at org.eclipse.swt.SWT.error(SWT.java:3666) at org.eclipse.swt.widgets.Display.error(Display.java:1180) at org.eclipse.swt.widgets.Display.asyncExec(Display.java:648) at org.eclipse.ui.internal.console.ConsoleDropDownAction.consolesRemoved(ConsoleDropDownAction.java:150) at org.eclipse.ui.internal.console.ConsoleManager$ConsoleNotifier.run(ConsoleManager.java:154) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.console.ConsoleManager$ConsoleNotifier.notify(ConsoleManager.java:174) at org.eclipse.ui.internal.console.ConsoleManager.fireUpdate(ConsoleManager.java:262) at org.eclipse.ui.internal.console.ConsoleManager.removeConsoles(ConsoleManager.java:244) at org.eclipse.debug.internal.ui.views.console.ProcessConsoleManager.removeProcess(ProcessConsoleManager.java:98) at org.eclipse.debug.internal.ui.views.console.ProcessConsoleManager.removeLaunch(ProcessConsoleManager.java:81) at org.eclipse.debug.internal.ui.views.console.ProcessConsoleManager.shutdown(ProcessConsoleManager.java:198) at org.eclipse.debug.internal.ui.DebugUIPlugin.stop(DebugUIPlugin.java:388) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$3.run(BundleContextImpl.java:1050) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:1046) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:457) at org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:531) at org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1104) at org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:655) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:312) at org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:257) at org.eclipse.osgi.framework.internal.core.SystemBundle.suspend(SystemBundle.java:236) at org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:678) at org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:576) at org.eclipse.osgi.framework.internal.core.OSGi.close(OSGi.java:41) at org.eclipse.core.runtime.adaptor.EclipseStarter.shutdown(EclipseStarter.java:424) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:200) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
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.
I presume this is still relevant. We do have a patch, but looks like it won't be sufficient for the scenario reported in comment #8. It will be nice if someone can pick this up and provide a patch for both the batch compiler as well as the IDE.
