Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 483300

Summary: Tycho CompilerMain uses JDT internals
Product: z_Archived Reporter: Jan Sievers <jan.sievers>
Component: TychoAssignee: Project Inbox <tycho-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: daniel_megert, david_williams, igor, jarthana, manoj.palat, mistria, stephan.herrmann
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=528905
https://git.eclipse.org/r/115711
https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=5928f7d4dfe18679f28efbd4ca9138db12ad3cb5
Whiteboard:
Bug Depends on: 514471    
Bug Blocks:    

Description Jan Sievers CLA 2015-11-30 06:54:37 EST 
this is a follow-up on bug 483239

Tycho uses JDT internals which changed recently and broke the Tycho-JDT integration.

AFAIK JDT internals are used so we can change java.home used for compilation even when compiling in-process.

https://github.com/eclipse/tycho/blame/master/tycho-compiler-jdt/src/main/java/org/eclipse/tycho/compiler/jdt/CompilerMain.java

We should either try to find a way to achieve the same functionality without using internals or failing that, request API from JDT core.
Comment 1 Igor Fedorenko CLA 2015-11-30 08:57:42 EST 
Not sure how much you want to invest into this, but I've written a better naming environment implementation at Takari [1]. It works faster for larger classpaths (jdt code has inefficient O(N) linear classpath scan) and classpath entries can be cached and used in multithreaded builds.


[1] https://github.com/takari/takari-lifecycle/tree/master/takari-lifecycle-plugin/src/main/java/io/takari/maven/plugins/compile/jdt/classpath
Comment 2 Jan Sievers CLA 2017-12-11 07:31:08 EST 
the fix for bug 514471 will probably solve this
Comment 3 Stephan Herrmann CLA 2017-12-11 19:18:33 EST 
(In reply to Igor Fedorenko from comment #1)
> Not sure how much you want to invest into this, but I've written a better
> naming environment implementation at Takari [1]. It works faster for larger
> classpaths (jdt code has inefficient O(N) linear classpath scan) and
> classpath entries can be cached and used in multithreaded builds.
> 
> 
> [1]
> https://github.com/takari/takari-lifecycle/tree/master/takari-lifecycle-
> plugin/src/main/java/io/takari/maven/plugins/compile/jdt/classpath

Would that be interesting for JDT itself?

Mmh, I don't see a ClasspathJrt in your repo, so which version of JDT is this compatible with?
Comment 4 Igor Fedorenko CLA 2017-12-11 22:46:23 EST 
Current master uses 4.6.2 compiler and I have local changes to update to 4.7.2 but without java 9 support. I have not looked at java 9 support yet, so can't tell how difficult it will be to implement (note that my original comment was from 2015, way before java 9 become a thing at eclipse). I am obviously biased, but I think Takari naming environment implementation is something that will benefit jdt command line build. Don't want to get too offtopic, but there are other interesting parts of Takari implementation, like better incremental annotation processing support, that can be useful in jdt. Happy to give more details on what we did at Takari if jdt developers are interested.
Comment 6 Jan Sievers CLA 2018-01-24 11:24:49 EST 
fixed as part of bug 514471