Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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 [1] 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 cyclic
module 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[2][3] we did these days. In particular [2] 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

[1] http://objectteams.org/publications/Diplom_Markus_Witte.pdf
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=551284
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=551147

Back to the top