java.awt.FileDialog does not work properly bundled but not sandboxed app
Hey, I'm under the impression that the java.awt.FileDialog in mode FileDialog.LOAD does not work properly when invoked from an app bundle. As in: It always assumes a sandbox and does not give me access to all files anymore. It does not matter, if the bundle was signed or not. The bundle was created with https://bitbucket.org/infinitekind/appbundler Note that AppBundler passes in a system property -DSandboxEnabled=true, if it finds *any* Containers folder. Meaning, it's only an indication for whether sandboxing is possible at all, *not* whether this particular app is sandboxed. There is no problem, when launching the same app via the regular java launcher. Does anybody else have this problem? Cheers, -hendrik
HiDPI Scaling - OSX vs Windows
Hey Guys, about half a year ago I filed https://bugs.openjdk.java.net/browse/JDK-8029087, stating basically that the HiDPI logic on Windows and on OS X is fundamentally different and therefore WORA is violated (don't know what the Linux situation is). I was wondering whether anybody at Oracle discusses this and what your conclusions are? Or is this being ignored as not important enough? I'm writing mainly, because a hint in which direction this will go, will help me to write my code accordingly. I would hate having to re-code all retina related stuff with extra workarounds for Windows... Thanks, -hendrik
Re: [9] Review request for 8040291 [macosx] Http-Images are not fully loaded when using ImageIcon
Hi, Alexander. The fix looks good. On 5/21/14 6:00 PM, Petr Pchelko wrote: Hello, Alexander. The fix looks good. With best regards. Petr. On 21 мая 2014 г., at 17:47, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8040291/webrev.03/ - The test checks that the resolution-variant observer is called at least once. Thanks, Alexandr. On 5/21/2014 2:50 PM, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8040291/webrev.02/ - The isRVObserevr typo is fixed On 5/20/2014 7:32 PM, Petr Pchelko wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8040291/webrev.01 - The getRVSize() method from the SunToolkit is fixed Thank you for the update, but I still have questions about the test: 1. There’s a typo in isRVObserevr. 2. Do we need the isRVObserevr method? How could it be that this method return false in this test and it’s a correct behavior and not a bug? I see it’s only possible from SunToolkit.prepareImage if bits are ERROR | ABORT. Couldn’t we get rid of this method? Walking up the stack doesn’t look like the most reliable solution.. The ImageObserver is used for two purposes in the Toolkit prepareImage() method: - to query which part of the image should be loaded - to notify an object about which image information is available To prepare a multi-resolution image it needs to prepare its resolution variant as well. The only way to know which part of the resolution variant should be loaded is requesting the base image observer. It leads that there will be a notification for the object that contains the resolution variant instead of the base image. To improve it the MultiResolutionToolkitImage wraps the base image observer for the resolution variant. The object gets notification which contains only the base image and updated sizes after that. The another case which is fixed in this issue is that the resolution variant can be loaded first and it notifies the object that the image is loaded. The fix reduces the resolution variant info flags so the object should wait for image loading notification from the base image. The test needs to check that the wrapped observer from the resolution variant does not send more info than the original image has already had. The isRVObserver() just checks that the observer is called from the resolution variant and not is from the base image. Thanks, Alexandr. With best regards. Petr. On May 20, 2014, at 7:07 PM, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8040291/webrev.01 - The getRVSize() method from the SunToolkit is fixed On 5/20/2014 6:46 PM, Petr Pchelko wrote: Hello, Alexander. SunToolkit:876 size == -1 ? -1 : size What’s going on here? Isn’t this equal to just size? I believe is’t wrong and the size should be multiplied by 2 somewhere? If the method is wrong how does the test pass? The test passes because it uses SunToolkit.prepareImage() method with the -1 size. It also uses the image observer that requires to load all image bits. Thanks, Alexandr. With best regards. Petr. On May 20, 2014, at 6:32 PM, Alexander Scherbatiy wrote: Hello, Could you look at the fix? Thanks, Alexandr. On 4/30/2014 6:34 PM, Alexander Scherbatiy wrote: Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8040291 webrev: http://cr.openjdk.java.net/~alexsch/8040291/webrev.00 The SunToolkit.prepareResolutionVariant() method wraps the base image observer and passes it to the resolution variant. It leads that the resolution variant notifies the base image about info changing. When the base image is loaded by the MediaTracker and the resolution variant is loaded first it calls the base image observer and wrongly finishes the base image loading. The fix passes the reduced resolution variant info flags to the base image so the base image loading is finished only after notifiing by the original base image observer. Thanks, Alexandr. -- Best regards, Sergey.
Re: HiDPI/Retina support for -splash option
On Fri, May 23, 2014 at 12:32 PM, Paul Taylor wrote: > On 22/05/2014 20:05, Hendrik Schreiber wrote: >> >> Hi, >> >> I'm under the impression that the VM option -splash does not honor the @2x >> notation for HiDPI images. >> Am I missing something, is that being worked on, or is there a bug report >> for this (I couldn't find one)? >> >> It's a little disappointing when you spend so much time on getting Retina >> right and then you realize that the very first impression the user gets when >> starting your app is a bad one, i.e. a blurry splash screen. >> >> Thanks! >> >> -hendrik > > But isnt there a much larger problem, the -splash option still broken only > to be fixed in https://bugs.openjdk.java.net/browse/JDK-8024185. To clarify > using the splash option will prevent my main application from working. Same here. -- Robert Krüger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com
Re: HiDPI/Retina support for -splash option
On 23/05/2014 11:38, Petr Pchelko wrote: But isnt there a much larger problem, the -splash option still broken only to be fixed in https://bugs.openjdk.java.net/browse/JDK-8024185. To clarify using the splash option will prevent my main application from working. This fix was integrated in JDK-9 long time ago and didn’t cause any regressions. I think it is safe to back port this to jdk8u20 which I will do right now. With best regards. Petr. Okay, great thanks.
Re: HiDPI/Retina support for -splash option
On May 23, 2014, at 12:32, Paul Taylor wrote: > On 22/05/2014 20:05, Hendrik Schreiber wrote: >> Hi, >> >> I'm under the impression that the VM option -splash does not honor the @2x >> notation for HiDPI images. >> Am I missing something, is that being worked on, or is there a bug report >> for this (I couldn't find one)? >> >> It's a little disappointing when you spend so much time on getting Retina >> right and then you realize that the very first impression the user gets when >> starting your app is a bad one, i.e. a blurry splash screen. >> >> Thanks! >> >> -hendrik > But isnt there a much larger problem, the -splash option still broken only > to be fixed in https://bugs.openjdk.java.net/browse/JDK-8024185. To clarify > using the splash option will prevent my main application from working. The bug is marked as "Fixed" for 9. Do you still see this problem in 8u20? And if it is only fixed for 9, will it be backported to 8u20? Thanks, -hendrik
Re: HiDPI/Retina support for -splash option
> But isnt there a much larger problem, the -splash option still broken only > to be fixed in https://bugs.openjdk.java.net/browse/JDK-8024185. To clarify > using the splash option will prevent my main application from working. This fix was integrated in JDK-9 long time ago and didn’t cause any regressions. I think it is safe to back port this to jdk8u20 which I will do right now. With best regards. Petr. On May 23, 2014, at 2:32 PM, Paul Taylor wrote: > On 22/05/2014 20:05, Hendrik Schreiber wrote: >> Hi, >> >> I'm under the impression that the VM option -splash does not honor the @2x >> notation for HiDPI images. >> Am I missing something, is that being worked on, or is there a bug report >> for this (I couldn't find one)? >> >> It's a little disappointing when you spend so much time on getting Retina >> right and then you realize that the very first impression the user gets when >> starting your app is a bad one, i.e. a blurry splash screen. >> >> Thanks! >> >> -hendrik > But isnt there a much larger problem, the -splash option still broken only > to be fixed in https://bugs.openjdk.java.net/browse/JDK-8024185. To clarify > using the splash option will prevent my main application from working. > > Paul
Re: HiDPI/Retina support for -splash option
On 22/05/2014 20:05, Hendrik Schreiber wrote: Hi, I'm under the impression that the VM option -splash does not honor the @2x notation for HiDPI images. Am I missing something, is that being worked on, or is there a bug report for this (I couldn't find one)? It's a little disappointing when you spend so much time on getting Retina right and then you realize that the very first impression the user gets when starting your app is a bad one, i.e. a blurry splash screen. Thanks! -hendrik But isnt there a much larger problem, the -splash option still broken only to be fixed in https://bugs.openjdk.java.net/browse/JDK-8024185. To clarify using the splash option will prevent my main application from working. Paul
Re: HiDPI/Retina support for -splash option
On May 22, 2014, at 21:16, Sergey Bylokhov wrote: > I think it was overlooked. Please file a new bug at > http://bugreport.sun.com/bugreport , don't forget to add a steps to reproduce > your issue. > Thanks for report! Filed the report. The Oracle review id is: JI-9012489 Cheers, -hendrik
