|
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 :)
https://www.eclipse.org/lists/jdt-dev/msg01240.html
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 [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 :)
As of recently, Google's translation of [1] 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.
Individual topics are even documented within the code :)
Why Allow Classpath Cycles?
My immediate goal is to enable development
of projects having cyclic module dependencies.
You asked:
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[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.
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[2][3], 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.
Best,
-rjs
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
|
