On 9/24/2019 5:37 AM, Stephan Herrmann wrote:
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 :)
Thanks for forwarding Manoj's message, I'm now able to run whatever JDT and other tests I need. I still have some questions about the (mostly)-hierarchical structure of suites, and what's expected or "best" practice for scoping tests to a specific project/component/feature (any docs on test modularity and design intent would be welcome). For now, I'm okay just temporarily hacking suite code while I'm getting familiar with jdt, etc.
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.
You lost me here. I made no mention of eclipse, and given the choice of involving eclipse in test launching, or not, I'll choose the latter with pleasure. (Ah, Maven, ... Don't get me started. I like Gradle a whole lot less, for various reasons, but hate that Buildship's "opinions" about classpaths are frequently broken.) (I've got a design for a next-gen build system, but that's fodder for another day.)
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.
That's pretty much what I'm doing. (BTW, to what does the "5 sec. delay" refer? If just the compile and launch the
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 :)
As of recently, Google's translation of  is fairly readable (with the usual comical goofs). I think there's value in (very selectively) reading sections pertaining to specific parts of the overall OT/Java project, so thanks for the link.
Why Allow Classpath Cycles?
Individual topics are even documented within the code :)
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?
For now, I mean "eclipse project".
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.
Yes, thanks for the pointers, all makes sense.
The specific use-case I'm addressing is as follows:
Assume I have a project Plat intended to implement a new application/service platform, and which provides very rich, nearly 100% horizontal ("generic" but that term's overloaded) services, such as deeper/more dynamic reflection/meta-programming, structured printing, comm/transport frameworks, replication, event processing, consistency, UI auto-generation, etc, etc.
Further assume that some of Plat's provided services (aka "public APIs") are facades (of some depth) on other service provider projects' (SPP) services, say projects X and Y, a specific case-in-point is a hugely enriched ANTLR parser generation framework.
Further assume for simplicity that I have access to such projects' sources, and that I want to share as many Plat features as possible, and thereby coalesce and unify SPP's abstractions around Plat's ontology, so have consistent structured printing, inspection, metaprogramming, pickling, etc spanning Plat and other constituent projects.
There are 2 broad approaches to implementing such an integrated modular ecosystem:
- current "no-cp-cycles allowed" regime: Move the interfaces defining Plat's API to a second project, call it SubPlat (or in German, UnterPlat :-) and add implementation facades to SubPlat, which the SPPs call. That's the path I've put-up with for > 2 decades, at staggering cost in time, footprint, complexity, maintenance, documentation, workarounds for object identity tears, etc, etc, ad nauseum.
- proposed "cp-cycles allowed" regime: No need for SubPlat. Resulting ecosystem is far cleaner, smaller, easier to grok, faster, and improvements in all remaining sofware engineering and cost dimensions.
In concrete terms, what I'm proposing is essentially exposing JavaCore.CORE_CIRCULAR_CLASSPATH via the existing compiler preferences subsystem, as just another flag controllable at the project or workbench grain. This avoids any taint that I'm proposing to modify Java syntax or semantics for other users and projects, now and in future releases. (It also cleanly side-steps getting into any "true-believer" word-wars about committing language heresy, etc.) While I haven't worked-out the implementation to the last detail, I've isolated the < half-dozen places where small, surgical cuts need to be made, so feel I'm going in the right direction.
Returning to the cyclic fire-fights, I must admit that I find it a bit amusing that interdicting cp-cycles and diagnosing their occurrence exacts such a high price in reporting (tough problem, which y'all excellently handled, IMHO), none of which I'll need to consider (or so I hope).
Current focus is getting the test rig working, picking-up from your and Ed Merk's helpful comments of 10/4 (and thanks).
"fix-point": likely. "resolution": yes.
"type inference" is a different animal, I'm convinced.
Yes, thanks for correcting the terminology. As I hinted in a prior message, I think the desired fixed-point dependency semantics is already handled by the class-loading architecture, so don't really anticipate any emergent issues.
So, that's the current project picture. As always, I'm completely open to any comments or hints you care to share.
_______________________________________________ jdt-dev mailing list jdt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev