|Re: [cross-project-issues-dev] HTMLPrinter is Broken|
On 24.01.2018 15:08, Mickael Istria wrote:
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.
You'll note that I reported this problem before it appeared in M5.
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.
Oomph's Targlets use the platform's IBuilds by default for a Photon target platform, so that helps find problems early too.
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.
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.
I'm well aware of the facts.
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.
Back to the top