Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] HTMLPrinter is Broken

Mickael,

Comments below.


On 24.01.2018 15:08, Mickael Istria wrote:
Hi Ed, all

@Ed: First, don't pretend you don't know what "internal" means here, you're smarter than that. Those projects deliberately built against such risk and it's fair to have them dealing with there own issues. Platform is a welcoming project, and anyone who needs to make code API can ask and do.
That's great in principle, but often not so workable in practice.

What you fail to take into consideration is that EMF tries to provide the broadest range of environments into which EMF can be installed.  So the best I could do in this situation is to change my code to use reflection that detects which versions of the methods are available.  And even if new APIs were introduced in Photon, I'd still end up with yet more ugly reflective code to cover all the bases. 

Oomph is in a similar boat, supporting the ability to create Juno installations and running in those installations (thanks to the fact that EMF supports that too).  If you saw how much internals we've needed to use in Oomph you'd hurl.  If we waiting for APIs, we'd still be working on creating them, with nothing to show for it.

In life there are ideals and I think we all agree on what ideally should be the case.  And then pragmatism must set in because we need to accomplish a goal today, or this year.

  1. I don't see that JDT ought to have exclusive special privileges to use internal things.
JDT doesn't have privileges and everyone is free to use internal packages.
But JDT succeeds to do it well because it does understand and comply with the meaning of internal and have set some practices to not be affected in a breaking way: building against Platform master source code or latest integration/nightly build to spot defects ASAP, agreement in making the necessary changes when need be or asking immediately to Platform for some remediation in too tricky scenarios, configuration of version range to not be affected by changes in internal code...
You'll note that I reported this problem before it appeared in M5.
Every project that follows similar practices can safely use internals. Projects that use internals without such practices were warned in the IDE when choosing to pick and internal API, and deliberately chose to ignore the warning either by keeping the reference to internal code, or not setting up a process that allows to spot such issues extremely early.
We can detect the problem, but as I explained above, it's not always possible to simply change StringBuffer to StringBuilder and have the problem go away, though that worked nicely with JDT because it doesn't expect to be able to install into Oxygen.

Fortunately, the milestone builds are here so that even projects that don't have such a process as JDT one can detect issue a bit later, during milestones and react accordingly.
Oomph's Targlets use the platform's IBuilds by default for a Photon target platform, so that helps find problems early too.

But I agree with Alex and others that any request to have internal code managed like API is something Platform cannot afford at the moment, and could afford better if users of such internal code were more involved in Platform to make those officially APIs, or at the very least asking for those to become APIs on the bug tracker.
I've have worked 12+ hour days for the last month getting the darned EMF build work, so I can assure you that I do not have a surplus of time to invest elsewhere.

Please revert this change before M5.

Why would Platform make an effort for downstream projects not properly using code? Platform is fully working as contracted in project plan, nothing to blame on Platform here.
Because life a game of give and take and most people realize that.  I'll point out that I'm not actually personally obligated to provide anything for anyone either but I know that getting a build in place is important for a great many people so I do it anyway.  We could see how shipping a release train works out without the effort I invest in EMF.

And in the future, please consider that any internal API that is used by any other project is going to cause problems for many projects just as it did for JDT:

Sure, but that won't prevent internal code from changing in a non-API compatible way forever. In the future, projects that use internal code just have to be ready to change your code which has internal references, like they've been expected to be since inception of API contracts.
I'm well aware of the facts.

And see how JDT dealt with it? A patch was produced then merged. JDT understands what internal means, takes responsibility and remediates gently without offending other developers. Take that as an example.
I'll take Lars' changing the code back as a much better example.  It's really a very small problem that's easy to avoid, and I appreciate his effort and his explanation about Sonar warnings, which I did not take into account.  This is give an take.  I change the EMF templates so that they generate StringBuilder instead of StringBuffer so that Lars can regenerate the platform UI models.  And he's kind enough not to take offense even when I'm a jerk; lack of sleep tends to cause that.



Now, for the specific case of HTMLPrinter, I agree it would better become an API then.
@Ed: would you mind opening the bug request?


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Back to the top