|Re: [jdt-dev] Need some more current pointers for getting started on JDT projects|
A few answers inline: On 18.09.19 21:36, Richard Steiger wrote:
1. AFAIK, I haven't received any emails from Manoj (or on a thread on such mails), so don't have access to his suggestions to run RunJDTCoreTest.
You may need to check your spam settings :) https://www.eclipse.org/lists/jdt-dev/msg01240.html
2. Running with changes: I'll give the "launch a runtime workbench" a try later today, but since time is the most precious asset any of us has, I was hoping for something having a much shorter null-debug-loop time, namely, running focused unit tests as normal debug launches in the JDT workbench. 1. My first (current) attempt is to create a tiny harness as a Maven project (in the JDT workbench), intended to launch the batch compiler on a series of compilation scenarios/cases, then leverage ability to use breakpoints, tracing, stepping, etc, and move at least an order of magnitude faster. Should or shouldn't this be a viable approach, overall?
I'm skeptical, but for reasons that relates to the generally tense relationship between maven and me ;p Unless you really want, maven should never be *necessary* for Eclipse work. And starting a maven process certainly has its price performance wise.
If the existing JUnit-Plugin Tests have to much overhead for your purpose (do they really?? for me it's a 5 sec. delay, not more), feel free to directly invoke org.eclipse.jdt.internal.compiler.batch.Main.compile(String, PrintWriter, PrintWriter, CompilationProgress) from your unit tests. Perhaps even some goodness from AbstractBatchCompilerTest can be used without OSGi.
3. Thanks for the suggestion to focus my learning cycles in particular areas, and engage other relative experts in those areas. Yes, the compiler is my first focus. > 4. [...] I take it from your lack of suggestions that there aren't other ejc theory of operation docs and such, [...]
Long time ago I supervised a master thesis  which has a chapter giving an overview of ecj. Unfortunately, it's in German, but once I received feedback that even an automatic translation was helpful to someone :)
Individual topics are even documented within the code :)
5. I do want to (and intend to) tell y'all what my goals are, as they attain sufficient priority to start working on them. [...] 2. My immediate goal is to enable development of projects having cyclicmodule dependencies.
When you say "module", what exactly do you mean? A project in Eclipse? A maven artifact? A JPMS module?
Concerning the topic of cycles you should surely be interested in the fire fighting we did these days. In particular  will give you pointers to code where cycles are detected.
3. What I'm trying to assess very quickly is whether ejc and the rest of jdt can be relatively easily (non-violently) teased into treating module graphs as fixed-point type inferencing/resolution problems, just the way that cyclic type ancestries and references are resolved.
"fix-point": likely. "resolution": yes. "type inference" is a different animal, I'm convinced. best, Stephan  http://objectteams.org/publications/Diplom_Markus_Witte.pdf  https://bugs.eclipse.org/bugs/show_bug.cgi?id=551284  https://bugs.eclipse.org/bugs/show_bug.cgi?id=551147
Back to the top