Extract ECJ compiler code from jdt.core to ecj bundle and make ecj a real plug-in

[iloveeclipse]

Follow up on eclipse-platform/eclipse.platform.ua#18 (comment).

Currently JDT has LOT of hacks around compiler part (dedicated source folders, dedicated build files, dedicated deployment steps, dedicated validation bundle) - all because the standalone Eclipse Compiler for Java (ECJ) code is located inside the jdt.core project that contains additionally all the IDE specific extensions.

Ideally ECJ could be just extracted from the jdt.core bundle so it can be used by jdt.core and other bundles as a regular bundle.

This would remove most of the custom hacks around building, testing and shipping ecj we have today.

I will provide a draft idea, but I have no enough time/knowledge to perform all the build/maven magic required to get that working.
Technically I believe this should work without breaking existing jdt.core clients.

[iloveeclipse]

@stephan-herrmann , @jarthana : WDYT about #182 ?

Do you have any idea why org.eclipse.jdt.compiler.apt and org.eclipse.jdt.compiler.tool are fragments of jdt.core? Just a hack to get the standalone part compiled separately?

Would there be any issue if we just merge all three code bases together (ecj + org.eclipse.jdt.compiler.apt + org.eclipse.jdt.compiler.tool) in one real bundle? At the end that is what ecj.jar does?

[stephan-herrmann]

Do you have any idea why org.eclipse.jdt.compiler.apt and org.eclipse.jdt.compiler.tool are fragments of jdt.core? Just a hack to get the standalone part compiled separately?

I can only guess / infer from what I see in our history. Both fragments implement additional capabilities connected to the compiler that were introduced around Java 6 (JSR 269 and JSR 199), right? As such the had to set BREE 1.6, while the rest of JDT/Core was still at 1.4 (!). That's why the implementation had to be kept separate.

If that was the only reason, then the reason is gone in times where JDT/Core requires 11.

For authoritative answers you'd have to ask Walter Harley or Olivier Thomann, I believe. I haven't heard from Walter for ages, but Olivier might still respond?

[guw]

+1 for merging the fragments into a new ECJ bundle. They make ECJ a better offering in the Java ecosystem.

My hypothesis is that they are separate because they have been created long time ago while JDT was much more strict with who and what goes into jdt.core.

[stephan-herrmann]

My hypothesis ...

The JDK 6 dependency was a sufficient reason to keep those fragments separate (see my previous comment). I just wasn't sure if that was the only reason.

As of today I cannot think of any reason against merging.

[jarthana]

@stephan-herrmann , @jarthana : WDYT about #182 ?

I am not sure I understand the changes in org.eclipse.jdt.core/.classpath. What does this mean to org.eclipse.jdt.core as a Java Project in the IDE?

Do you have any idea why org.eclipse.jdt.compiler.apt and org.eclipse.jdt.compiler.tool are fragments of jdt.core? Just a hack to get the standalone part compiled separately?

I agree with Stephan's reasoning.

Would there be any issue if we just merge all three code bases together (ecj + org.eclipse.jdt.compiler.apt + org.eclipse.jdt.compiler.tool) in one real bundle? At the end that is what ecj.jar does?

I can't think of a reason why this will be a big problem. Except that org.eclipse.jdt.core, when shipped with IDE, will contain some code that won't be useful. Or are you suggesting that we continue to make two bundles?

[iloveeclipse]

are you suggesting that we continue to make two bundles?

Yes. One "ecj" bundle for batch compiler (and apt) and one "core" bundle for the rest of jdt, that depends on ecj.

[stephan-herrmann]

are you suggesting that we continue to make two bundles?

Yes. One "ecj" bundle for batch compiler (and apt) and one "core" bundle for the rest of jdt, that depends on ecj.

I'm not sure this is the same split that @jarthana had in mind, see:

org.eclipse.jdt.core, when shipped with IDE, will contain some code that won't be useful.

This seems to refer to code from source folder antadapter, right?

[jarthana]

org.eclipse.jdt.core, when shipped with IDE, will contain some code that won't be useful.

This seems to refer to code from source folder antadapter, right?

I had that and "batch" in my mind. But just checked the jdt.core bundle and to my surprise found all those classes already in there. We really don't need them, do we? Perhaps there's some history I don't remember.

[stephan-herrmann]

org.eclipse.jdt.core, when shipped with IDE, will contain some code that won't be useful.

This seems to refer to code from source folder antadapter, right?

I had that and "batch" in my mind. But just checked the jdt.core bundle and to my surprise found all those classes already in there. We really don't need them, do we? Perhaps there's some history I don't remember.

Well, who remembers the decisions from 2001 or earlier :)

Just two small observations:

• org.eclipse.jdt.core.compiler.batch.BatchCompiler is API, so if it's in jdt.core now, it must remain there. It then pulls in all the rest from "batch".
• lot's of our tests use "batch", so they need a way to depend on it