After being away from doing any eclipse work since last October, I’ve resumed getting ejc to allow project dependency cycles. (All the following in on 2020-03.)
[Stephan and Andrey, Cc’ing you since you’ve both helped orient me on this project, and also in case you’re interested in the changes I’m proposing, especially if you see problems and/or have suggestions.]
The mods I’ve made and tested are, briefly:
-
Added an Ignore option to ... -> Compiler -> Building -> Build path problems
-> Circular dependencies:
-
In JavaProject:createClasspathProblemMarker, when
Ignore is selected, in the absence of any other classpath problems, detected dependency cycles are ignored. The net effect of this is to suppress adding a buildpath problem marker to the project, altogether. This approach of ditching markers at the
earliest opportunity proved to be surgically clean, and avoided “chasing” after markers, then suppressing them downstream in the
Ignore case.
-
I hacked
MultiProjectTests:testCycle*, setting
CORE_CIRCULAR_CLASSPATH to
JavaCore.IGNORE instead of
JavaCore.WARNING, but only tested
testCycle1, which covers my core use-case.
-
Before submitting these changes, I’d like to properly parameterize the
testCycle* methods, and have them run twice, once with
IGNORE, once with
WARNING. While I have an idea how to do this without bloating the code, I’d feel better making this change after discussing how best to handle such parameterized tests with someone who’s familiar with the existing testing rubric, and maybe has implemented
such parameterization.
The next step is to road-test these mods. My thought is to locally build a stock
Eclipse IDE for Java Developers package, having the above mods, and put it into daily use for a couple of weeks, using it to work on a large code-base.
What’s the recipe for building the IDE? I’d like to use the most lightweight path, e.g. don’t need to create an update site, doesn’t require pushing to git, etc.
Thanks,
-rjs
From: R Steiger <rsteiger@xxxxxxxxxxxxxxxx>
Sent: Thursday, October 17, 2019 1:54 PM
To: Andrey Loskutov <loskutov@xxxxxx>
Cc: jdt-dev@xxxxxxxxxxx
Subject: Re: [jdt-dev] discussion about my current "Enable Classpath Cycles"project
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:
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
|
