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

Ed, we have an on-going effort to reduce the number of Sonar warnings
in the platform code.  Moving from StringBuffer to StringBuilder in
our internal API is part of that.

As this method seems to be heavily used by others, I'm also surprised
that it was never requested as proper public API.

As for now I will revert the deletion the "old" internal methods via
https://bugs.eclipse.org/bugs/show_bug.cgi?id=530240.

Best regards, Lars

On Wed, Jan 24, 2018 at 1:38 PM, Aleksandar Kurtakov
<akurtako@xxxxxxxxxx> wrote:
> On Wed, Jan 24, 2018 at 2:27 PM, Ed Merks <ed.merks@xxxxxxxxx> 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
>> 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
>
>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> _______________________________________________
> 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



-- 
Eclipse Platform project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com


Back to the top