Do you mean they are now using a new library which now inappropriately
uses the moved internal API, and they consider that problem solved ?
-phil.
On 12/1/11 8:00 AM, Martijn Verburg wrote:
Hi Roman,
Exactly :-), yes they want to avoid using the internal APIs. After
your hint they were quickly able to find a library that wraps the
internal API, problem solved.
Cheers,
Martijn
On 1 December 2011 15:49, Roman Kennke<ro...@kennke.org> wrote:
Ah and of course... maybe you should try to avoid using internal APIs to
begin with. What exactly are you trying to do with this?
Regards, Roman
Am Donnerstag, den 01.12.2011, 15:30 +0000 schrieb Martijn Verburg:
Thanks, that helps a bunch!
On 1 December 2011 15:21, Roman Kennke<ro...@kennke.org> wrote:
Hi Martijn,
we refactored the FontManager internal API, it's now:
FontManagerFactory.getInstance().getNewComposite() (or whatever other
FontManager static method it was before). There are a few methods that
have been moved to other classes, but this one is still available in the
FontManager interface (that's what it is now).
I hope that helps.
Regards, Roman
Am Donnerstag, den 01.12.2011, 14:51 +0000 schrieb Martijn Verburg:
Hi all,
I'm dealing with a 3rd party-lib that is sadly using
sun.font.FontManager (getNewComposite in particular). When moving to
Java 7 this breaks (not unexpectedly) and so they'd like some advice
on what would be an appropriate OpenJDK package to use instead of the
internal sun one.
Any ideas? I'm completely clueless when it comes to this part of the
OpenJDK :|.
Cheers,
Martijn
