Andrey,
Thanks for pointing-out that there's an option for controlling
the compiler's behavior in the face of detecting classpath
cycles. Still being new to JDT, I've been trying to track-down
whether the option had been surfaced, and didn't think to look at
the ... -> Compiler -> Building -> Build path
problems pane, so you've saved me some time finding it, and
a whole lot more time testing!
As to whether I've filed a bug, not yet, since chose to first do
a "proof of concept" stage to determine if this is a feasible
capability. With your input, I now know that the answer is "it's
feasible", and can now determine whether there's a need to make
any changes; I expect this phase to take at least the next day or
so. Assuming this is successful, I suspect that I'll file a bug,
proposing to add an Ignore value to the option, so
projects having circularities don't get any useless warnings.
As for the reasons I'm looking into this, I've laid them out
pretty completely in the prior message (see the section entitled Why
Allow Classpath Cycles?), from which you'll learn that
I have a long-standing requirement, spanning an entire
product-line, to design and implement circular dependencies, as a
first-class architectural pattern.
I'm open to discussing in a professional manner, my reasoning for
selectively embracing circularities at the project level, and am
open to hearing of alternatives and exploring the tradeoffs.
(That said, for clarity, I'm not interested in debating the issue
on aesthetic, pseudo-religious, or other non-empirical,
non-engineering-economics bases.)
Thanks alot,
-rjs
On 10/17/2019 1:23 AM, Andrey Loskutov
wrote:
Richard,
Have you reported some concrete bug that you are trying to
solve?
May be I'm missing something, but do you know that we have
already a possibility to allow build cycles?
Preferences -> Java -> Compiler -> Building ->
Build path problems -> Circular dependencies
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
_______________________________________________
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
_______________________________________________
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
|