Eclipse build succeeding but command line giving 'code too large' error - java

I'm facing a very silly problem.
If I build my project using the Eclipse UI, it builds and runs fine. However, if I build it on the command-line using the plain old javac (i.e., without any ant or maven build tool), I get a code too large error on one of the files (which, btw, happens to be a Antlr3-generated Java parser file).
What's strange is:
My Eclipse project is pointing to the same JDK that I'm using on the command-line! So, it is not the case that I'm inadvertently using built-in Eclipse Java compiler
If the parser code were really 'too large' (some method in it being > 64K), why isn't the Eclipse build resulting in the same error? For this very reason, I'm also reluctant to start tweaking my parser grammar - a much more involved task.
I'm using Eclipse Neon and Oracle JDK 1.8.

The Eclipse UI always uses the Eclipse Java compiler, it never uses javac. So it may be the Eclipse compiler is doing a better job in this case.
The installed JRE is used for the libraries and the JVM when you are testing. Eclipse always uses its own compiler since it needs to do incremental compilation which javac can't do.

Related

How its possible for eclipse to compile and run programs on JRE without JDK [duplicate]

I need to batch a compilation with a special JRE which has been "customized".
Eclipse is able to compile the classes with this JRE, but I need to make a build script outside of Eclipse.
What is the method used by Eclipse to generate the .class files without a JDK?
Eclipse comes with its own compiler for the following reasons:
Incremental compilation (can compile just the changed parts of the project which can mean more than the amount of files you just saved, for example, when you changed some global)
The Eclipse compiler can create a class file even when the code contains errors. This allows to run the project even though not everything compiles.
The compiler provides Eclipse with an AST so it can do all kinds of fancy stuff (like the outline, show you all the places where the variable under the cursor is used, etc) at no extra cost (i.e. it doesn't have to run the compiler and another parser).
I believe Eclipse comes with internal compilers, and you can choose the compatibility to Java 1.3 through 1.6 (check the Preferences menu, under Java->Compiler). So Eclipse doesn't need an external JDK to compile, because it comes with it is self-sufficient.
If you want to create a build script outside of Eclipse, you're gonna need an external compiler, like the one that comes with the real JDK.
For the case one is interested: Eclipse's compiler is part of JDT core.
Eclipse was originally created by IBM. Eclipse has its own built-in Java compiler which is based on IBM's Java compiler, Jikes.

How to recreate Eclipse's ignoring of binary incompatibilities in an Ant javac invocation?

Eclipse provides a Java build-time option to ignore problems with incompatible required binaries at compile-time (see screenshot below; Ignore is the default actually):
I had needed this because I'm compiling a library on Eclipse Indigo (which I believe internally uses a 1.7 compiler) with a 1.6 target, but which is dependent on a library with a 1.8 target. (Everything will still be run on a 1.8 JVM where that dependent library is used, so I want the compilation to work.)
However, when I came to translate this to an Ant javac task in a build script, I've no idea how to specify this option (or, indeed, whether it boils down to a single compiler option). Having a look at the Java 6 javac 'man page' doesn't suggest anything obvious. (I appreciate that I am here using a 1.6 compiler — I'm on Ubuntu 12.04 which still has Java 1.6 — instead of Eclipse's internal 1.7 one, but that shouldn't affect the question.)
So:
(i) What does this boil down to in terms of javac options (or, equivalently, how is Eclipse achieving this?)?
(ii) How, if at all, is this translateable to an Ant javac task invocation?
To see the command that Eclipse is running when you click "Run":
Go to the Debug window, which is generally within the Debug perspective
Expand your application and right click on Java executable underneath (image below in case that's badly explained)
Click Properties and see the Command Line box
It could be that Eclipse is explicitly excluding the incompatible library? Hopefully it shows up in the command line box here.

Eclipse Luna not keeping code generated by Annotation Processing

I am running Eclipse Luna (4.4.1) under Ubuntu 14.10 (Utopic Unicorn) and have a project that uses annotation processing to validate certain forms in the code and generate utility code. In eclipse the code is not being generated.
First, the processors work perfectly with javac. Second the processors DO run in Eclipse. If I alter them to throw exceptions Eclipse reports that. Also if I provide the processors with malformed code (such as a getter/setter pair with different types) it reports the error properly (red squiggles, proper error message, whole nine yards).
No code appears in .apt_generated nor are class files generated.
I've tried disabling them and re-enabling them, starting a new project, tried it on a fresh install of Eclipse, changing the project version from 1.7 to 1.8 and back again, tried batch mode and not batch mode, changing the .apt_generated directory, double checked the permissions on .apt_generated, probably a few other things that I can't recall.
At this point I'm just running javac separately and thinking about making this our first Apache Ant or Maven project if that would help but I'd rather not quite at this juncture.
Anyone have any luck with code generation within Eclipse? Anything else to do or check?
Verify your project is set to actually use APT, as shown in https://www.eclipse.org/jdt/apt/introToAPT.php. Be aware those are project settings, not workspace preferences.
Make sure your potentially generated code is not deleted by some other part of your workflow. E.g. a second processor cleaning the directory that a first processor generated into.
Check that you are using a JDT and not a JRE both for running Eclipse as well as building your project.
Verify that org.eclipse.jdt.apt.core is part of your Eclipse installation, as that is the actual annotation processor integration for the JDT.
Verify your processor has a correctly filled file META-INF/services/javax.annotation.processing.Processor, pointing to the right class implementing the processor. Eclipse may ignore it otherwise.
That being said, I have used different annotation processors (like butterknife for Android) in Eclipse over the years and didn't run into such problems.
I had a similar problem with the AutoValue annotations not being processed with Eclipse 2019-3 with OpenJDK 11 as target runtime. In the Eclipse "Error Log" panel I saw this error:
java.lang.Exception: java.lang.UnsupportedClassVersionError:
javax/lang/model/element/ModuleElement has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0
Eclipse was running on an old Java 8 installation as indicated by Help -> About Eclipse IDE -> Installation Details -> Configuration. In my case, Eclipse found the JRE to run on on the PATH environment variable, see here. I forced Eclipse to use the OpenJDK 11 installation by adding the -vm argument to the Eclipse.ini:
-vm
"C:\path\to\OpenJDK\bin\server\jvm.dll"

Jenkins / Buildr running the eclipse compiler for 'javac' without changing system java

I'm instrumenting my java builds through jenkins, and the warnings plug-in has an option for scanning classes with the eclipse compiler, but I can't make it produce anything.
I looked through the buildr code and it looks like it uses a literal 'javac' when compiling, so I'm not sure how I could optionally switch out the compiler just for my test build (we have many other environments running java builds that I don't want to interfere with).
The standard javac is generating warnings, but I would like to be able to take an easy second pass with buildr and get those warnings as well.
Any idea how to make this work?
Jenkins is just automating your build. The Warnings plug-in just parses your build output, which contains compiler output, and generates the warning reports. The plugin cannot in itself switch compiler, that's the job of your build tool. It can only be made aware of the particular compiler you are using.
So to use the eclipse compiler on your project, you have to first configure your build tool (ant, maven, buildr, or whatever you are using) to use the eclipse compiler. Get this to work on your project outside of jenkins. Then you can tell the Warnings plug in to parse the build output.
I believe I contributed the Eclipse compiler to buildr.
IIRC (sorry, been long), you can call it with:
compile.using :ecj

Java compilation problem, Linux, project from Eclipse re-compile on Linux

I am trying to recompile an existing Java project exported from Eclipse. It is necessary to recompile this because I am running simulations remotely on other machines where a different (older) version of Java is installed. I have tried recompiling my .java file which specifies the simulation in question. However, it appears that it is necessary to recompile all other classes etc as well. Has anyone got an idea how to do this WITHOUT using Eclipse (I am not the Admin on the other machines and thus Eclipse is unavailable to me) and not manually because the project is quite huge?
Thanks a lot for any suggestions!
I recommend you to always have an command line way to build an application. The usual way to do this in Java is using ANT (or Maven).
As #Santiago Lezica says, Eclipse can generate an Ant file.
I believe that Eclipse allows you to build for an older target platform than the one you are currently running. That way you can do all of your builds locally.
The second approach has the advantage that you can fix any problems arising from compiling for the older platforms (e.g. use of new language features, use of new classes / methods) from the comfort of your own ... workstation.
There is another option that you should consider: Tell Eclipse to generate code for the old Java version (see the compiler options). That way, you can create code that runs on Java 1.3, even if Eclipse uses Java 5.
Not sure what your requirements are, but you could set the compiler level for your projects at the (older) level of your Linux installs. This would cause Eclipse to recompile it at that version, instead of a newer version.
At my company we use IBM's Rational Application Developer (instead of pure Eclipse), but I am assuming the option is in the same spot. If you right-click on your project, you can go to the Java Compiler options and then set the compatibility to the level of that on Linux (1.3, 1.4, etc.).
Since compile Java byte-code is supposed to be portable (for the most part), this should get you past most of your problems.
Otherwise, the other option is to use something like Ant or Maven scripts (which can be kicked off by Eclipse) and then just use a property to set the compiler right before you run it. This way you don't have to switch properties on your projects all the time, if you truly do need "newer" compiled code and can't live with "older" code on both systems.

Categories