Community
Participate
Working Groups
Hi, Sun's javac (and that of other JVM providers) supports a few options that the Eclipse compiler does not: -O, -X, -J, -extdirs, and -sourcepath. Would it be feasible to add these to the Eclipse compiler? We (Fedora (and potentially other Linux distributions)) use the Eclipse compiler as our java compiler (ie. /usr/bin/javac is a script which basically just called the Eclipse compiler) but currently have to use a wrapper script to strip out the aforementioned options. It would be nice if we could call ecj directly. Any chance of those options being added? Other thoughts/comments? Thanks, Andrew
-O is implicit in our compiler. -X -J are not documented well. -extdirs and -sourcepath would make more sense. We also have other options they don't have... and which you likely do not consider. Why isn't a different front-end a good idea ?
Adding fitzsim to CC.
Hi, (In reply to comment #1) > -O is implicit in our compiler. Ah, OK. In that case, it would be convenient for us if the Eclipse compiler accepted but ignored the -O option. Currently we strip out that option in our wrapper front-end. > -X -J are not documented well. > -X could be accepted and ignored. -J however is designed to pass options to the VM through the invocation API, so technically it should be stripped out by the wrapper front-end and not the Eclipse compiler itself. For the "javac" binary, I envision using the JNI invocation API to create a small C wrapper that creates a JVM according to the -J options, then runs ecj within that JVM. The "ecj" binary though, could either accept and ignore, or reject -J options. I'd like it to be more permissive and accept and ignore -J, but that's a judgement call. > -extdirs and -sourcepath would make more sense. > > We also have other options they don't have... and which you likely do not > consider. Why isn't a different front-end a good idea ? I don't mind if people use the Eclipse compiler's extra options. The idea is to make ecj's command line syntax more permissive than javac's. We've tried using wrappers but they're just another layer where things can go wrong. Thanks, Tom
Makes sense. Will tentatively try to implement this for M7. BTW, is this ejc or ecj ? I keep seeing the 2 names. Also, what performance numbers do you get with the executable in the end ?
We call it "ecj". Here's a performance comparison of native ecj vs. jikes: https://www.redhat.com/archives/fedora-devel-java-list/2005-March/msg00154.html These measurements were performed on the wrapper javac front-end in Fedora. But we also plan to provide a standalone "ecj" binary. It should be faster to start up than the javac wrapper because it will be linked directly to libgcj. This eliminates the extra steps of loading jdtcore.jar, then mapping the ecj Main class to its native compilation in jdtcore.jar.so.
So to summarize, I should add: -O : this would be ignored. -Xxxxx : this would be ignored. -Jxxxx : this would be ingored by the Eclipse compiler. It would actually be used by the wrapper to start the VM with the right arguments. -extdirs and -sourcepath this would be handled as describe below: -sourcepath sourcepath Specify the source code path to search for class or interface definitions. As with the user class path, source path entries are separated by semicolons (;) and can be directories, JAR archives, or ZIP archives. If packages are used, the local path name within the directory or archive must reflect the package name. Note that classes found through the classpath are subject to automatic recompilation if their sources are found. -extdirs directories Cross-compile against the specified extension directories. Directories is a semicolon-separated list of directories. Each JAR archive in the specified directories is searched for class files. I have concerns with the -X options. I found this description: -X Display information about non-standard options and exit. -Xstdout filename Send compiler messages to the named file. By default, compiler messages go to System.err. -Xswitchcheck Checks switch blocks for fall-through cases and provides a warning message for any that are found. Fall-through cases are cases in a switch block, other than the last case in the block, whose code does not include a break statement, allowing code execution to "fall through" from that case to the next case. For example, the code following the case 1 label in this switch block does not contain a break statement: switch (x) { case 1: System.out.println("1"); // No break; statement here. case 2: System.out.println("2"); } If the -Xswitchcheck flag were used when compiling this code, the compiler would emit a warning about "possible fall-through into case," along with the line number of the case in question. -Xstdout is the equivalent of -log .... for us. But we don't have an equivalent of -Xswitchcheck. Philippe, should we add a warning for -Xswitchcheck?
I think I would tolerate, and ignore any command line argument starting with "-X". If we did add support down the road for this particular diagnosis, then we could but it would not be mandated. I think all this request is about is to not complain on a selected set of additions to the command line. Only interesting cases are classpath related items. Again, if changes are too troublesome for M7, we should defer post 3.1, since there are obvious workarounds for client doing some wrappering anyway. Also you need to check with J9C people to see if these extra command line arguments could cause grief to them. Last, what about the Ant javac adapter ? Is this an ok change for it ?
Reduced severity. Olivier, this is time permitting to ease users of batch compiler (could be deferred to later stage or release).
Created attachment 21290 [details] implement -extdirs Hi, This patch implements the -extdirs option. Comments? Tom
Created attachment 21476 [details] implement -extdirs and -sourcepath, ignore -X, -J and -O Here is a new patch. It implements -sourcepath and -extdirs, recognizes but ignores options starting with -X and -J, and recognizes but ignores the -O option.
Maxime, I move it to you since you are adding the support for access restriction for the batch compiler. You might have conflicting changes with this patch.
Fixed and released in HEAD. Regression tests added in org.eclipse.jdt.core.tests.compiler.regression.BatchCompilerTest.
Maxime, please verify latest changes around the access restrictions.
Verified for 3.1 RC1 with build I20050527-0010.
