Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8260616: Removing remaining JNF dependencies in the java.desktop module #2305

Closed
wants to merge 7 commits into from
Closed

Conversation

prrace
Copy link
Contributor

@prrace prrace commented Jan 29, 2021

This completes the desktop module JNF removal

  • remove -framework JavaNativeFoundation from make files

  • remove #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S

  • replace JNFNSToJavaString with NSStringToJavaString and JNFJavaToNSString with JavaStringToNSString

  • replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString

  • replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI

  • Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)

  • Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.

  • define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.

  • Remove the single usage of JNFPerformEnvBlock

  • replace JNFJavaToNSNumber in single A11Y file with local replacement

  • replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement

  • remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m

  • misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8260616: Removing remaining JNF dependencies in the java.desktop module

Reviewers

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2305/head:pull/2305
$ git checkout pull/2305

@bridgekeeper
Copy link

bridgekeeper bot commented Jan 29, 2021

👋 Welcome back prr! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr label Jan 29, 2021
@openjdk
Copy link

openjdk bot commented Jan 29, 2021

@prrace The following labels will be automatically applied to this pull request:

  • 2d
  • awt
  • build

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added 2d build awt labels Jan 29, 2021
@mlbridge
Copy link

mlbridge bot commented Jan 29, 2021

Webrevs

@magicus
Copy link
Member

magicus commented Jan 29, 2021

I mostly have questions about what is missing from this PR. :-) (If this is supposed to remove the final remnants of JNF)

  • There is a disabled warning in make/autoconf/flags-cflags.m4, line 173, referring to JavaNativeFoundation. It can presumably be removed. If it triggers individually instead, the warning should be disabled on a per-library basis.

  • In make/modules/java.base/Lib.gmk, line 99 & 113, are references to JavaNativeFoundation. It seems that libosxsecurity needs to be cleaned from JNF as well. Also, the comments indicate that the exception for STATIC_BUILD can be removed. (You can verify this with configure --enable-static-build)

  • In make/modules/java.desktop/Lib.gmk, line 129, and make/modules/java.desktop/lib/Awt2dLibraries.gmk, line 866 & 094, it seems like libosx, libawt_lwawt, and liboxui also has JNF that needs to be removed. If these are fixed in any of the other issues for the umbrella JDK-8257852, I apologize. I could not figure that out.

  • There is also a test dependency that I have seen being addressed, in make/test/JtregNativeJdk.gmk line 82, for libTestMainKeyWindow.

@mlbridge
Copy link

mlbridge bot commented Jan 29, 2021

Mailing list message from erik.joelsson at oracle.com on awt-dev:

On 2021-01-29 02:56, Magnus Ihse Bursie wrote:

On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race <prr at openjdk.org> wrote:

This completes the desktop module JNF removal

* remove -framework JavaNativeFoundation from make files

* remove #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S

* replace JNFNSToJavaString with NSStringToJavaString and JNFJavaToNSString with JavaStringToNSString

* replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString

* replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI

* Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)

* Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.

* define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.

* Remove the single usage of JNFPerformEnvBlock

* replace JNFJavaToNSNumber in single A11Y file with local replacement

* replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement

* remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m

* misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)
I mostly have questions about what is missing from this PR. :-) (If this is supposed to remove the final remnants of JNF)

- There is a disabled warning in `make/autoconf/flags-cflags.m4`, line 173, referring to JavaNativeFoundation. It can presumably be removed. If it triggers individually instead, the warning should be disabled on a per-library basis.

- In `make/modules/java.base/Lib.gmk`, line 99 & 113, are references to JavaNativeFoundation. It seems that `libosxsecurity` needs to be cleaned from JNF as well. Also, the comments indicate that the exception for STATIC_BUILD can be removed. (You can verify this with `configure --enable-static-build`)

libosxsecurity is being worked on separately, see
https://github.com//pull/1845

That said, we may need a separate bug for build to remove the any
lingering global stuff after each component has been fixed.

/Erik

@prrace
Copy link
Contributor Author

prrace commented Jan 29, 2021

Right, this is the desktop module as per the first line of the comment.
java.base needs to be removed by the other PR as Erik said.
I had not spotted it, but I don't see why the make/test /JtregNativeJdk.gmk case needs to link this framework.
I don't see it being used by the test in question.
But we can just remove it and prove it - but probably a separate PR since it is nothing to do with the desktop module and the autoconf code needs to be updated once everything else is in.


// Draw the text context
DrawTextContext(env, qsdo, awtStrike, unichars, len, x, y);
}
else
{
// Get string to draw and the length
const jchar *unichars = JNFGetStringUTF16UniChars(env, str);
Copy link

@gerard-ziemski gerard-ziemski Jan 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to JNFString.h, the JNFGetStringUTF16UniChars() API:

/*

  • Gets UTF16 unichars from a Java string, and checks for errors and raises a JNFException if
  • the unichars cannot be obtained from Java.
    */

raises a (JNFException) if it can't get the chars, but now we simply return if GetStringChars() can not return the chars.

Seems like we handle this case differently in the new code now - is this change desired and correct?

Copy link
Contributor Author

@prrace prrace Jan 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are correct, but I decided that here it is fine.
If GetStringChars fails it will return NULL (it does not raise any excptions itself).
I added a check for NULL if NULL we then return from the JNI method to Java.
In the old case it also would return but would additionally propagate that raised exception to Java which JNF
decided to throw into the mix when there's already a standard way of testing failure.
And since we already know str != NULL we are in the realms of something went badly wrong inside the VM for
this to fail. So I decided this was all fine.

@@ -597,20 +598,23 @@ render using the right font (see bug 7183516) when attribString is not
{
jchar unichars[len];
(*env)->GetStringRegion(env, str, 0, len, unichars);
JNF_CHECK_AND_RETHROW_EXCEPTION(env);
CHECK_EXCEPTION();
Copy link

@gerard-ziemski gerard-ziemski Jan 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are JNF_CHECK_AND_RETHROW_EXCEPTION and CHECK_EXCEPTION equivalent?

JNF_CHECK_AND_RETHROW_EXCEPTION seems to throw exception, but CHECK_EXCEPTION does not?

Copy link
Contributor Author

@prrace prrace Jan 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JNF_CHECK_AND_RETHROW_EXCEPTION is this

/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/JavaNativeFoundation.framework/Versions/A/Headers/JNFJNI.h

// JNF_CHECK_AND_RETHROW_EXCEPTION - rethrows exceptions from Java
//
// Takes an exception thrown from Java, and transforms it into an
// NSException. The NSException should bubble up to the upper-most
// JNF_COCOA_ENTER/JNF_COCOA_EXIT pair, and then be re-thrown as
// a Java exception when returning from JNI. This check should be
// done after raw JNI operations which could cause a Java exception
// to be be thrown. The JNF{Get/Set/Call} macros below do this
// check automatically.
#define JNF_CHECK_AND_RETHROW_EXCEPTION(env)
{
jthrowable _exception = (*env)->ExceptionOccurred(env);
if (_exception) [JNFException raise:env throwable:_exception];
}

So what it actually does is clear the exception, raise an NSException and when
the code reaches JNF_COCOA_EXIT - which then has to be there - it clears the NSException
and re-throws the Java exception.

So the name of the macro is misleading since this does NOT itself rethrow the exception,
it relies on other code to do that.

CHECK_EXCEPTION will amount to the same - it throws an NSException if there is a Java exception pending.
And it will clear the NSException before exiting back to Java.
The difference is that it doesn't clear the Java Exception and later rethrow it since there is no need
There is one exception to this in CHECK_EXCEPTION - if this is the main (ie appkit) thread the java exception is cleared since there's no one to return it to ...

* There is a Cocoa constant representing that difference : NSTimeIntervalSince1970
*/
static jlong NSTimeIntervalToJavaMilliseconds(NSTimeInterval interval) {
NSTimeInterval interval1970 = interval + NSTimeIntervalSince1970;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it required for the APIs using the value from this function to expect the time calculated since Jan 1st 1970?

NSString* NormalizedPathNSStringFromJavaString(JNIEnv *env, jstring pathStr) {
if (pathStr == NULL) {
return nil;
}
NSString *nsStr = JavaStringToNSString(env, pathStr);
if (nsStr == NULL) {
return nil;
}
const char* chs = [nsStr fileSystemRepresentation];
int len = strlen(chs);
NSString* result = [[NSFileManager defaultManager]
stringWithFileSystemRepresentation:chs length:len];
return result;
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we doing:

java_string -> chars -> NSString -> chars -> [NSFileManager stringWithFileSystemRepresentation]

?

Why not just get the raw characters form JNI and feed them directly into [NSFileManager stringWithFileSystemRepresentation], ie:

java_string -> chars -> [NSFileManager stringWithFileSystemRepresentation]

and skip the JavaStringToNSString step altogether?

Copy link
Contributor Author

@prrace prrace Jan 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to explain the odd-ness of this in the comments preceding the function definition.
Near as I could figure out that intermediate call is needed to do the decomposition since the NSFileManager won't do that.
But this is not exactly my area of expertise and there may be a better way. Who is an expert on the intricacies of the macOS file system naming ?

Copy link

@gerard-ziemski gerard-ziemski Feb 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about a comment like:

/*
Returns an NSString in decomposed UTF16 format that is compatible with HFS's
expectation of the UTF16 format for file system paths.

Example string: "/Users/Amélie/"

Java's UTF16 string is "/ U s e r s / A m \351 l i e /"
macOS UTF16 string suitable for HFS is "/ U s e r s / A m e \314 \201 l i e /"

There is no direct API that takes in NSString UTF16 encoded by Java
and produces NSString UTF16 for HFS, so we first need to decompose it
into chars (suitable for low level C file APIs), and only then
create NSString representation of this decomposition back into UTF16 string.
*/

?

I borrowed the API description from Apple's original JNFNormalizedNSStringForPath API, but added an example and different description.

@gerard-ziemski
Copy link

gerard-ziemski commented Jan 29, 2021

Lots of small changes you had to handle here. Thank you for doing it!

@prrace
Copy link
Contributor Author

prrace commented Jan 29, 2021

I pushed a commit with the remaining -lframework ... removals in the desktop makefiles that I had somehow missed ...

magicus
magicus approved these changes Feb 1, 2021
Copy link
Member

@magicus magicus left a comment

Build changes look good for this PR.

@openjdk
Copy link

openjdk bot commented Feb 1, 2021

@prrace This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8260616: Removing remaining JNF dependencies in the java.desktop module

Reviewed-by: gziemski, ihse, serb

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready label Feb 1, 2021
@prrace
Copy link
Contributor Author

prrace commented Feb 1, 2021

  • There is also a test dependency that I have seen being addressed, in make/test/JtregNativeJdk.gmk line 82, for libTestMainKeyWindow.

update on this. It Is used by precisely one jtreg AWT test. So I guess it is fair game to add resolving this to the desktop module update. I am currently testing it before committing - will take a couple of hours as the headful tests take a while to run.

@gerard-ziemski
Copy link

gerard-ziemski commented Feb 1, 2021

The changes look good to me, but please see my comment from my review about documenting NormalizedPathNSStringFromJavaString() API.

const jchar *unichars = JNFGetStringUTF16UniChars(env, str);
const jchar *unichars = (*env)->GetStringChars(env, str, NULL);
if (unichars == NULL) {
return;
Copy link
Member

@mrserb mrserb Feb 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do not we need to throw an exception here? Otherwise, GetStringChars error will be ignored?

Copy link
Contributor Author

@prrace prrace Feb 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look a few lines further up at my reply 3 days ago Gerard about this.

Copy link
Member

@mrserb mrserb Feb 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read it and not sure that it is fine to ignore this error, why not throw an exception and signal the CTextPipe_doDrawString that an error occurred like InvalidPipeException or something(Sometimes we wrap other exception like OOM into the InvalidPipeException and this seems similar case)?

Copy link
Contributor Author

@prrace prrace Feb 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes look good to me, but please see my comment from my review about documenting NormalizedPathNSStringFromJavaString() API.

I see it. I will copy what you wrote in there.

Copy link
Contributor Author

@prrace prrace Feb 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read it and not sure that it is fine to ignore this error, why not throw an exception and signal the CTextPipe_doDrawString that an error occurred like InvalidPipeException or something(Sometimes we wrap other exception like OOM into the InvalidPipeException and this seems similar case)?

OK. I will do something like throw OOME or InternalError. Since we already checked for NULL as an arg any failure here implies a deep VM problem rather than anytjhing like a 2D invalid pipe

*/
static NSNumber* JavaNumberToNSNumber(JNIEnv *env, jobject jnumber) {
if (jnumber == NULL) {
return nil;
Copy link
Member

@mrserb mrserb Feb 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on its usage it is probably should be zero on NULL number?

Copy link
Contributor Author

@prrace prrace Feb 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not an unreasonable idea and I considered it but :

  • It is never called with NULL. There is always a null check
  • The JNF equivalent returns nil on NULL

BTW two of the functions in which the code appears : accessibilityMinValueAttribute and accessibilityMaxValueAttribute (SFAIC) aren't used anywhere.

Copy link
Member

@mrserb mrserb Feb 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@azuev-java Looks like a cleanup opportunity?


NSString* JavaStringToNSString(JNIEnv *env, jstring jstr) {
if (jstr == NULL) {
return NULL;
Copy link
Member

@mrserb mrserb Feb 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other methods, the nil is used

Copy link
Contributor Author

@prrace prrace Feb 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not understanding what you mean ? This is the same behavior as the function being replaced.

@@ -49,6 +50,15 @@ static inline void attachCurrentThread(void** env) {

@implementation ThreadUtilities

+ (void)initialize {
Copy link
Member

@mrserb mrserb Feb 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to check how this new modes will work when the AWT is embedded inside SWT and FX.

Copy link
Contributor Author

@prrace prrace Feb 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are just specifying an additional run mode for JDK internal use.
It means that when we are saying to process only events for that mode, then only those will be processed.
And it is used only for nested event loops.
Nothing eternal should be assuming AWT uses JNF at all, never mind in a particular way.

There is a special case for FX but I don't see a problem.

If you look at Java_sun_lwawt_macosx_LWCToolkit_doAWTRunLoopImpl
there's a variable "inAWT".
isRunning = [[NSRunLoop currentRunLoop] runMode:(inAWT ? [JNFRunLoop javaRunLoopMode] : NSDefaultRunLoopMode) ... ]];

This is specified as
inAWT = AccessController.doPrivileged(new PrivilegedAction() {
@OverRide
public Boolean run() {
return !Boolean.parseBoolean(System.getProperty("javafx.embed.singleThread", "false"));
}
});
}

So generally FX doesn't care, and is ignorant of this new mode.
Unless you set that property to true, in which case AWT use the NSDefaultRunLoopMode and so again FX is unaffected.
Nothing in the FX sources goes anywhere near JNF .. or has a reference to the special mode.

Bottom line I don't see it being affected.

I'll check with Kevin but also Gerard had a lot to do with the creation of the current FX toolkit.

Copy link
Member

@kevinrushforth kevinrushforth Feb 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ran some tests embedding JavaFX into Swing and vice versa both with and without -Djavafx.embed.singleThread=true and I don't see any regression in behavior.

Copy link
Member

@mrserb mrserb Feb 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am mostly worried about the usage of JNF by someone else's native code, as far as I understand it could be "broken" now. But it is good that FX does not use it.

BTW looks like all comments like "// AWT_THREADING Safe (AWTRunLoop)" could be removed now.

Copy link
Contributor Author

@prrace prrace Feb 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SWT does not use JNF at all. I've looked at their source code.
I can clean up those comments.

@mlbridge
Copy link

mlbridge bot commented Feb 2, 2021

Mailing list message from Magnus Ihse Bursie on build-dev:

On 2021-01-29 17:41, Phil Race wrote:

But we can just remove it and prove it - but probably a separate PR since it is nothing to do with the desktop module and the autoconf code needs to be updated once everything else is in.

Fair enough. Do you have a JBS issue tracking the remaining build system
fixes for the JNF removal? I looked around but could not find one.

/Magnus

@mlbridge
Copy link

mlbridge bot commented Feb 2, 2021

Mailing list message from Philip Race on build-dev:

Per my comment in the PR I am currently working on updating it to handle
the test update needed.

Once the other in-flight PRs are integrated, my grepping says that the
only remaining build change

needed after that is to remove one disabled warning in
make/autoconf/flags-cflags.m4

I am going to try to find out if we can remove that now or have to wait
until all JNF is removed.

FWIW it looks like you added it here :
http://hg.openjdk.java.net/jdk/jdk/rev/ec62d6cab037

If we can roll this into an existing PR that might be easier. If it
needs to wait for all of them, then we'll play it by ear as to whether
to add it fo the last man standing or file a new bug.

-phil

On 2/1/21 3:33 AM, Magnus Ihse Bursie wrote:

On 2021-01-29 17:41, Phil Race wrote:

But we can just remove it and prove it - but probably a separate PR
since it is nothing to do with the desktop module and the autoconf
code needs to be updated once everything else is in.
Fair enough. Do you have a JBS issue tracking the remaining build
system fixes for the JNF removal? I looked around but could not find one.

/Magnus

@mlbridge
Copy link

mlbridge bot commented Feb 2, 2021

Mailing list message from Philip Race on build-dev:

I can confirm that the autoconf warning disabling is currently still
needed when building with our standard devkit.

It'll have to be removed at the very end.

In file included from ./open/src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m:27:
....
.....

/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework/Headers/JNFJNI.h:30:
/System/Volumes/Data/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-macosx_x64/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework/Headers/JNFException.h:49:1:
error: method has no return type specified; defaults to 'id'
[-Werror,-Wmissing-method-return-type]
?- init:(JNIEnv *)env throwable:(jthrowable)throwable;
?^
? (id)
/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework/Headers/JNFException.h:50:1:
error: method has no return type specified; defaults to 'id'
[-Werror,-Wmissing-method-return-type]
?- init:(JNIEnv *)env as:(const char *)javaExceptionType reason:(const
char *)reasonMsg;
?^

-phil.

On 2/1/21 8:02 AM, Philip Race wrote:

Per my comment in the PR I am currently working on updating it to
handle the test update needed.

Once the other in-flight PRs are integrated, my grepping says that the
only remaining build change

needed after that is to remove one disabled warning in
make/autoconf/flags-cflags.m4

I am going to try to find out if we can remove that now or have to
wait until all JNF is removed.

FWIW it looks like you added it here :
http://hg.openjdk.java.net/jdk/jdk/rev/ec62d6cab037

If we can roll this into an existing PR that might be easier. If it
needs to wait for all of them, then we'll play it by ear as to whether
to add it fo the last man standing or file a new bug.

-phil

On 2/1/21 3:33 AM, Magnus Ihse Bursie wrote:

On 2021-01-29 17:41, Phil Race wrote:

But we can just remove it and prove it - but probably a separate PR
since it is nothing to do with the desktop module and the autoconf
code needs to be updated once everything else is in.
Fair enough. Do you have a JBS issue tracking the remaining build
system fixes for the JNF removal? I looked around but could not find
one.

/Magnus

@kevinrushforth
Copy link
Member

kevinrushforth commented Feb 2, 2021

The following commit was integrated to jdk master since you created this branch:

acbcde8 : JDK-8256111 : Create implementation for NSAccessibilityStaticText protocol

with a new reference to JNF, so it fails to compile with this patch. You will need to merge openjdk/jdk master into your PR branch and then fix the new JNF reference.

@openjdk openjdk bot removed the ready label Feb 2, 2021
@openjdk openjdk bot removed the rfr label Feb 2, 2021
@prrace
Copy link
Contributor Author

prrace commented Feb 2, 2021

Updated as follows

  • merged to current master and fixed the new A11Y usage of JNF
  • added comment provided by Gerard
  • removed comments as suggested by Sergey
  • made failure of GetStringChars in CTextPipe throw OOME

@openjdk openjdk bot added ready rfr labels Feb 2, 2021
mrserb
mrserb approved these changes Feb 4, 2021
@prrace
Copy link
Contributor Author

prrace commented Feb 4, 2021

/integrate

@openjdk openjdk bot closed this Feb 4, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Feb 4, 2021
@openjdk
Copy link

openjdk bot commented Feb 4, 2021

@prrace Pushed as commit 8760688.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@prrace prrace deleted the jnf_string branch Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2d awt build integrated
5 participants