Leo,
I have read the whole thread.
Comments below.
On 25.01.2018 17:44, Leo Ufimtsev wrote:
I haven't read the whole thread.
But I think it's fairly common sense that one should not use internal
api by an external project. It's just one of life's axioms.
It's definitely best avoided, when possible, but that's the caveat. When
it's not possible to implement JDT without using UI internals and it's
not possible to implement PDE without p2 internals then axiomatically it
follows that others wanting to implement cool functionality like these
projects do will find themselves in the same boat.
It's like people who use reflection to get to private members of a
java class and deploy that code into production.
The Eclipse itself runtime does exactly that:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=502209
That's just a 'quick' workaround that generates unstable products.
Yes, it's less than ideal, with the added huge disadvantage that you
only see failures at runtime, so the tests better be good.
I really cannot see any way to justify using internal api for use in a
stable product beyond testing / development / exploration / proof of
concept.
Yet the platform project's own teams make a habit of this practice. That
too would appear to be unjustifiable.
And by extension, internal api should be subject to change and removal
at any given time without prior notice.
I understand that you primarily see this as black or white, but thank
goodness the JDT team doesn't take this attitude and sees all the shades
of gray between the extremes.
I can only suggest that you look carefully within your glass house,
making sure its furnishings set the highest standard with regard to the
fundamental principles according to which you expect others to furnish
their houses.
--
Leo Ufimtsev, Software Engineer, Red Hat
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
