Community
Participate
Working Groups
This is a follow up from a bug that was reported to us (STS) here: https://github.com/spring-projects/sts4/issues/434 This bug looks rather similar at first sight than https://bugs.eclipse.org/bugs/show_bug.cgi?id=558495 It even sometimes manifest with a similar 'main class not found' error message. At other times it manifest as somewhat random looking JVM crashes. Behavior will vary between runs of the exact same app with the exact same launch parameters (this is different from the previously reported/fixed bug). Also, this still happens with Eclipse 4.15. We spend quite a some time trying to get to the bottom of this. See the linked STS github issue for lengthy discussion / details. I will summarise here the conclusion. This appears to be a bug in JDK. The problem can be reproduced without using STS or Eclipse, just launching Java app from the commandline. I have sumbitted a JDK bug about this, but it is still under review and not yet publically visible (I will post a link when/if it becomes available). Although this isn't an Eclipse bug, the reason why I am raising it here anyway is that there is a simple 'workaround' that can avoid the bug from affecting people using Eclipse. The trick is simply to avoid using the '@' classpath file by checking the 'Use Temporary Jar' option in the launch config editor instead. So the purpose of this ticket is just to ask Eclipse/jdt to consider whether switching this option on by default might be a good idea. I'm not necessarily saying this is something JDT must absolutely do, but there are some good reasons to do it: - the bug is really confusing to users and cause a lot of time to be wasted. - the bug makes Eclipse look flaky (even if it isn't Eclipse's fault, but for some reason, it seems to manifest mostly when launching apps from Eclipse, whereas it usally doesn't happen when running the same app using maven or Gradle on the CLI.
Kris, thanks for reporting, I've updated title to make sure we are talking about an enhancement (to prevent a crash), not about crash itself. Is this Windows only issue, or does it also crash on Linux?
We have had no reports so far of crashes on anything but Windows. But I am not sure whether the bug affects other OS's. My impression was it's specific to Windows and my testing was on Windows specifically. I will give a try if I get these crashes on my Linux box and report back later.
I've tried on my linux box. I am fairly sure that it is not affected. It may be that the JDK bug actually does affect Linux. However on Linux when I launch my app from Eclipse, Eclipse just 'inlines' the classpath argument rather than using a '@file' style argument. I gather this use of '@file' argument is specific to Windows and kicks on to avoid specific limitations with commands string length on Windows. I've tried launching the same app that breaks on Windows about a dozen times on Linux and it launched fine each time. This is of course not a 100% guarantee there is no problem and I just got extremely lucky not to hit one of the random failures. However given that we know: - all reports of this kind of launching problem have been on Windows so far - the use of '@' argument by Eclipse is also windows specific - the use of '@' argument seems to be closely related to this bug Seems to me that we can be fairly certain this bug only affects Windows.
Changing the default behaviour might be a surprise for many. I will suggest to send a mail to cross-dev and jdt-dev mailing list so that people are aware of this bug and if there are no objections and good number of votes, we can do it.
> Changing the default behaviour might be a surprise for many. I think its more of a surprise if they launch their app / project and it crashes the JVM. People hiiting this bug will then have to spend a good ammount of time and effort to figure out that by checking the somewhat obscure 'use temporary jar' checkbox in the launch config, the problem is avoided. On the other hand, I think most people will not be surprised at all by this change for the simple fact they won't notice anything different. The app launches fine and they have no real reason to go and inspect the exact commandline string that Eclipse used to launch their project. > I will suggest to send a mail to cross-dev and jdt-dev mailing list so that people are aware of this bug and if there are no objections and good number of votes, we can do it. Fair enough.
