On Wed, Jan 24, 2018 at 2:27 PM, Ed Merks <[email protected]> wrote: > I'm a more than little annoyed to see that this method > > org.eclipse.jface.internal.text.html.HTMLPrinter.insertPageProlog(StringBuffer, > int, RGB, RGB, String) > > has gone from deprecated to deleted in less than a 5 week period: > > https://github.com/eclipse/eclipse.platform.text/commits/master/org.eclipse.jface.text/src/org/eclipse/jface/internal/text/html/HTMLPrinter.java > > JDT, EMF, Xtext, and Oomph all use this method.
So where were the people from these projects all these years and no one have stepped in to make such a thing proper API? > > I really don't care to hear the arguments about it being internal because: > > I don't see that JDT ought to have exclusive special privileges to use > internal things. > I don't see any reason why it should be internal. > And any client wanting to implement hovers that work like the ones for JDT, > will have the same needs as JDT and will solve the problem the same way. > > I'd like to avoid dwelling on the fact that this is simply a pointless > change, but I can't help it. Surely one wouldn't change this simply to > improve performance in code that has no relevant performance impact! It > seems to me at best a misguided effort that would be better spent on real > improvements. Neither you nor me nor anyone else has the right to tell anyone what to contribute in his own time! > > Please revert this change before M5. > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=530240 > > 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: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=529118 You're not serious, right? Do you seriously expect for every change to do a check on every Eclipse plugin existing whether it used the internal method to be changed? Oh wait that can't be only the release train this must include Pydev, JBoss Tools , Spring Tools and etc, right? If anyone has such expectations this is clearly not going to happen. For every case where someone uses internal he/she must know it's a risk taken by them on purpose. I for one strongly disagree with exporting internal packages from bundles at all, that would solve so many such issues and boost people to work in proper way! > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Alexander Kurtakov Red Hat Eclipse Team _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
