Community
Participate
Working Groups
4.12: When launching org.eclipse.qvtd.xtext.qvtrelation.tests.QVTrDebuggerTests.testDebugger_Run_hstm2fstm_CG by selecting the test in the JUNit View for the \org.eclipse.qvtd.all.tests\.launches\All QVTd Tests (Plugin) launch, I get Thread [main] (Suspended (breakpoint at line 54 in MalformedURLException)) MalformedURLException.<init>(String) line: 54 URL.<init>(URL, String, URLStreamHandler) line: 593 URL.<init>(URL, String) line: 490 URL.<init>(String) line: 439 Main.addBaseJars(URL, ArrayList<URL>) line: 929 Main.getDevPath(URL) line: 797 Main.getBootPath(String) line: 995 Main.basicRun(String[]) line: 577 Main.run(String[]) line: 1468 Main.main(String[]) line: 1441 C:\Program Files\Java\jdk1.8.0_211\bin\javaw.exe (18 Aug 2019, 14:51:47) Investigating, it appears that in Main.addBaseJars String baseJarList = System.getProperty(PROP_CLASSPATH); returns null, but that readFrameworkExtensions(base, result); baseJarList = System.getProperty(PROP_CLASSPATH); changes baseJarList to ., file:E:/Tools/Eclipse/4.12/plugins/org.eclipse.osgi.compatibility.state_1.1.500.v20190516-1407.jar and that it is the "." that provokes the MalformedURLException
Moving to JDT UI.
(In reply to Ed Willink from comment #0) > Investigating, it appears that in Main.addBaseJars > > String baseJarList = System.getProperty(PROP_CLASSPATH); > > returns null, but that > > readFrameworkExtensions(base, result); > baseJarList = System.getProperty(PROP_CLASSPATH); > > > changes baseJarList to > > ., > file:E:/Tools/Eclipse/4.12/plugins/org.eclipse.osgi.compatibility.state_1.1.500.v20190516-1407.jar > > > and that it is the "." that provokes the MalformedURLException The referenced code is from Equinox.
Outside of a breakpoint hit on MalformedURLException, what is the observed error to the end user of Eclipse?
Probably only the fractional difference in speed for a guarded rather than caught problem. It's just really naff that Eclipse/Java seems to have an extra warmup problem for a debug user to navigate with each release.
(In reply to Ed Willink from comment #4) > Probably only the fractional difference in speed for a guarded rather than > caught problem. If you can observe a few nanoseconds in a debug session I am impressed. > > It's just really naff that Eclipse/Java seems to have an extra warmup > problem for a debug user to navigate with each release. I don't understand this comment, this code has been this way for more than 10 years. I also don't understand understand how this is a warmup problem at all because the code catches and handles the exception itself. Not sure why that has to affect a debug user. IIRC this code has a pattern of trying the value out as a URL and intentionally catches the MalformedURLException and then falls back to using the value as a relative path to the base. Moving to Launcher since this is not a framework issue.
(In reply to Thomas Watson from comment #5) > (In reply to Ed Willink from comment #4) > > Probably only the fractional difference in speed for a guarded rather than > > caught problem. > > If you can observe a few nanoseconds in a debug session I am impressed. I suspect it's actually nearly microseconds since probably there is a MalformedURLException class load. > > > > It's just really naff that Eclipse/Java seems to have an extra warmup > > problem for a debug user to navigate with each release. > > I don't understand this comment, this code has been this way for more than > 10 years. I also don't understand understand how this is a warmup problem > at all because the code catches and handles the exception itself. Not sure > why that has to affect a debug user. > > IIRC this code has a pattern of trying the value out as a URL and > intentionally catches the MalformedURLException and then falls back to using > the value as a relative path to the base. > > Moving to Launcher since this is not a framework issue. MalformedURLException, UnsupportedOperationException, NullPointerException, IllegalStateException, AssertionFailedError are ones I have learned to always debug since they invariably lie at the heart of more confusing downstream behaviour. In some cases a URL try and fail may be necessary, but "." is a guaranteed failure from an internally created definitely-not-URL. In practice the try-and-fail need only fail for genuinely bad URLs.
(In reply to Ed Willink from comment #6) > In some cases a URL try and fail may be necessary, but "." is a guaranteed > failure from an internally created definitely-not-URL. In practice the > try-and-fail need only fail for genuinely bad URLs. Sure, but the value currently supports both URL values and non-URL values, so you either need to do some check before calling new URL or just handling the non-URL values when catching the exception that we need to be prepared to catch anyway. I suppose we could do some check like indexOf(':') != -1 before calling new URL which would probably handing most all cases I can think of.
The check is already there. Currently if (string.equals(".")) { //$NON-NLS-1$ addEntry(base, result); } detects the problem path, special cases it then continues in the main flow where the known bad case causes a guaranteed exception for new URL("."). Surely URL url; if (string.equals(".")) { //$NON-NLS-1$ addEntry(base, result); url = new URL(base, string); } else if (string.startsWith(FILE_SCHEME)) url = new File(string.substring(5)).toURL(); else url = new URL(string); addEntry(url, result); avoids the gratuitous exception?
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.
Still waiting for a response to comment 8
(In reply to Ed Willink from comment #10) > Still waiting for a response to comment 8 I've lost sight of what this bug report is trying to fix. Is there some end user observable issue here?
There is a gratuitous Exception, caused by poor programming, that makes the debugging user's life harder by causing problem breakpoints to be hit when actually there was no problem at all. Comment #8 suggests a trivial rewrite.
(In reply to Ed Willink from comment #12) > There is a gratuitous Exception, caused by poor programming, Lovely > that makes the > debugging user's life harder by causing problem breakpoints to be hit when > actually there was no problem at all. > > Comment #8 suggests a trivial rewrite. Not sure how trivial it is. This code path appears to be when you have some equinox specific framework extensions present and are in dev mode. That is a rather complicated scenario. I have to admit I don't have a full memory of all the inputs PDE sets for such a scenario when you have framework extensions contributing to the classpath of the framework and the launcher has to discover all of the paths to put on the class loader for the framework. That in addition to being in devmode so now the launcher also has to look for all the dev paths from framework extensions that may be contained in the workspace. All of this is to say, I don't think we have adequate test coverage for such a complicated scenario to make sure this "trivial" change doesn't break stuff. That makes this change non-trivial.
