search

cincheo / jsweet-eclipse-plugin

The official Eclipse plugin for the JSweet transpiler
http://www.jsweet.org
Apache License 2.0
20 stars 10 forks source link

A multitude of JRE/JDK related problems #8

Closed ivmarkov closed 8 years ago

ivmarkov commented 8 years ago

There are a multitude of JDK-related problems:

1) The jsweet Eclipse plugin requires that Eclipse is being run with a JDK rather than a JRE, or else the transpilation process fails as the jsweet transpiler is looking for the JDK tools.jar and bails out when it is not on the classpath. This is unfortunate, because by default Eclipse picks up the installed JRE, not JDK (on Windows, that is). An annoying workaround is to manually modify eclipse.ini and specify as a VM the path to the JDK. E.g.:

-vm
C:\Program Files\Java\jdk1.8.0_74\bin\javaw.exe

Here, the relevant stacktrace from the Eclipse error log:

java.lang.NoClassDefFoundError: com/sun/tools/javac/main/Option
    at org.jsweet.transpiler.JSweetTranspiler.initJavac(JSweetTranspiler.java:283)
    at org.jsweet.transpiler.JSweetTranspiler.java2ts(JSweetTranspiler.java:739)
    at org.jsweet.transpiler.JSweetTranspiler.transpile(JSweetTranspiler.java:597)
    at org.jsweet.plugin.builder.JSweetBuilder.transpileFiles(JSweetBuilder.java:518)
    at org.jsweet.plugin.builder.JSweetBuilder.fullBuild(JSweetBuilder.java:543)
    at org.jsweet.plugin.builder.JSweetBuilder.build(JSweetBuilder.java:456)
    at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
    at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
    at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
    at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
    at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
    at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

2) Running with JDK1.8.0_31 and JDK1.8.0._74 generates a stacktrace in the jsweet transpiler, as it expects a different javac API. What is the correct JDK to be used? BTW: why not using the standard javax.tools API rather than relying on com.sun.* unofficial stuff?

Here, the relevant stacktrace from the Eclipse error log:

java.lang.NoSuchMethodError: com.sun.tools.javac.util.Options.put(Lcom/sun/tools/javac/main/Option;Ljava/lang/String;)V
    at org.jsweet.transpiler.JSweetTranspiler.initJavac(JSweetTranspiler.java:283)
    at org.jsweet.transpiler.JSweetTranspiler.java2ts(JSweetTranspiler.java:739)
    at org.jsweet.transpiler.JSweetTranspiler.transpile(JSweetTranspiler.java:597)
    at org.jsweet.plugin.builder.JSweetBuilder.transpileFiles(JSweetBuilder.java:518)
    at org.jsweet.plugin.builder.JSweetBuilder.fullBuild(JSweetBuilder.java:543)
    at org.jsweet.plugin.builder.JSweetBuilder.build(JSweetBuilder.java:456)
    at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
    at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
    at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
    at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
    at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
    at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

3) Prio B, but the jsweet Eclipse plugin does not work with JDK7, as it is not compiled with source level 1.7

renaudpawlak commented 8 years ago

JSweet only works with JDK because you need the Java compiler, and version 8 because you need the lambdas....

At some point the transpiler was raising a nice error when a JDK 8 was not found in the path. But obviously, this regressed -- it is hard to test such things :( So this is a bug of the transpiler I'd say (but maybe also of the plugin).

ivmarkov commented 8 years ago

OK but then again: which JDK shall I use with the jsweet plugin? JDK1.8.0_31 and JDK1.8.0._74 (latest version available) generate the displayed stacktrace...

renaudpawlak commented 8 years ago

I don't have the answer to that question yet. I personally use 1.8.0_65. But there should not be any significant differences in the Javac API. We assume that all 1.8.x should be fine with JSweet.

So the different stack traces probably just reflect an implementation difference... the problem being the stacktrace itself (maybe another bug).

I will investigate ASAP.

renaudpawlak commented 8 years ago

I must say that I am lost on this one.

I use version 1.8.0_65, I have a server using 1.8.0_60 and Travis CI uses 1.8.0_31 (same as one you mention). All these three versions work fine.

I am 99.9% sure that it is not a version problem, but something more subtle.

Maybe you have previous errors that are not shown in your report?

Questions: did you manage building with Maven? (like just building the quickstart project for instance). If yes, what was the JDK version? Do you manage to build with Maven the same JDK as the one you are launching Eclipse with?

renaudpawlak commented 8 years ago

OK. I started over with my Windows laptop. Here are my findings.

JSweet uses the JAVA_HOME system variable if it is set. So you should be careful with that variable because it is the key. Normally, when this variable points to a wrong version of the JDK, The JSweet plugin complains by erroring the project with a global error which is quite explicit: Java compiler cannot be found: make sure that JAVA_HOME points to a JDK (version>=8) and not a JRE, or sets the transpiler jdkHome option.

I just tried to point to a JDK 1.6 and got that message.

So, the point is that the first thing to do is really to revert your hack that made Eclipse point to a JDK 1.8. JSweet was never intended to work this way, and on all my Windows systems (I have 2 laptops under Windows 7 and 8.1) and all my Eclipse installations (Kepler, Luna, and Mars), JSweet worked without having to hack Eclipse. (Note that it should work anyway if you set the right JAVA_HOME, but maybe there is a side effect when hacking the eclipse.ini, so since we don't want to get confused here (it is another story), you should just revert it.)

Once it is reverted, check your JAVA_HOME system variable. If it points to an older version of the JDK, then, if you restart Eclipse and build your project with the JSweet builder enabled, then you should get the same error as me (note that I also tried with a JRE and got the same error). To be clear: this error in not in the error log, it is in the problems view and applies to the project. Now it may be that there is a bug with that error on some versions of the JDK (I have to say that I have not tried with a version 1.7). So if the error fails to appear, please tell me and we will fill a bug report. In any case, this should not prevent the plugin to work if your set your JAVA_HOME properly.

So, make sure that you set your JAVA_HOME to any JDK 1.8 version and restart Eclipse. If you build the project, it should be fine and you should see the outputed JS and nice information messages in the Error Log view (note that the first build can be quite long because various initializations are done).

I hope this will work as expected. I am curious to see what you get.

Additional info: I just filled an issue so that the plugin can work without having to rely on the JAVA_HOME variable (see issue #9). Maybe I should have done it this way from day one because relying on a system variable does not sound like a good idea after all :(

ivmarkov commented 8 years ago

I confirm that having the workaround of JAVA_HOME pointing to a JDK8 installation allows me to use jsweet from within Eclipse. Thanks!

BTW: I cannot remove the JRE8 from the eclipse.ini file though. This I need because otherwise, a JRE7 is found, and the jsweet eclipse plugin is compiled with Java 8 sourcelevel compatibility... But that's a smaller issue.