Re: FTFactory.java: Fonts loaded by Pango are never registered and always return

[Felipe Heidrich]

Mario is correct.

Basically we want to be able to compile and load this library in systems where 
libfontconfig is not available (or system where the given symbol, 
FcConfigAppFontAddFile, is not there - maybe system using old version of 
libfontconfig).

If it works for you, it just means your system has all the right versions of 
the libraries, but it doesn't mean it works on supported platforms.

Not sure why the common code didn't work for you.
does dlopen(LIB_FONTCONFIG, RTLD_LAZY) return a non-null value ?
does dlsym(handle, "FcConfigAppFontAddFile") return a non-null value ? 


Felipe




> On Mar 3, 2016, at 7:43 AM, Maurice  wrote:
> 
> Hmm  I think I have to agree with you... you are right. Commenting it in 
> didn't give a compiler or linkage error, and it made it work. I'm happy at 
> the moment and tired of the debugging process, but I'll give it more thought 
> later.
> 
> Op 03-03-16 om 16:36 schreef Mario Torre:
>> On Thu, Mar 3, 2016 at 2:48 PM, Maurice  wrote:
>>> At the moment the embedded environment I'm using is not able to use
>>> downloaded or external supplied fonts. I've traced through the system and
>>> found that it looks like it fails in pango.c FcConfigAppFontAddFile, at
>>> least OSPango.FcConfigAppFontAddFile returns false, thus propagating a null
>>> all the way up.
>>> 
>>> Checking the pango.c file I noticed something very interesting:
>>> JNIEXPORT jboolean JNICALL OS_NATIVE(FcConfigAppFontAddFile)
>>> (JNIEnv *env, jclass that, jlong arg0, jstring arg1)
>>> {
>>> static void *fp = NULL;
>>> if (!fp) {
>>> void* handle = dlopen(LIB_FONTCONFIG, RTLD_LAZY);
>>> if (handle) fp = dlsym(handle, "FcConfigAppFontAddFile");
>>> }
>>> jboolean rc = 0;
>>> if (arg1) {
>>> const char *text = (*env)->GetStringUTFChars(env, arg1, NULL);
>>> if (text) {
>>> //rc = (jboolean)FcConfigAppFontAddFile(arg0, text);
>>> if (fp) {
>>> rc = (jboolean)((jboolean (*)(jlong, const char *))fp)(arg0,
>>> text);
>>> }
>>> (*env)->ReleaseStringUTFChars(env, arg1, text);
>>> }
>>> }
>>> return rc;
>>> }
>>> 
>>> Yes, you see it correctly! The line that actually should register the font
>> Pointer to functions make me blind too, but If I'm not reading it
>> wrong, I think this is not a commented code call, it's meant to tell
>> what the code below it does (apparently, it made blind also the
>> author!):
>> 
>> FcConfigAppFontAddFile is dloaded into fp, so this totally
>> incomprehensible line:
>> 
>> ((jboolean (*)(jlong, const char *))fp)(arg0, text);
>> 
>> it's just casting fp to a function that returns a jboolean and takes a
>> jlong and a const char array as argument, hence it becomes again:
>> 
>> (jboolean)FcConfigAppFontAddFile(arg0, text);
>> 
>> Cheers,
>> Mario
> 

Request Review: 8150991 [packager] Module Path Packager Arguments

[Chris Bensen]

Hi Kevin,

Small packager change to pass module path to to the call to JDEPS.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8150991 

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8150991/webrev.00/ 


Thanks,
Chris

Re: FTFactory.java: Fonts loaded by Pango are never registered and always return

[Maurice]

I'm running on Ubuntu desktop, and I can gladly report that it works 
fine. I think I saw fp wasn't null, but I'll check later. Maybe my only 
fix was ignoring a 'false'.  According to 
https://www.freebsd.org/cgi/man.cgi?query=fontconfig&sektion=3&apropos=0&manpath=XFree86+4.5.0 
FcConfigAppFontAddFile returns a FcBool, and I did see the rc is 0.


Although ignoring the result does work, can it be something that is 
lacking in the environment? The Yocto embedded Linux is naked from the 
start, so it is totally possible that something else is missing.


Maurice.
(my pride on finding the flaw is quickly diminishing...)

Op 03-03-16 om 17:20 schreef Philip Race:

Since I don't see any code here that looks like it would run only on
an embedded environment then I wonder why Linux desktop users
are not reporting the same problem ?

Did your instrumentation check that both dlopen & dlsym succeeeded ?

-phil.

On 3/3/16, 7:43 AM, Maurice wrote:
Hmm  I think I have to agree with you... you are right. 
Commenting it in didn't give a compiler or linkage error, and it made 
it work. I'm happy at the moment and tired of the debugging process, 
but I'll give it more thought later.


Op 03-03-16 om 16:36 schreef Mario Torre:

On Thu, Mar 3, 2016 at 2:48 PM, Maurice  wrote:

At the moment the embedded environment I'm using is not able to use
downloaded or external supplied fonts. I've traced through the 
system and
found that it looks like it fails in pango.c 
FcConfigAppFontAddFile, at
least OSPango.FcConfigAppFontAddFile returns false, thus 
propagating a null

all the way up.

Checking the pango.c file I noticed something very interesting:
JNIEXPORT jboolean JNICALL OS_NATIVE(FcConfigAppFontAddFile)
 (JNIEnv *env, jclass that, jlong arg0, jstring arg1)
{
 static void *fp = NULL;
 if (!fp) {
 void* handle = dlopen(LIB_FONTCONFIG, RTLD_LAZY);
 if (handle) fp = dlsym(handle, "FcConfigAppFontAddFile");
 }
 jboolean rc = 0;
 if (arg1) {
 const char *text = (*env)->GetStringUTFChars(env, arg1, 
NULL);

 if (text) {
//rc = (jboolean)FcConfigAppFontAddFile(arg0, text);
 if (fp) {
 rc = (jboolean)((jboolean (*)(jlong, const char 
*))fp)(arg0,

text);
 }
 (*env)->ReleaseStringUTFChars(env, arg1, text);
 }
 }
 return rc;
}

Yes, you see it correctly! The line that actually should register 
the font

Pointer to functions make me blind too, but If I'm not reading it
wrong, I think this is not a commented code call, it's meant to tell
what the code below it does (apparently, it made blind also the
author!):

FcConfigAppFontAddFile is dloaded into fp, so this totally
incomprehensible line:

((jboolean (*)(jlong, const char *))fp)(arg0, text);

it's just casting fp to a function that returns a jboolean and takes a
jlong and a const char array as argument, hence it becomes again:

(jboolean)FcConfigAppFontAddFile(arg0, text);

Cheers,
Mario

Re: FTFactory.java: Fonts loaded by Pango are never registered and always return

[Philip Race]

Since I don't see any code here that looks like it would run only on
an embedded environment then I wonder why Linux desktop users
are not reporting the same problem ?

Did your instrumentation check that both dlopen & dlsym succeeeded ?

-phil.

On 3/3/16, 7:43 AM, Maurice wrote:
Hmm  I think I have to agree with you... you are right. Commenting 
it in didn't give a compiler or linkage error, and it made it work. 
I'm happy at the moment and tired of the debugging process, but I'll 
give it more thought later.


Op 03-03-16 om 16:36 schreef Mario Torre:

On Thu, Mar 3, 2016 at 2:48 PM, Maurice  wrote:

At the moment the embedded environment I'm using is not able to use
downloaded or external supplied fonts. I've traced through the 
system and

found that it looks like it fails in pango.c FcConfigAppFontAddFile, at
least OSPango.FcConfigAppFontAddFile returns false, thus propagating 
a null

all the way up.

Checking the pango.c file I noticed something very interesting:
JNIEXPORT jboolean JNICALL OS_NATIVE(FcConfigAppFontAddFile)
 (JNIEnv *env, jclass that, jlong arg0, jstring arg1)
{
 static void *fp = NULL;
 if (!fp) {
 void* handle = dlopen(LIB_FONTCONFIG, RTLD_LAZY);
 if (handle) fp = dlsym(handle, "FcConfigAppFontAddFile");
 }
 jboolean rc = 0;
 if (arg1) {
 const char *text = (*env)->GetStringUTFChars(env, arg1, NULL);
 if (text) {
//rc = (jboolean)FcConfigAppFontAddFile(arg0, text);
 if (fp) {
 rc = (jboolean)((jboolean (*)(jlong, const char 
*))fp)(arg0,

text);
 }
 (*env)->ReleaseStringUTFChars(env, arg1, text);
 }
 }
 return rc;
}

Yes, you see it correctly! The line that actually should register 
the font

Pointer to functions make me blind too, but If I'm not reading it
wrong, I think this is not a commented code call, it's meant to tell
what the code below it does (apparently, it made blind also the
author!):

FcConfigAppFontAddFile is dloaded into fp, so this totally
incomprehensible line:

((jboolean (*)(jlong, const char *))fp)(arg0, text);

it's just casting fp to a function that returns a jboolean and takes a
jlong and a const char array as argument, hence it becomes again:

(jboolean)FcConfigAppFontAddFile(arg0, text);

Cheers,
Mario

[9-dev] RFR(XS): 8088809: MenuItem.setText() is broken (Mac)

[Morris Meyer]

Kevin, David and David,

Please review this small patch for changing a Mac system menu item, 
where that item is a top level menu in the [NSApp mainMenu] menu bar.


The fix is to look specifically in the main menu for these items, and to 
use the appropriate mechanism to set the title of that top-level menu.


Thanks,

--morris

WEBREV - http://cr.openjdk.java.net/~morris/JDK-8088809.01/
BUG - https://bugs.openjdk.java.net/browse/JDK-8088809

Re: FTFactory.java: Fonts loaded by Pango are never registered and always return

[Maurice]

Hmm  I think I have to agree with you... you are right. Commenting 
it in didn't give a compiler or linkage error, and it made it work. I'm 
happy at the moment and tired of the debugging process, but I'll give it 
more thought later.


Op 03-03-16 om 16:36 schreef Mario Torre:

On Thu, Mar 3, 2016 at 2:48 PM, Maurice  wrote:

At the moment the embedded environment I'm using is not able to use
downloaded or external supplied fonts. I've traced through the system and
found that it looks like it fails in pango.c FcConfigAppFontAddFile, at
least OSPango.FcConfigAppFontAddFile returns false, thus propagating a null
all the way up.

Checking the pango.c file I noticed something very interesting:
JNIEXPORT jboolean JNICALL OS_NATIVE(FcConfigAppFontAddFile)
 (JNIEnv *env, jclass that, jlong arg0, jstring arg1)
{
 static void *fp = NULL;
 if (!fp) {
 void* handle = dlopen(LIB_FONTCONFIG, RTLD_LAZY);
 if (handle) fp = dlsym(handle, "FcConfigAppFontAddFile");
 }
 jboolean rc = 0;
 if (arg1) {
 const char *text = (*env)->GetStringUTFChars(env, arg1, NULL);
 if (text) {
//rc = (jboolean)FcConfigAppFontAddFile(arg0, text);
 if (fp) {
 rc = (jboolean)((jboolean (*)(jlong, const char *))fp)(arg0,
text);
 }
 (*env)->ReleaseStringUTFChars(env, arg1, text);
 }
 }
 return rc;
}

Yes, you see it correctly! The line that actually should register the font

Pointer to functions make me blind too, but If I'm not reading it
wrong, I think this is not a commented code call, it's meant to tell
what the code below it does (apparently, it made blind also the
author!):

FcConfigAppFontAddFile is dloaded into fp, so this totally
incomprehensible line:

((jboolean (*)(jlong, const char *))fp)(arg0, text);

it's just casting fp to a function that returns a jboolean and takes a
jlong and a const char array as argument, hence it becomes again:

(jboolean)FcConfigAppFontAddFile(arg0, text);

Cheers,
Mario

Re: FTFactory.java: Fonts loaded by Pango are never registered and always return

[Mario Torre]

On Thu, Mar 3, 2016 at 2:48 PM, Maurice  wrote:
> At the moment the embedded environment I'm using is not able to use
> downloaded or external supplied fonts. I've traced through the system and
> found that it looks like it fails in pango.c FcConfigAppFontAddFile, at
> least OSPango.FcConfigAppFontAddFile returns false, thus propagating a null
> all the way up.
>
> Checking the pango.c file I noticed something very interesting:
> JNIEXPORT jboolean JNICALL OS_NATIVE(FcConfigAppFontAddFile)
> (JNIEnv *env, jclass that, jlong arg0, jstring arg1)
> {
> static void *fp = NULL;
> if (!fp) {
> void* handle = dlopen(LIB_FONTCONFIG, RTLD_LAZY);
> if (handle) fp = dlsym(handle, "FcConfigAppFontAddFile");
> }
> jboolean rc = 0;
> if (arg1) {
> const char *text = (*env)->GetStringUTFChars(env, arg1, NULL);
> if (text) {
> //rc = (jboolean)FcConfigAppFontAddFile(arg0, text);
> if (fp) {
> rc = (jboolean)((jboolean (*)(jlong, const char *))fp)(arg0,
> text);
> }
> (*env)->ReleaseStringUTFChars(env, arg1, text);
> }
> }
> return rc;
> }
>
> Yes, you see it correctly! The line that actually should register the font

Pointer to functions make me blind too, but If I'm not reading it
wrong, I think this is not a commented code call, it's meant to tell
what the code below it does (apparently, it made blind also the
author!):

FcConfigAppFontAddFile is dloaded into fp, so this totally
incomprehensible line:

((jboolean (*)(jlong, const char *))fp)(arg0, text);

it's just casting fp to a function that returns a jboolean and takes a
jlong and a const char array as argument, hence it becomes again:

(jboolean)FcConfigAppFontAddFile(arg0, text);

Cheers,
Mario

FTFactory.java: Fonts loaded by Pango are never registered and always return

[Maurice]

At the moment the embedded environment I'm using is not able to use 
downloaded or external supplied fonts. I've traced through the system 
and found that it looks like it fails in pango.c FcConfigAppFontAddFile, 
at least OSPango.FcConfigAppFontAddFile returns false, thus propagating 
a null all the way up.


Checking the pango.c file I noticed something very interesting:
JNIEXPORT jboolean JNICALL OS_NATIVE(FcConfigAppFontAddFile)
(JNIEnv *env, jclass that, jlong arg0, jstring arg1)
{
static void *fp = NULL;
if (!fp) {
void* handle = dlopen(LIB_FONTCONFIG, RTLD_LAZY);
if (handle) fp = dlsym(handle, "FcConfigAppFontAddFile");
}
jboolean rc = 0;
if (arg1) {
const char *text = (*env)->GetStringUTFChars(env, arg1, NULL);
if (text) {
//rc = (jboolean)FcConfigAppFontAddFile(arg0, text);
if (fp) {
rc = (jboolean)((jboolean (*)(jlong, const char 
*))fp)(arg0, text);

}
(*env)->ReleaseStringUTFChars(env, arg1, text);
}
}
return rc;
}

Yes, you see it correctly! The line that actually should register the 
font with pango is commented out! I removed the comment, but still the 
result is false. I then overruled the return code in FTFactory.java 
registerEmbeddedFont to be always true after it has called the native 
function, and voilà, there are my external fonts.


What a journey :-)

Maurice.

8151148: [TEST BUG] Fix imports for com.sun.javafx.Utils

[Andrey Rusakov]

Hello, everyone!
I've found that test workspace fixes for JDK-8093068 
 were not integrated 
into tests files and that need to be done.
Please look at my small fix: 
http://cr.openjdk.java.net/~arusakov/8151148/webrev.00/ 
 and commit it.

Changeset is also applicable for 9u-dev tests.