No worries, thanks!
-DrD-
> Sorry for the delay, looks good.
>
> Kumar
>
>> Please review the (fairly straightforward) JDK changes needed to support
>> launching JavaFX applications in a named module.
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8169289
>>
>> Webrev:
>> http://cr.
>> Please review the (fairly straightforward) JDK changes needed to support
>> launching JavaFX applications in a named module.
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8169289
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/
>>>
> On Nov 15, 2016, at 4:21 PM, Mandy Chung wrote:
>
>
>> On Nov 15, 2016, at 4:04 PM, David DeHaven wrote:
>>
>>
>>>>> Please review the (fairly straightforward) JDK changes needed to support
>>>>> launching JavaFX appl
>>> Please review the (fairly straightforward) JDK changes needed to support
>>> launching JavaFX applications in a named module.
>>>
>>> JBS:
>>> https://bugs.openjdk.java.net/browse/JDK-8169289
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/
>>>
>>>
>>
>> Would it b
>> Please review the (fairly straightforward) JDK changes needed to support
>> launching JavaFX applications in a named module.
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8169289
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/
>>
>>
>
> Would it be better to
Ping? Kumar?
-DrD-
> On Nov 10, 2016, at 9:38 AM, David DeHaven wrote:
>
>
> Please review the (fairly straightforward) JDK changes needed to support
> launching JavaFX applications in a named module.
>
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-816
Please review the (fairly straightforward) JDK changes needed to support
launching JavaFX applications in a named module.
JBS:
https://bugs.openjdk.java.net/browse/JDK-8169289
Webrev:
http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/
For reference, here are the openjfx changes needed:
http
> JLI_Launch is an *internal* entry point, this is primarily used in main.c,
>> and this is called by JDK's tool launchers which sets
>> "NEVER_ACT_AS_SERVER",
>> also this entry point is used by the java packager and deployment, I
>> have cc'ed
>> C
>> Please review the new patch version:
>> http://cr.openjdk.java.net/~ddehaven/8165271/jdk.1/
>>
>
> Looks okay but I think the new interface should be named
> “JavaNetURLClassLoaderAccess” (matching “URLClassLoader")
I originally had that but changed it to look more consistent with the other
On Oct 13, 2016, at 5:24 PM, Mandy Chung wrote:
>
>
>> On Oct 13, 2016, at 4:08 PM, David DeHaven wrote:
>>
>>
>> JBS Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8165271
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ddehaven/8165271/j
JBS Issue:
https://bugs.openjdk.java.net/browse/JDK-8165271
Webrev:
http://cr.openjdk.java.net/~ddehaven/8165271/jdk.0/
Synopsis:
An upcoming change in the module system will prevent setAccessible calls from
working across module boundaries. This patch allows the use of SharedSecrets
instead t
Fix looks good to me too.
-DrD-
> On Jun 29, 2016, at 12:54 PM, Gerard Ziemski
> wrote:
>
> hi Brent,
>
> Thank you for fixing the original issue and for putting in this follow-up fix!
>
> Looks good! (for full disclosure I proposed the workaround)
>
>
> cheers
>
>> On Jun 29, 2016, at 2
Thanks, Sergey.
Can someone from the core-libs launcher group please approve? (looks at Kumar)
-DrD-
> Looks fine.
>
> On 22.06.16 1:58, David DeHaven wrote:
>>
>>> JBS:
>>> https://bugs.openjdk.java.net/browse/JDK-8022291
>>>
>>> Webrev:
&
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8022291
>
> Webrev:
> http://cr.openjdk.java.net/~ddehaven/8022291/jdk.0/index.html
>
> This actually turned out to be pretty easy to fix, I eliminated the
> JavaLaunchHelper class and in place of it stuffed the block it replaced into
> a NSBlo
JBS:
https://bugs.openjdk.java.net/browse/JDK-8022291
Webrev:
http://cr.openjdk.java.net/~ddehaven/8022291/jdk.0/index.html
This actually turned out to be pretty easy to fix, I eliminated the
JavaLaunchHelper class and in place of it stuffed the block it replaced into a
NSBlockOperation then c
>> The Java source was being built and included in rt.jar, but it would not run
>> because jdk/src/macosx/native/apple/launcher/JavaAppLauncher.m (implementing
>> the two native methods) was not being built so it would have died with an
>> UnsatisfiedLinkError. The Xcode project is not referenc
As the subject says, so examined and determined that it can indeed be removed.
The Java source was being built and included in rt.jar, but it would not run
because jdk/src/macosx/native/apple/launcher/JavaAppLauncher.m (implementing
the two native methods) was not being built so it would have d
> ...
>
>if (JAVAFX_FXHELPER_CLASS_NAME_SUFFIX.equals(mainClass.getName()) ||
>doesExtendFXApplication(mainClass)) {
>// Will abort() if there are problems with FX runtime
>FXHelper.setFXLaunchParameters(what, mode);
>return FXHelpe
Do we care about the 1 in more than 80 trillion case where the third party
Main-Class would be named "LauncherHelper$FXHelper"? I think the probability is
extremely unlikely so I'm fine with it the way it's written.
LauncherHelper.java:
590 return;
Redundant return statement?
-DrD-
>>> Done, new webrev is here:
>>
>> http://cr.openjdk.java.net/~bchristi/7199674/webrev.01/
>>
>>
>> On 9/6/13 4:09 PM, Mike Duigou wrote:
>>>
>>> I am surprised that strdup isn't needed for the constant "?" string
>>> but java_props_md.c seems to include other constant strings in sprops
>>> s
>> I don't know Cocoa memory management but from a quick look at the
>> NSAutoreleasePool docs then what you seems to be right. Folks on
>> macosx-port-dev would be better to comment on that.
>
> Perhaps Dave could comment?
The use of NSAutoreleasePool is fine in this case.
>> I see that creat
> So this clears up my questions about this patch. Thanks for helping me
> through it.
>
> Cheers,
> Nick
>
>
>
> On Thu, Sep 12, 2013 at 12:11 AM, David DeHaven
> wrote:
>
> >>> The bottom line is, if what you have now allows you to write to
> >
>>> The bottom line is, if what you have now allows you to write to
>>> ~/Documents and you're sandboxed then this change should not
>>> affect your application at all, except maybe in the UI if you're
>>> displaying that path to the user. The user won't notice the
>>> difference otherwise.
>>
>>
> In my app, I have an export dialog where the user can select the file to
> export as well as choose some other export options. In that dialog, after the
> user has selected the file to export (via the file selection dialog), I
> display the full path to the file that was returned from the fi
> I use user.home to do things like:
>
> String userHomePath = System.getProperty("user.home");
> myFileDialog.setDirectory(userHomePath + "/Documents");
This will continue to work fine. Like I said, user.home is the Data directory
inside the app container which is a shadow of the users home fo
ally
> being run sandboxed or not), but redefining user.home doesn't seem like the
> right solution. Having AppBundler (or even the JRE) provide that information
> via special properties feels better from my developer's perspective.
>
> Nick
>
>
>
> On Fri,
> This isn't every other platform, this is Mac OS X and all the baggage that
> goes along with it! :)
>
> What do you actually need access to user.home for? Do you have empirical
> evidence that this will break your application?
>
> The whole point of sandboxing is you no longer have direct ac
>> As someone with a Java app in the Mac App Store (MAS), I would like to vote
>> against this change.
>>
>> It is still important to know the user's actual home directory
>> (/Users/) even if the app is running in the sandbox. Using the
>> entitlement, com.apple.security.files.user-selected.
I was about to chime in that UTF-8 has been the preferred encoding for (stored)
text on Mac OS X as long as I've been hacking on it (think "Rhapsody"), so why
is this even an issue?
Judging from the docs, nl_langinfo seems like a Unix portability function
(something more likely to be happier w
> Please review my fix for 8011194 : "Apps launched via double-clicked .jars
> have file.encoding value of US-ASCII on Mac OS X"
>
> http://bugs.sun.com/view_bug.do?bug_id=8011194
>
> In most cases of launching a Java app on Mac (from the cmdline, or from a
> native .app bundle), reading and d
>> Specifically, I was referred to how C handles "%0.4f\n".
No width, decimal truncated (rounded? floored? I forgot which it is) to four
digits.
-DrD-
>>printf("%0.4f\n", 56789.456789F);
...
>> 56789.4570
> ^ ^ ^ ^ ^ ^ ^ ^
...
> "A leading zero in the width value is interpreted as the z
@Deprecated: never
-DrD-
> If we can't deprecate this, we might as well deprecate @Deprecated.
>
> On May 14, 2013, at 10:25 AM, Alan Bateman wrote:
>
>>
>> I would like to broach the subject of pulling out the implementation of
>> Thread.stop(Throwable), maybe suspend/resume later. By "pull
Those changes look fine to me. None of those typedefs make sense with JNIEXPORT
since they're only used locally, and most are scoped to a single function…
I agree with the __has_attribute comment.
The next step would be to try setting -fvisibility=hidden and
-fvisibility-inlines-hidden :) I e
>> Here's the latest version of the proposed patch:
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/JNIEXPORT/
>>
>> that has been tested, but only with gcc 4.6,
>> but is also written to work with llvm.
>
> This looks fine, however since 4.2.1
I meant 4.1.2…
-DrD-
> Here's the latest version of the proposed patch:
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/JNIEXPORT/
>
> that has been tested, but only with gcc 4.6,
> but is also written to work with llvm.
This looks fine, however since 4.2.1 is still used for some builds we need to
filter t
>> a) I don't know what's going on behind the scenes, but if this sounds
>> like a good idea to folks, can we open a bug and get the process
>> otherwise rolling?
>>
>> b) Martin, where did the 4.2 restriction come from? Both Apple's site
>> and the gcc wiki say that visibility support arrived i
> a) I don't know what's going on behind the scenes, but if this sounds like a
> good idea to folks, can we open a bug and get the process otherwise rolling?
>
> b) Martin, where did the 4.2 restriction come from? Both Apple's site and
> the gcc wiki say that visibility support arrived in 4.0:
+#if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) &&
(__GNUC_MINOR__ > 2)
+ #define JNIEXPORT __attribute__((visibility("default")))
+ #define JNIIMPORT __attribute__((visibility("default")))
>>>
>>> The default compiler in Xcode 4.1 is llvm-gcc 4.2, it see
> This seems like an obvious improvement.
> There are already bunches of places in the jdk sources that do things like:
>
> ./hotspot/src/cpu/x86/vm/jni_x86.h
> #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE)
>
> #if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) &&
> (
>> +#if defined(__GNUC__) && (__GNUC__ > 4) || (__GNUC__ == 4) &&
>> (__GNUC_MINOR__ > 2)
>> + #define JNIEXPORT __attribute__((visibility("default")))
>> + #define JNIIMPORT __attribute__((visibility("default")))
>
> The default compiler in Xcode 4.1 is llvm-gcc 4.2, it seems. The con
>>> It's a Windows feature. We discovered this recently in debugging another
>>> test failure. Windows is documented to do asynchronous deletes. You can't
>>> depend on a file.delete() which returns true to have actually deleted the
>>> file. It may be the case that another process has a file
>>> Cmd line FAC LAUNCH_MODE
>>> JAVAFX_LAUNCH_MODE
>>> java -jar fxapp.jarPresent LM_JAR LM_JAR
>>> java -jar fxapp.jarNot present LM_JAR [LM_JAR]
>>> java -cp fxapp.jar ... Not present LM_CLASS
> Cmd line FAC LAUNCH_MODE JAVAFX_LAUNCH_MODE
> java -jar fxapp.jarPresent LM_JAR LM_JAR
> java -jar fxapp.jarNot present LM_JAR [LM_JAR]
> java -cp fxapp.jar ... Not present LM_CLASSLM_CLASS
[pardon the data shuffle…]
Cmd line FAC LAUNCH_MODE JAVAFX_LAUNCH_MODE
java -jar fxapp.jarPresent LM_JAR LM_JAR
java -jar fxapp.jarNot present LM_JAR [LM_JAR]
java -cp fxapp.jar ... Not present LM_CLASS
[adding core-libs-dev back in.. not sure how that got lost]
> [Back from vacation, let's get the ball rolling again… :]
>
>> In order to understand and explain here is a truth table:
>>
>> Cmd line FAC LAUNCH_MODE JAVAFX_LAUNCH_MODE
>> java -jar fxapp.jarPr
> I need more coffee this morning :-)
I have that problem often :)
>> In the absence of JavaFX-Application-Class, canLaunchFXAppJar simply returns
>> false. It does not load the FX launcher on failure or it would be doing so
>> for non-FX jars which would cause testExtraneousJars to fail.
>>
> David,
>
> It looks great here are few items I noticed:
> 1. The error defined by:
>
> +java.launcher.javafx.error1=\
> +Error: The JavaFX runtime is incompatible with the Java launcher
>
> is used for a signature mismatch, I suggest changing the
> message to reflect the real reason.
How
Request for review for extending the launcher support to allow the JavaFX
runtime to fully support all of it's launch features, including
preloaders, classpath, etc..
>> >> Webrev:
>> http://cr.openjdk.java.net/~ddehaven/8004547/webrev.1/
>>> > > FXHelper.canLaunche
>> Request for review for extending the launcher support to allow the JavaFX
>> runtime to fully support all of it's launch features, including preloaders,
>> classpath, etc..
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ddehaven/8004547/webrev.1/
>
> FXHelper.canLauncherFXAppJar launches a JA
Request for review for extending the launcher support to allow the JavaFX
runtime to fully support all of it's launch features, including preloaders,
classpath, etc..
Webrev:
http://cr.openjdk.java.net/~ddehaven/8004547/webrev.1/
Corresponding JavaFX JIRA issue that these changes depend on:
ht
Hopefully final webrev for this change:
http://cr.openjdk.java.net/~ddehaven/8004042/webrev.3/
I moved the createBatFile method to TestHelper as I thought it could be useful
to other tests and added more diagnostic info.
It turns out the culprit on my machine was Windows' "Application Experienc
(There's another issue which is that if there were previous retries, the
ADEs from them are thrown away. But maybe we should save that one for
another day.)
>>>
>>> I had the same thought, but aside from collecting and reporting all of them
>>> somehow I'm not sure what could be
>>> (There's another issue which is that if there were previous retries, the
>>> ADEs from them are thrown away. But maybe we should save that one for
>>> another day.)
>>
>> I had the same thought, but aside from collecting and reporting all of them
>> somehow I'm not sure what could be done
> OK, looks pretty good. But
>
> One little thing is still bothering me. Suppose we get interrupted from the
> sleep() and bail out on that basis. If we got to the point where we're
> sleeping, we must have caught an AccessDeniedException previously.
> Unfortunately this exception is disca
New webrev posted:
http://cr.openjdk.java.net/~ddehaven/8004042/webrev.2/
Summary:
- Cleaned it up a bit by change to a for loop (eliminating done flag)
- Throws RuntimeException instead of IOException, handles InterruptedException
- Bumped retry count to 10
- Changed @run mode to "main/othervm"
>> A fix for intermittent test failures causing grief on Windows, particularly
>> Windows 7 and 2008 systems:
>> http://cr.openjdk.java.net/~ddehaven/8004042/webrev.1/
>>
>> The underlying cause is as of yet unknown, but I was able to create an
>> environment that caused similar failures by run
A fix for intermittent test failures causing grief on Windows, particularly
Windows 7 and 2008 systems:
http://cr.openjdk.java.net/~ddehaven/8004042/webrev.1/
The underlying cause is as of yet unknown, but I was able to create an
environment that caused similar failures by running "watch -n 0.2
>>> If Main-Class is always present with JavaFX-Application-Class, it may be no
>>> impact; but this seems to be unclear at this moment. Kevin can chime in
>>> here and looks like this requires more investigation before we continue the
>>> code review.
>> I've read the other mails and I see th
>> If Main-Class is always present with JavaFX-Application-Class, it may be no
>> impact; but this seems to be unclear at this moment. Kevin can chime in
>> here and looks like this requires more investigation before we continue the
>> code review.
> I've read the other mails and I see that th
>> I cleaned it up quite a bit, I think it looks a lot better now:
>> http://cr.openjdk.java.net/~ddehaven/8001533/webrev.1/
>>
>> The comments still need some attention, I'll get that first thing on the
>> morrow.
>>
>> -DrD-
>>
> I haven't done a detailed code review but I'm wondering about
>>> L496-517 somewhat duplicates the logic added for FX in the
>>> getMainClassFromJar method. Have you considered some refactoring
>>> work you could do to simplify the fix since I think once you get
>>> the classname of the entry point (either from a JAR or command-line
>>> and with a
> java.c: L427 it would be helpful to add a comment to explain
>the case where appClass is different than mainClass.
>Probably the comment above L425 should be updated to
>reflect the support for JavaFX
Done.
>L428-430: is this fallback needed? Would it be better
>if Launch
Why not just use CFLocale and call CFLocaleCopyCurrent?
https://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFLocaleRef/Reference/reference.html#//apple_ref/c/func/CFLocaleCopyCurrent
-DrD-
> As to the default locale detection, we need to call JavaRuntimeSupport.
>
Bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001533
Webrev:
http://cr.openjdk.java.net/~ddehaven/8001533/webrev.0/
This change adds support in the Java launcher to launch JavaFX applications
directly (without the aid of launcher code injected by javafxpackager). This is
accomplishe
64 matches
Mail list logo
