Re: java.lang.NoSuchMethodError: createImageUsingNativeSize error in 1.8.0_45
On 23/07/2015 12:46, Alexander Scherbatiy wrote: It looks like known issue JDK-8077016 [macosx] Image transfer through System Clipboard is broken in 1.8.0_40 on Mac OS X https://bugs.openjdk.java.net/browse/JDK-8077016 and it fails this test https://bugs.openjdk.java.net/browse/JDK-8037371 so begs the question how did it get released in the first place !
Re: java.lang.NoSuchMethodError: createImageUsingNativeSize error in 1.8.0_45
On 23/07/2015 11:19, Paul Taylor wrote:
This code that was used in some circumstances for dealing with single
images dragged and drop from certain webbrowsers (firefox) gave no
issues in 1.8.0_25
image = (Image)
trans.getTransferData("image/x-java-image;class=java.awt.Image");
but now in 1.8.0_45 causing
java.lang.NoSuchMethodError: createImageUsingNativeSize
at sun.lwawt.macosx.CDataTransferer.getImageForByteStream(Native Method)
at
sun.lwawt.macosx.CDataTransferer.platformImageBytesToImage(CDataTransferer.java:238)
at
sun.awt.datatransfer.DataTransferer.translateBytes(DataTransferer.java:1659)
at
sun.lwawt.macosx.CDataTransferer.translateBytes(CDataTransferer.java:142)
at
sun.awt.dnd.SunDropTargetContextPeer.getTransferData(SunDropTargetContextPeer.java:269)
at
sun.awt.datatransfer.TransferableProxy.getTransferData(TransferableProxy.java:73)
at
java.awt.dnd.DropTargetContext$TransferableProxy.getTransferData(DropTargetContext.java:376)
at
com.jthink.jaikoz.draganddrop.ImageHandler.createImageCell(ImageHandler.java:30)
Is this a bug in the new version of OSX Java or am I simply doing
something wrong, is there a simple workaround ?
Paul
It seems to be
https://bugs.openjdk.java.net/browse/JDK-8077016?page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#issue-tabs
but breaking use of the clipboard for copy and pate of images is a
massive bug dont you think, surely this should be a priority 1 bug as we
are not talking about some obscure functionality here ?
Paul
java.lang.NoSuchMethodError: createImageUsingNativeSize error in 1.8.0_45
This code that was used in some circumstances for dealing with single
images dragged and drop from certain webbrowsers (firefox) gave no
issues in 1.8.0_25
image = (Image)
trans.getTransferData("image/x-java-image;class=java.awt.Image");
but now in 1.8.0_45 causing
java.lang.NoSuchMethodError: createImageUsingNativeSize
at sun.lwawt.macosx.CDataTransferer.getImageForByteStream(Native Method)
at
sun.lwawt.macosx.CDataTransferer.platformImageBytesToImage(CDataTransferer.java:238)
at
sun.awt.datatransfer.DataTransferer.translateBytes(DataTransferer.java:1659)
at sun.lwawt.macosx.CDataTransferer.translateBytes(CDataTransferer.java:142)
at
sun.awt.dnd.SunDropTargetContextPeer.getTransferData(SunDropTargetContextPeer.java:269)
at
sun.awt.datatransfer.TransferableProxy.getTransferData(TransferableProxy.java:73)
at
java.awt.dnd.DropTargetContext$TransferableProxy.getTransferData(DropTargetContext.java:376)
at
com.jthink.jaikoz.draganddrop.ImageHandler.createImageCell(ImageHandler.java:30)
Is this a bug in the new version of OSX Java or am I simply doing
something wrong, is there a simple workaround ?
Paul
Re: Swing Look And Feel for Yosemite
On 11/11/2014 02:02, Phil Race wrote: On 11/10/14 9:45 AM, David DeHaven wrote: We still use it for the occasional generic "Java 7/8/9 on Mac" question that comes up from time to time. It is far preferable that the question be posted to the more specific lists, but sometimes it isn't clear where that belongs. There's enough of us monitoring the list that we can provide guidance on where to go but not enough that it should be used for all Mac specific question And, some Apple folks might be still peeking at this list in their free time and chime in with useful information. But they are very unlikely to be reading the swing list. Yep Just don't take that as meaning all mac questions go here first. After all we don't have a "windows port list" or an "ubuntu port list" ... No, but Apple a special case there is alot more divergence between the OSX Gui, and the Windows/Linux guis. And Apple seems much more likely to making changes in its new OS versions that scupper us java devs. Paul
Re: Swing Look And Feel for Yosemite
On 10/11/2014 15:42, dalibor topic wrote: Hi, Since you're asking about Swing, it may be better to raise this on the swing-dev mailing list. cheers, dalibor topic I dont see why as the issue is very much specific to OSX Paul
Re: OSX failing to get a url for image even though it is a supported dataflavour for the transferable
On 22/09/2014 14:03, Scott Palmer wrote: The XML has an array of two strings. Are you sure you aren't getting the error from the second blank string? Scott Ah, good point BUT why would getTransferData() return an empty value, I dont see I have any control over that ? Paul
OSX failing to get a url for image even though it is a supported dataflavour for the transferable
Customer reporting this error when trying to copy and paste an image
from amazon, although we check the transferable object support a
particular dataflavor, it fails when try and use that data flavour to
get a url. Ive not seen this error before and recently moved to Java
1.8.0_20 so I'm assuming the issues lies with Java 8 ?
java.net.MalformedURLException: no protocol: encoding="UTF-8"?>
"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
http://ecx.images-amazon.com/images/I/41NTPXC8EHL.jpg
at java.net.URL.(URL.java:586)
at java.net.URL.(URL.java:483)
at java.net.URL.(URL.java:432)
at
sun.lwawt.macosx.CDataTransferer.translateBytes(CDataTransferer.java:135)
at
sun.awt.datatransfer.ClipboardTransferable$DataFactory.getTransferData(ClipboardTransferable.java:71)
at
sun.awt.datatransfer.ClipboardTransferable.getTransferData(ClipboardTransferable.java:168)
Code Extract
public static DataFlavor imageUrlFlavor = new
DataFlavor("application/x-java-url;class=java.net.URL");
public void getImage(Transferable trans)
if(trans.isDataFlavorSupported(FileDropTarget.imageUrlFlavor))
{
imageUrl = (URL)
trans.getTransferData(FileDropTarget.imageUrlFlavor);
}
Re: What do we need to change to sign java appbundle since updating from 10.9.4 to 10.9.5
On 18/09/2014 20:22, Hendrik Schreiber wrote: On Sep 18, 2014, at 20:49, Paul Taylor wrote: On 18/09/2014 18:16, Danno Ferrin wrote: On the javapacakger (javafxpackager) side of the house we dodge this by not using the symlinked JLI. The JDK as it is installed installs a symlink to the libjli.dylib in ...app/Contents/MacOS is actually a symlink. I don't know if you copy it if it will still work, it may want to live in ...app/Contents/Home/jre/lib/jli/libjli.dylib. This is referenced in the default info.plist The way we dodge this for the javapackager is we create our own launch native that opens up the libjli from the location deep in the JRE. And we don't ship the symlink. I can confirm that javapackager 8u20 signs and launchers with 10.9.5, but I haven't tried to submit it to the app store since the signing requirements changes. So I don't know how you launch, but the info.plist cannot refer to the symlinked libjli.dylib if it is symlinked, and it may not even be allowed to exist as a symlink in ...app/Contents/MacOS. So if you can remove the symlink before signing that may help. Im using a fork of Java Application Bundler from InfiniteKind - https://bitbucket.org/infinitekind/appbundler -Im not deploying to the appstore its just uploaded to my website. So following your advice I found that libjli.dylib in Contents/PlugsIns/jdk1.8.0_20.jdk/Contents/MacOS pointed to ../Home/jre/lib/jli - replacing the symbolic link with a copy of the file has allowed the signing to work, and when installed the application stills seem to work, thankyou :) ' I assume if it doesn't work then you'll have a problem with javafxpackager applications as well. Any thoughts from dev team about removing this symbolic link in the jdk ? Perhaps AppBundler should simply not copy the MacOS folder. I don't see how it's needed when bundle the JRE as plugin and launch with the AppBundler stub. -hendrik Ive raised this issue on AppBundler https://bitbucket.org/infinitekind/appbundler/issue/1/appbundle-built-on-mac-osx-1095-cannot-be Paul
Re: What do we need to change to sign java appbundle since updating from 10.9.4 to 10.9.5
On 18/09/2014 18:16, Danno Ferrin wrote: On the javapacakger (javafxpackager) side of the house we dodge this by not using the symlinked JLI. The JDK as it is installed installs a symlink to the libjli.dylib in ...app/Contents/MacOS is actually a symlink. I don't know if you copy it if it will still work, it may want to live in ...app/Contents/Home/jre/lib/jli/libjli.dylib. This is referenced in the default info.plist The way we dodge this for the javapackager is we create our own launch native that opens up the libjli from the location deep in the JRE. And we don't ship the symlink. I can confirm that javapackager 8u20 signs and launchers with 10.9.5, but I haven't tried to submit it to the app store since the signing requirements changes. So I don't know how you launch, but the info.plist cannot refer to the symlinked libjli.dylib if it is symlinked, and it may not even be allowed to exist as a symlink in ...app/Contents/MacOS. So if you can remove the symlink before signing that may help. Im using a fork of Java Application Bundler from InfiniteKind - https://bitbucket.org/infinitekind/appbundler -Im not deploying to the appstore its just uploaded to my website. So following your advice I found that libjli.dylib in Contents/PlugsIns/jdk1.8.0_20.jdk/Contents/MacOS pointed to ../Home/jre/lib/jli - replacing the symbolic link with a copy of the file has allowed the signing to work, and when installed the application stills seem to work, thankyou :) ' I assume if it doesn't work then you'll have a problem with javafxpackager applications as well. Any thoughts from dev team about removing this symbolic link in the jdk ? Paul
What do we need to change to sign java appbundle since updating from 10.9.4 to 10.9.5
Can somebody help me with this please I just updated from OSX 10.9.4 to 10.9.5, and it looks like I have to change how I sign Java application after updating because Im now getting this output after signing with export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate" /usr/bin/codesign --sign "Developer ID Application: P Taylor" --force --deep --verbose /Applications/SongKong.app Im getting: /Applications/SongKong.app: the main executable or Info.plist must be a regular file (no symlinks, etc.) In subcomponent: /Applications/SongKong.app/Contents/PlugIns/jdk1.8.0_20.jdk and verification with /usr/bin/codesign --verify --deep --verbose /Applications/SongKong.app gives me /Applications/SongKong.app: code object is not signed at all In architecture: x86_64 What do I have to change to fix this ? Paul
Re: java.awt.FileDialog does not work properly bundled but not sandboxed app
On 29/05/2014 11:27, Robert Krüger wrote: Hi, I am not really sure I understand your posting correctly. Are you saying that your impression is that java.awt.FileDialog in mode FileDialog.LOAD does not work properly in an app bundle, regardless of sandboxing? If that is so, then I can confirm that this is not the case. You are not by any chance starting the app with a splash screen with -splash? If so that is likely to be the reason for your problems as java.awt.FileDialog is completely broken then (see https://bugs.openjdk.java.net/browse/JDK-8009203, https://bugs.openjdk.java.net/browse/JDK-8006420). If I understand the feedback of an Oracle dev a few days ago on this list correctly, this is fixed in J9 and will be backported for the next J8 update. We even implemented our own splash screen because of this. Cheers, Robert +1 this is what I was saying about splashscreen completely screwing up a gui application. Using Appbundler and without splash screen I use java.awt.FIleDialog fine ( see http://jthink.net/songkong, and select File/Open Folder ) Paul
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 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: Unable to get Applescript Engine on some computers
On 27/02/2014 11:07, Michael Hall wrote:
On Feb 27, 2014, at 4:52 AM, Paul Taylor wrote:
In my code I have:
ScriptEngineManager mgr = new ScriptEngineManager();
ScriptEngine engine = mgr.getEngineByName("AppleScript");
this works fine for me, but for some customers in returns null for engine.
We are using Java 1.8.0 25.0-b69 64bit (build 129)
Customer was on Mac OS X 10.9.2 x86_64, I've upgraded to same version still
don't get the problem.
Applescript does exist because earlier in my code I run some applescript using
osascript and Runtime class and that works fine
l don't know that it was precisely determined what caused this. Possibly some
change in an OS upgrade where Apple removed something from their java
distribution?
Although we didn't know it, we were relying on the Apple code being in place.
Your three options would be…
1)
Provide the code in the jar and dylib yourself. This is what I did and what I
made available on github at…
https://github.com/mik3hall/AppleScriptEngine
All you really need are the jar and dylib.
Put the dylib in the application's MacOSX folder. appbundler adds that to
LD_LIBRARY_PATH.
Put the jar in the application's Java folder, this should get it into class
path.
Done and should work on any configuration.
FYI I tried this, and it worked !
Brilliant thanks solved a big problem for me
Paul
Re: Unable to get Applescript Engine on some computers
On 27/02/2014 13:17, Alan Bateman wrote: On 27/02/2014 13:11, Paul Taylor wrote: : I wanted to replicate the issue before fixing so I renamed /System/Library/Java/Extensions/AppleScriptEngine.jar and libAppleScriptEngine.jniLib but it stills works. I searched the whole hard disk and couldn't find any other copies What do I need to do to make it fail ? Is the renamed JAR file still in /System/Library/Java/Extensions? If so then move it where because that directory is used by the extensions mechanism (all JAR files in there are searched). -Alan. Ah yes, I renamed to .old file thinking that would do it, but moving it out completely does replicate the issue thanks Paul
Re: Unable to get Applescript Engine on some computers
On 27/02/2014 12:16, Paul Taylor wrote: On 27/02/2014 11:50, Andrew Thompson wrote: On Feb 27, 2014, at 6:10 AM, Alan Bateman wrote: The JDK does include the AppleScriptEngine but is missing the service configuration file that is needed to locate it. There is a bug open for this but it does raise the question as to whether the JDK really needs to bundle this scripting engine or not. I think the issue here is right now a lot of customers still have at least some fragments of Apple's Java 6 installed which makes this work. As more machines come to exist which have only ever had Java 7 or greater on them we'd see this issue more often, unless it is fixed. Right now I think this masking makes it impossible to estimate how widely used this engine is. This is a terrible slip up, I assume you do java builds on clean machine so I assume you don't have a single until test for checking talking to Applescript engine. I dread to think how many potential customers have tried my application and given up when it fails to update iTunes ( a key part on of the appilication for many OSX users), and Ive been unaware Paul I wanted to replicate the issue before fixing so I renamed /System/Library/Java/Extensions/AppleScriptEngine.jar and libAppleScriptEngine.jniLib but it stills works. I searched the whole hard disk and couldn't find any other copies What do I need to do to make it fail ? Paul
Re: Unable to get Applescript Engine on some computers
On 27/02/2014 11:50, Andrew Thompson wrote: On Feb 27, 2014, at 6:10 AM, Alan Bateman wrote: The JDK does include the AppleScriptEngine but is missing the service configuration file that is needed to locate it. There is a bug open for this but it does raise the question as to whether the JDK really needs to bundle this scripting engine or not. I think the issue here is right now a lot of customers still have at least some fragments of Apple's Java 6 installed which makes this work. As more machines come to exist which have only ever had Java 7 or greater on them we'd see this issue more often, unless it is fixed. Right now I think this masking makes it impossible to estimate how widely used this engine is. This is a terrible slip up, I assume you do java builds on clean machine so I assume you don't have a single until test for checking talking to Applescript engine. I dread to think how many potential customers have tried my application and given up when it fails to update iTunes ( a key part on of the appilication for many OSX users), and Ive been unaware Paul
Re: Unable to get Applescript Engine on some computers
On 27/02/2014 11:07, Michael Hall wrote:
On Feb 27, 2014, at 4:52 AM, Paul Taylor wrote:
In my code I have:
ScriptEngineManager mgr = new ScriptEngineManager();
ScriptEngine engine = mgr.getEngineByName("AppleScript");
this works fine for me, but for some customers in returns null for engine.
We are using Java 1.8.0 25.0-b69 64bit (build 129)
Customer was on Mac OS X 10.9.2 x86_64, I've upgraded to same version still
don't get the problem.
Applescript does exist because earlier in my code I run some applescript using
osascript and Runtime class and that works fine
l don't know that it was precisely determined what caused this. Possibly some
change in an OS upgrade where Apple removed something from their java
distribution?
Although we didn't know it, we were relying on the Apple code being in place.
Your three options would be…
1)
Provide the code in the jar and dylib yourself. This is what I did and what I
made available on github at…
https://github.com/mik3hall/AppleScriptEngine
All you really need are the jar and dylib.
Put the dylib in the application's MacOSX folder. appbundler adds that to
LD_LIBRARY_PATH.
Put the jar in the application's Java folder, this should get it into class
path.
Done and should work on any configuration.
2).
Fix the openjdk configuration error yourself. This means adding the
AppleScriptEngine entry to the config file in resources.jar. I believe the bug
report I gave earlier details how to do that.
3).
Wait for openjdk to correct the configuration file in resources.jar
My understanding on that one anyhow.
Michael Hall
trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe
AppConverter convert Apple jvm to openjdk apps
http://www195.pair.com/mik3hall/index.html#appconverter
Oh, sorry didnt notice those post, okay I'll try solution 1
Paul
Unable to get Applescript Engine on some computers
In my code I have:
ScriptEngineManager mgr = new ScriptEngineManager();
ScriptEngine engine = mgr.getEngineByName("AppleScript");
this works fine for me, but for some customers in returns null for engine.
We are using Java 1.8.0 25.0-b69 64bit (build 129)
Customer was on Mac OS X 10.9.2 x86_64, I've upgraded to same version
still don't get the problem.
Applescript does exist because earlier in my code I run some applescript
using osascript and Runtime class and that works fine
Any ideas ?
Paul
Re: Disabling AppNap from java
On 22/02/2014 20:43, Eirik Bakke wrote: JNA might be a simpler way to call native functions: https://github.com/twall/jna -- Eirik On 2/22/14, 8:51 AM, "Paul Taylor" wrote: I think Im having problems with AppNap with my application, although it is difficult to understand when/if it is kicking in. 'The correct way to disable App Nap is to use the -[NSProcessInfo beginActivityWithOptions:reason:] and -[NSProcessInfo endActivity] APIs within your app via JNI, and only when your app is actually doing work.' - Mike Swingler Has anything been done to disable AppNap from java without having to use JNI Paul I think JNA or its own is Wndows only isnt it, but there is something called rococoa. To be honest I was hoping someone else had encountered this particular problem with AppNap and had something to share. Paul
Disabling AppNap from java
I think Im having problems with AppNap with my application, although it is difficult to understand when/if it is kicking in. 'The correct way to disable App Nap is to use the -[NSProcessInfo beginActivityWithOptions:reason:] and -[NSProcessInfo endActivity] APIs within your app via JNI, and only when your app is actually doing work.' - Mike Swingler Has anything been done to disable AppNap from java without having to use JNI Paul
Re: OSX Java 8 crash on Mavericks
On 14/02/2014 11:41, Michael Hall wrote: I was under the impressions that however bad my code was it shouldn't cause Java to crash in this way, is that not correct ? I believe that is the theory. So you probably did hit on at least an edge case which the jdk didn't handle as well as you'd hope - if not a actual jdk bug. But interesting that you think there is a bug in my code that could be causing this to happen, its only been reported once by one user so going to be difficult to track down Probably in or calling into native. I don't think I said anything about it being your code. Although I would say it's possible it's your code. I usually tend to suspect mine first in these situations. Probably doing something strange to hit a jdk edge case. To be clear I'm not taking any offense that it could be my code, I just didn't think I could cause a crash. For example in this case if I'm recursively calling something I would just expect a java |StackOverflowError, I think if I did hit ||edge case which the jdk didn't handle as well as hoped that would be a jdk bug in my book. | || |My application doesnt really contain any native code written by me, there is a little bit of Applescript and that is it.| || | Paul|
Re: OSX Java 8 crash on Mavericks
On 14/02/2014 11:16, Michael Hall wrote: Not sure what you mean by update? If you have a bug report? The above sort of suggests you have something looping or too recursive going on with the native gui thread. Probably in or calling into native. I just meant do you know about this issue. I was under the impressions that however bad my code was it shouldn't cause Java to crash in this way, is that not correct ? But interesting that you think there is a bug in my code that could be causing this to happen, its only been reported once by one user so going to be difficult to track down Paul
Re: Java 7 application halting OSX when left unatteended
On 31/01/2014 11:04, Paul Taylor wrote: On 31/01/2014 10:58, Hendrik Schreiber wrote: This smells like App Nap. See http://krypted.com/mac-os-x/disable-app-nap-in-mavericks/ -hendrik I'm just testing it with AppNap will report back later, if this doesnt fix it I'll dig out by 10.8 machine and see if the problem occurs there as well Paul Thanks it does indeed to seem to be AppNap. Well it might be a combination of a couple of things Ive realized in my OSX Preferences I have Energy Saver/Display Sleep and Computer Sleep set to 15 minutes, so I guess that after 15 minutes the Display Sleep will make the screen go black even if progress bar updating because no user has touched keyboard/mouse but computer sleep doesnt kick in because its detect the application is active. But then once Display Sleep is blank that tells AppNap it can pause any application and it does. Clicking on the Properties of the Application and preventing AppNap seems to ensure process continues processing even after screen gone black Is my summary correct ? Paul
Re: Java 7 application halting OSX when left unatteended
On 31/01/2014 10:58, Hendrik Schreiber wrote: This smells like App Nap. See http://krypted.com/mac-os-x/disable-app-nap-in-mavericks/ -hendrik I'm just testing it with AppNap will report back later, if this doesnt fix it I'll dig out by 10.8 machine and see if the problem occurs there as well Paul
Java 7 application halting OSX when left unatteended
My (java 7 based) Gui application processes digital music files, and is designed so it can be left unattended. I have noticed that if I leave it running overnight on my OSX Mavericks computer that it stops shortly after I leave it, only continuing when I touch the keyboard in the morning. How can I prevent this, I do not have the same problem running the application on a Windows 8 machine. paul
Re: Properly code-signing an app with bundled JRE
On 28/01/2014 19:05, Hendrik Schreiber wrote: On Jan 28, 2014, at 19:56, Hendrik Schreiber wrote: On Jan 28, 2014, at 19:28, Paul Taylor wrote: This email sent to paul_t...@fastmail.fm I can confirm I had to change it to use --deep option a while ago for it to work, I do bundle it with a jre and it still works, but maybe not as a plugin not sure what you mean here. I package the JRE into MyApp.app/Contents/PlugIns/jre - so in essence it's a plugin. Would you mind sharing your codesign call, Paul? Though from reading http://furbo.org/2013/10/17/code-signing-and-mavericks/ it sounds like Steve took the "correct" approach by signing the plugin individually. -hendrik Ah right, I package my application up using the BitBucket branch AppBundler https://bitbucket.org/infinitekind/appbundler whihc just relelized all puts the jre in the plugin folder but I only have to do this /usr/bin/codesign --sign "Developer ID Application: P Taylor" --force --deep --verbose /Applications/SongKong.app /usr/bin/codesign --verify --deep --verbose /Applications/SongKong.app and it works, or at least seems to. Paul
Re: Properly code-signing an app with bundled JRE
On 28/01/2014 18:12, Hendrik Schreiber wrote: Hey.. it seems that Apple has changed the way codesign works. On Mavericks with current XCode, Unless you use the --deep option, your app isn't signed at all. And when you use --deep, it works fine as long as you don't bundle a JRE as plugin. Is anybody else having this issue... and perhaps a solution? Thanks, -hendrik PS: I'd be very surprised, if the official Oracle recommendation (http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html) actually still worked. ___ Do not post admin requests to the list. They will be ignored. Java-dev mailing list (java-...@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/java-dev/paul_t100%40fastmail.fm This email sent to paul_t...@fastmail.fm I can confirm I had to change it to use --deep option a while ago for it to work, I do bundle it with a jre and it still works, but maybe not as a plugin not sure what you mean here. Paul
Re: Dragging an image from Webpage within Firefox no longer provides it as DataFlavour java.net.URL/java.util.List on OSX with Java 7
On 13/01/2014 16:47, Hendrik Schreiber wrote: On Jan 13, 2014, at 17:38, Paul Taylor wrote: I verified it was now working , but in my use case the jpeg is within the html file so maybe that is the difference I just tried that as well: no difference :-( Which OS X and Java version did you test with? I tried 10.9.1 and java 1.8.0-b121. -hendrik Hmm, maybe are talking about different things I had two issues, one was fixed by the final version of java 7, and issue with Chrome was fixed with Java 8 build 119 but its a while ago now I'm not sure on the details Paul
Re: Dragging an image from Webpage within Firefox no longer provides it as DataFlavour java.net.URL/java.util.List on OSX with Java 7
On 13/01/2014 16:27, Hendrik Schreiber wrote: On Jan 13, 2014, at 14:14, Paul Taylor wrote: Hi, yes it is fixed in early access version of Java 8 http://download.java.net/jdk8/changes/jdk8-b119.html?q=download/jdk8/changes/jdk8-b119.html Was this fixed by http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8027913 or http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124253? Have you verified the fix? When dragging a JPEG (which is not embedded in HTML) from a web browser to my app, I never get a URL or a File list flavor. What I reliably see is: java.awt.datatransfer.DataFlavor[mimetype=image/x-java-image;representationclass=java.awt.Image] and depending on the browser a bunch of other text/... flavors. But I'd much rather have a URL or a file... This is on OS X 10.9.1 and FireFox 26, Chrome 31 and Safari 7.0.1, Java build 1.8.0-ea-b121. Cheers, -hendrik I verified it was now working , but in my use case the jpeg is within the html file so maybe that is the difference paul
Re: Dragging an image from Webpage within Firefox no longer provides it as DataFlavour java.net.URL/java.util.List on OSX with Java 7
On 13/01/2014 12:55, Hendrik Schreiber wrote: On Nov 25, 2013, at 12:07, Paul Taylor wrote: So on Windows with Java 7 I receive an image dragged frrm a webpage in these flavours (plus others) but these are two I'm interested in 25/11/2013 10.31.07:com.jthink.jaikoz.draganddrop.FileDropTarget:drop:SEVERE: java.awt.datatransfer.DataFlavor[mimetype=application/x-java-url;representationclass=java.net.URL] 25/11/2013 10.31.07:com.jthink.jaikoz.draganddrop.FileDropTarget:drop:SEVERE: java.awt.datatransfer.DataFlavor[mimetype=application/x-java-file-list;representationclass=java.util.List] On OSX with Java 6 I received at least one of the two above, but now with Java 7 (1.7.0_40) I no longer receive either I found these bugs that seem related https://bugs.openjdk.java.net/browse/JDK-7124379 https://bugs.openjdk.java.net/browse/JDK-8005932 Hey Paul, I was just wondering - did you get a resolution for this? Thanks, -hendrik Hi, yes it is fixed in early access version of Java 8 http://download.java.net/jdk8/changes/jdk8-b119.html?q=download/jdk8/changes/jdk8-b119.html Paul
Re: Using the Apple menu (Apple.laf.useScreenMenuBar) the menu items are always in English whatever set as Preferred Language
On 25/12/2013 18:27, Petr Pchelko wrote: Hello, Paul. Thanks, my application is actually packaged using this fork of appbundler https://bitbucket.org/infinitekind/appbundler So will CFBundleAllowMixedLocalizations work for that as well ? I’ve never tried to use this tool, so I do not know. But you could simply try that just by adding CFBundleAllowMixedLocalizations to the Info.plist of a bundled app. I suppose it should work. If it does not the javafxpackager is available in JDK8 EA builds and it works not only for JavaFX but for Swing applications too. With best regards. Petr. Confirmed works thx. Would be nice if could be put into infinitekinds Appbundler anyone, had a look at the source code myself but got nowhere. Paul
Re: Using the Apple menu (Apple.laf.useScreenMenuBar) the menu items are always in English whatever set as Preferred Language
On 25/12/2013 13:26, Petr Pchelko wrote: Hello, Paul. Sorry for the delayed answer. The problem is that we are relying on Cocoa to create these menu items. However, to properly understand the locale Cocoa needs a special key in the Info.plist file (CFBundleAllowMixedLocalizations). However when you are running a java application as java -jar … there’s no Info.plist file, so Cocoa does not use the locale preferences and displays everything in English. We have the same problem with a native FileDialog. The problem does not seem to be fixable internally in JDK, because there’s no API to tell Cocoa that we wish to use CFBundleAllowMixedLocalizations key. The only possible workaround right now is to use the javafxpackager tool and create a native bundle with your application. Bundled apps have an Info.plist and Cocoa localization works well with them. For more info please look at the following JDK bug: https://bugs.openjdk.java.net/browse/JDK-8019464 It’s about the FileDialog, but everything there applies to the default menu items as well. With best regards. Petr. Thanks, my application is actually packaged using this fork of appbundler https://bitbucket.org/infinitekind/appbundler So will CFBundleAllowMixedLocalizations work for that as well ? paul
Re: Signing Mac OS X Apps
On 17/12/2013 04:11, Dinesh Amarasekara wrote: Hi, I have bundled a java application using appbundler. But when I try to sign the bundle it gives me the following error. JavaAppLauncher malformed object (unknown load command 9) Any input for this highly appreciated. Thanks And Best Regards, Dinesh. PS : I ran the following to sign the bundle. codesign -s "3rd Party Mac Developer Application: My Application (AAABBBCCC)" "My Application.app" I think you have to use the --deep option when signing now After signing you can verify it was signed correctly using /usr/bin/codesign --verify --deep --verbose "My Application.app" which will highlight any problems. Paul
Re: On OSX with Editable combo box the button is not aligned correctly with the combobox field
On 12/12/2013 20:39, Anthony Petrov wrote: Hi Paul, Can you please file bugs at http://bugs.sun.com/ for all the issues that you encounter? Okay, Ive submitted bug reports for the editablecombo, and Apple menu bar bugs. I'll go through the others when I can. Paul
On OSX with Editable combo box the button is not aligned correctly with the combobox field
With Editable combo box the button is not aligned correctly with the combobox field, at least I don't think so I'm struggling to find an example of editable combo in a native OSX application. Its worse using size variant small, with non editable combobox its fine. Same problem on Java 7 and Java 8 This screenshot shows three cases http://www.jthink.net/jaikoz/images/combos%20not%20aligned.jpg Language, editable small (JComponent.sizeVariant) Script, no editable small Genre, editable normal
Using the Apple menu (Apple.laf.useScreenMenuBar) the menu items are always in English whatever set as Preferred Language
Using the Apple menu (Apple.laf.useScreenMenuBar) the special menu items are always in English whatever set as Preferred Language OSX:System Preferences:Language and Region:Preferred Languages i.e it stills say Preferences... Show All Hide Others etc in the first menu (my own menu items using my own resource bundle are fine) instead of: Préférences Tout afficher Masquer les autres even if change preferred language from English to French and reboot This works properly using Java 6 Is this a known bug, is quite problematic because it makes Java applications look rather amateurish in non-english env. Paul
Dragging an image from firefox browser works but not Google Chrome with Java 7
Dragging an image from firefox browser works but not Google Chrome, Chrome provides no data flavours when using Java 7 (1.7.0_45) although it works correctly when using Java 6
Dragging an image from Webpage within Firefox no longer provides it as DataFlavour java.net.URL/java.util.List on OSX with Java 7
So on Windows with Java 7 I receive an image dragged frrm a webpage in these flavours (plus others) but these are two I'm interested in 25/11/2013 10.31.07:com.jthink.jaikoz.draganddrop.FileDropTarget:drop:SEVERE: java.awt.datatransfer.DataFlavor[mimetype=application/x-java-url;representationclass=java.net.URL] 25/11/2013 10.31.07:com.jthink.jaikoz.draganddrop.FileDropTarget:drop:SEVERE: java.awt.datatransfer.DataFlavor[mimetype=application/x-java-file-list;representationclass=java.util.List] On OSX with Java 6 I received at least one of the two above, but now with Java 7 (1.7.0_40) I no longer receive either I found these bugs that seem related https://bugs.openjdk.java.net/browse/JDK-7124379 https://bugs.openjdk.java.net/browse/JDK-8005932 Could I have a comment on this please. Paul
CheckboxMenuItem added to dock fires itemevent returning String rather than CheckboxMenuItem
On OSX Java 7 (1.7.0_40) I wanted to add some mutually exclusive
CheckBoxItems to the dock menu, in order to create the mutual
exclusivity I used the answer here by
http://stackoverflow.com/questions/13596428/adding-a-checkbox-group-to-a-java-menu/20092694#20092694
provided by Julian Wright to create the equivalent of ButtonGroup
available for JCheckBoxMenuItems
But I ran into a problem, the object returned by ItemEvent is of type
String rather than CheckBoxMenuItem, I worked round it with the code
below but this is an OSX bug isnt it ?
|import java.awt.*;
import java.awt.event.ItemEvent;
import java.awt.event.ItemListener;
import java.util.HashSet;
import java.util.Set;
public class CheckboxMenuItemGroup implements ItemListener
{
private Set items= new HashSet();
public void add(CheckboxMenuItem cbmi) {
cbmi.addItemListener(this);
cbmi.setState(false);
items.add(cbmi);
}
@Override
public void itemStateChanged(ItemEvent e) {
if (e.getStateChange() == ItemEvent.SELECTED) {
String itemAffected= (String)e.getItem();
for (CheckboxMenuItem item: items) {
if (item.getLabel() != itemAffected) item.setState(false);
}
}
}
public void selectItem(CheckboxMenuItem itemToSelect) {
for (CheckboxMenuItem item: items) {
item.setState(item== itemToSelect);
}
}|
Re: Problem with InetAddress.getLocalHost() on Java 7
On 11/11/2013 15:35, Alan Bateman wrote: On 11/11/2013 09:09, Paul Taylor wrote: Trouble is I cannot replicate the problem myself even if remove entries from /etc/hosts it is only a problem some of my customers are having Paul The reports on this issue (assuming it is the same thing as JDK-7180557) were sparse and it took a while to find a system where this duplicated. The comments in the bug might be useful to help you duplicate it. -Alan. ok, thanks Alan
Re: Problem with InetAddress.getLocalHost() on Java 7
On 11/11/2013 09:02, Alan Bateman wrote: On 08/11/2013 16:48, Paul Taylor wrote: It works okay for me but for a particular customer InetAddress.getLocalHost() is failing with Java 7 although it works okay with Java 6 with the following exception java.net.UnknownHostException: rupert: rupert: nodename nor servname provided, or not known at java.net.InetAddress.getLocalHost(InetAddress.java:1466) Caused by: java.net.UnknownHostException: rupert: nodename nor servname provided, or not known at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method) at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:894) at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1286) at java.net.InetAddress.getLocalHost(InetAddress.java:1462) Is this by design ? This might be another case of JDK-7180557. Any chance that you could try the most recent build of JDK 8 and see if it duplicates? -Alan Trouble is I cannot replicate the problem myself even if remove entries from /etc/hosts it is only a problem some of my customers are having Paul
Problem with InetAddress.getLocalHost() on Java 7
It works okay for me but for a particular customer InetAddress.getLocalHost() is failing with Java 7 although it works okay with Java 6 with the following exception java.net.UnknownHostException: rupert: rupert: nodename nor servname provided, or not known at java.net.InetAddress.getLocalHost(InetAddress.java:1466) Caused by: java.net.UnknownHostException: rupert: nodename nor servname provided, or not known at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method) at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:894) at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1286) at java.net.InetAddress.getLocalHost(InetAddress.java:1462) Is this by design ? Paul
Re: How do I make my Java 7 OSX App draggable on toolbar only ?
On 04/11/2013 09:37, Hendrik Schreiber wrote: On Nov 4, 2013, at 10:05 AM, Paul Taylor wrote: Nevermind I found a solution, I used UnifiedToolbar from thehttp://code.google.com/p/macwidgets/ project with Java 6. Since moving to Java 7 and no longer using UnifiedToolbar I couldn't see a solution but delving into their code simply using WindowsDragger class works perfectly well i.e. new WindowsDragger(frame, toolbar); new WindowsDragger(frame, statusbar) In contrast the "apple.awt.draggableWindowBackground" option is only really useful if happy for the whole frame to be draggable. In other words: it's not useful. But it would be great, if there was something that worked the way Paul used it originally. I.e. a property that can be set on a panel that makes it so that you can drag the window by dragging a panel/container. -hendrik Well it can be useful I use apple.awt.draggableWindowBackground in my SongKong app, and there is it is fine, but yes the option could really be improved on. Paul
Re: How do I make my Java 7 OSX App draggable on toolbar only ?
On 31/10/2013 17:30, Paul Taylor wrote:
Things were working okay with Java 6 ( and some custom libs) but now
by default a Java 7 application is only movable on Mac if you click
near the top of the window (like on Windows), however if I set
toolbar.getRootPane().putClientProperty("apple.awt.draggableWindowBackground")
I can then move the window by dragging on the toolbar. Unfortunately
because this property is applied to the rootpane, and then is just one
rootpane for the frame that the whole applications is a part of the
window moves where-ever I drag on it, I only want to be able to drag
on it in the toolbar.
The main part of my application is a JTable and I really don't want
the window to be moved when I dragclick here because it causes lots of
problems such as I can now no longer reorder by table columns by
dragging the table headers because that just moves the whole window.
How can I limit movement to either:
1. Only the JToolbar
2. Everywhere except the Jtable
whichever is easiest.
thanks Paul
Nevermind I found a solution, I used UnifiedToolbar from
thehttp://code.google.com/p/macwidgets/ project with Java 6. Since
moving to Java 7 and no longer using UnifiedToolbar I couldn't see a
solution but delving into their code simply using WindowsDragger class
works perfectly well
i.e.
new WindowsDragger(frame, toolbar);
new WindowsDragger(frame, statusbar)
In contrast the "apple.awt.draggableWindowBackground" option is only
really useful if happy for the whole frame to be draggable.
Paul
Re: Specifying splash screen in bundle appears to completely screw up using FileDialog
On 01/11/2013 20:33, Paul Taylor wrote: On 01/11/2013 20:00, Paul Taylor wrote: After fixing a load of Java 7 related problems the last two days I was all set to do a new release of my application, but when I did final check of functionality I noticed that when using FileDialogs they were opening a slightly different view (not FileDialog not JFileChooser) and they were indicating busy whenever I selected a folder, and they stayed busy unless I selected another folder and the select the first folder again. this was major regression so I spent all afternoon checking my FileDialog related code which had been changed looking for what I could have changed that would cause this, nothing seemed to fix it. So I then started rebuilding my code from different svn checkins to try and find out where it goes wrong, and the culprit was adding a splash screen to the application bundle ! I did have this in appbundle ant file (and I'm sure I've specified it correctly because the application did correctly show the splash screen when built with this included ) simply removing it and rebuilding and FileDialog now works as intended, and Ive added it and taken it out and rebuilt each time to check this because I couldn't believe it first time. How the two relate I do not know but I would assume splash screens are pretty common, and the link with FileDialogs is so obscure it will be difficult for developers to link the issues. I then found https://bugs.openjdk.java.net/browse/JDK-8009203 which looks to be the same issue, but the comment 'The issue exists from the jdk7u6 on OS X, so it is not a regression' make no sense, it is a regression if moving from Java 6 to Java 7 And the comment 'It is unlikely that the client would notice the problem as it's quite unusual to open the FileChooser immediately after the application loads.' used to justify no fix until jdk 9 is incorrect, the problem occurs however long you wait. This really should be fixed for Jdk 8 at least IMO. thanks Paul This issue may also be related https://bugs.openjdk.java.net/browse/JDK-8020681 Paul Heh, sorry to go on but I found the same issue reported back in December 2012 and no triage done https://bugs.openjdk.java.net/browse/JDK-8006420 in the bug tracker they write 'The FileDialog won't work properly if it's shown while an AWT SplashScreen is showing.' but that is not what the email that the issue is based it does not restrict the issue to when the splash screen is showing, this seems to have been incorrectly inferred by whoeever adde dto the bugtracker. Paul
Re: Specifying splash screen in bundle appears to completely screw up using FileDialog
On 01/11/2013 20:00, Paul Taylor wrote: After fixing a load of Java 7 related problems the last two days I was all set to do a new release of my application, but when I did final check of functionality I noticed that when using FileDialogs they were opening a slightly different view (not FileDialog not JFileChooser) and they were indicating busy whenever I selected a folder, and they stayed busy unless I selected another folder and the select the first folder again. this was major regression so I spent all afternoon checking my FileDialog related code which had been changed looking for what I could have changed that would cause this, nothing seemed to fix it. So I then started rebuilding my code from different svn checkins to try and find out where it goes wrong, and the culprit was adding a splash screen to the application bundle ! I did have this in appbundle ant file (and I'm sure I've specified it correctly because the application did correctly show the splash screen when built with this included ) simply removing it and rebuilding and FileDialog now works as intended, and Ive added it and taken it out and rebuilt each time to check this because I couldn't believe it first time. How the two relate I do not know but I would assume splash screens are pretty common, and the link with FileDialogs is so obscure it will be difficult for developers to link the issues. I then found https://bugs.openjdk.java.net/browse/JDK-8009203 which looks to be the same issue, but the comment 'The issue exists from the jdk7u6 on OS X, so it is not a regression' make no sense, it is a regression if moving from Java 6 to Java 7 And the comment 'It is unlikely that the client would notice the problem as it's quite unusual to open the FileChooser immediately after the application loads.' used to justify no fix until jdk 9 is incorrect, the problem occurs however long you wait. This really should be fixed for Jdk 8 at least IMO. thanks Paul This issue may also be related https://bugs.openjdk.java.net/browse/JDK-8020681 Paul
Re: Moving around Jtable with cursor key balnks out values
On 30/10/2013 12:24, Paul Taylor wrote:
On 30/10/2013 12:13, Paul Taylor wrote:
With Java 7 on OSX I find that as I move around my JTable cells with
cursor keys it causes it to blank out every field in goes into.
Adding:
table.putClientProperty("JTable.autoStartsEdit", Boolean.FALSE)
stops that issue happening, but then I have to press 'Enter' key to
start editing.
What I want to happen is that cursor keys just move the cursor
without editing, and pressing any other key will start editing in
that field. i.e I move to a field and press 'd', then will be
displayed in the field. This is what happened in Java 6 on OSX
(Quaqua) and with Java 7 on Windows.
Paul
Apparently a bug was submitted for this, see
http://stackoverflow.com/questions/11553197/spurious-calls-to-setvalueat-with-jtables-in-java-7-on-os-x-lion
but seems to have disappeared without being fixed, is it still in JIRA ?
Paul
I found the issue, once again the analysis that decides to defer to this
Java 9 is IMO poor
https://bugs.openjdk.java.net/browse/JDK-8025126
The customer submitted workaround of using
putClientProperty("JTable.autoStartsEdit", Boolean.FALSE);
is not a useful workaround for me and many others.
I had to check for empty values in setValue() method of my model instead
but this causes other problems such as now the cannot explicity set a
value to blank because their modification gets ignored. Surely this
terribly buggy behaviour is higher priority than some of the other hings
being fixed.
Sorry to be complaining because in general Im very positive about Java 7
on Mac, but at least someone complains directly about these issue I
imagine they will remain low priority
Paul
Specifying splash screen in bundle appears to completely screw up using FileDialog
After fixing a load of Java 7 related problems the last two days I was all set to do a new release of my application, but when I did final check of functionality I noticed that when using FileDialogs they were opening a slightly different view (not FileDialog not JFileChooser) and they were indicating busy whenever I selected a folder, and they stayed busy unless I selected another folder and the select the first folder again. this was major regression so I spent all afternoon checking my FileDialog related code which had been changed looking for what I could have changed that would cause this, nothing seemed to fix it. So I then started rebuilding my code from different svn checkins to try and find out where it goes wrong, and the culprit was adding a splash screen to the application bundle ! I did have this in appbundle ant file (and I'm sure I've specified it correctly because the application did correctly show the splash screen when built with this included ) simply removing it and rebuilding and FileDialog now works as intended, and Ive added it and taken it out and rebuilt each time to check this because I couldn't believe it first time. How the two relate I do not know but I would assume splash screens are pretty common, and the link with FileDialogs is so obscure it will be difficult for developers to link the issues. I then found https://bugs.openjdk.java.net/browse/JDK-8009203 which looks to be the same issue, but the comment 'The issue exists from the jdk7u6 on OS X, so it is not a regression' make no sense, it is a regression if moving from Java 6 to Java 7 And the comment 'It is unlikely that the client would notice the problem as it's quite unusual to open the FileChooser immediately after the application loads.' used to justify no fix until jdk 9 is incorrect, the problem occurs however long you wait. This really should be fixed for Jdk 8 at least IMO. thanks Paul
Re: Java 7 Application built on OSX 10.9 crashing on startup on 10.7.5
On 01/11/2013 01:41, Michael Hall wrote: On Oct 31, 2013, at 7:10 PM, Paul Taylor wrote: On 31/10/2013 21:49, Michael Hall wrote: On Oct 30, 2013, at 4:38 PM, Paul Taylor wrote: /Applications/Jaikoz.app/Contents/MacOS/Jaikoz I'm assuming this is the appbundler JavaAppLauncher. Which branch? java.net project or infinitekind? Which OS version was it built on? Ah, I think you have it. It was the latest version of infinitekind on mavericks, and now I remember change something in the appbundler build file because it couldn't find some 10.7 files, is it possible these files on 10.9 is it possible these files are not on 10.9? I would think some incompatibility is possible. You could maybe try building the native executable on 10.7 instead of 10.9. If it works, you have one executable that works for all. Otherwise you might have to resolve the incompatibility. For infinitekind, or both JavaAppLauncher projects, figuring out what the incompatibility is might be appreciated anyhow. Hi Michael Sorry that sentence didn't make much sense, I meant to say 'is it possible to install the missing files on OSX 10.9 so that appbundler builds without modification.' Anyway, I have found my mistake in the build.xml for appbundler i modified to I should have just changed the first line, and left the second line alone Building my application using this version of Appbundler it now works okay on 10.7, 10.8 and 10.9 Ive looked at the Infinitekinds Appbundler and this changed has already been committed, but unfortunately that occurred after I downloaded it. So sorry stupid mistake on my part but this backups my unanswered post on the Appbundler mailing list that it would be useful if Infinitekind made a prebuilt download available to help those of us who don't really understand non java stuff, and also had their own mailing list/bug tracker as there is no way to communicate on bitbucket except committing code and commenting on code, if that was the case I would have asked someone instead of blindly changing the build.xml without understanding what I was doing. Paul Paul
Re: Java 7 Application built on OSX 10.9 crashing on startup on 10.7.5
On 31/10/2013 21:49, Michael Hall wrote: On Oct 30, 2013, at 4:38 PM, Paul Taylor wrote: /Applications/Jaikoz.app/Contents/MacOS/Jaikoz I'm assuming this is the appbundler JavaAppLauncher. Which branch? java.net project or infinitekind? Which OS version was it built on? Ah, I think you have it. It was the latest version of infinitekind on mavericks, and now I remember change something in the appbundler build file because it couldn't find some 10.7 files, is it possible these files on 10.9 Paul Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter
Re: Java 7 Application built on OSX 10.9 crashing on startup on 10.7.5
On 31/10/2013 18:38, Mike Swingler wrote: Is this the full crash log? Are there no thread stacks? Regards, Mike Swingler Apple Inc. Thats all that comes up with the Crash reporter, Ive now tried another application that definitently was working on OSX 10.7 with an earlier version of Java 7 but now crashes in the same way, you can download both, they have both been released because they do work on 10.8 and 10.9 http://www.jthink.net/jaikoz/jsp/manualdownload/jaikoz-osx.dmg?val=125 http://www.jthink.net/songkong/downloads/songkong-osx.dmg?val=15 Paul
How do I make my Java 7 OSX App draggable on toolbar only ?
Things were working okay with Java 6 ( and some custom libs) but now by
default a Java 7 application is only movable on Mac if you click near
the top of the window (like on Windows), however if I set
toolbar.getRootPane().putClientProperty("apple.awt.draggableWindowBackground")
I can then move the window by dragging on the toolbar. Unfortunately
because this property is applied to the rootpane, and then is just one
rootpane for the frame that the whole applications is a part of the
window moves where-ever I drag on it, I only want to be able to drag on
it in the toolbar.
The main part of my application is a JTable and I really don't want the
window to be moved when I dragclick here because it causes lots of
problems such as I can now no longer reorder by table columns by
dragging the table headers because that just moves the whole window. How
can I limit movement to either:
1. Only the JToolbar
2. Everywhere except the Jtable
whichever is easiest.
thanks Paul
Default heap memory size allocated with Java 7 on OSX
How does Java 7 decide on the max value of heap memory allocated (-Xmx) if not specified on an OSX bundle, I've read the manual page and it gave no indication. It seems to be allocated more than the default on Java 6 and I wonder if it varies with the memory available on the machine, that would be very useful to me because my application is memory bound, but I cannot set the default too high because then the application would fail to run at all on lower specification machines. Paul
Re: Possible regressionn, popupmenus not appearing to work correctly with cntl-click
On 31/10/2013 11:11, Leonid Romanov wrote:
I see.. While it might pose an inconvenience in some scenarios on OS
X, I don't think it's an issue, since Apple JDK 6 behaves the same
way, so I'm going to close the bug.
Okay no problem, I now have it working for me since using
setComponentPopup(). The only thing I would say is that is if Cntl-Click
is meant to work the same as Right-Click on OSX in all situations it
does seem there is a minor issue that it breaks my old code but this is
no longer a problem for me.
On 29.10.2013, at 15:14, Paul Taylor <mailto:paul_t...@fastmail.fm>> wrote:
On 28/10/2013 12:29, Leonid Romanov wrote:
Hello,
I've filed a bug:
https://bugs.openjdk.java.net/browse/JDK-8027374
Hi, Ive think Ive found the issue for me , I created this test case
and it works correctly as you say
import javax.swing.*;
public class TableTest
{
public static void main(String[] args) throws Exception
{
JPopupMenu popup = new JPopupMenu("Popup");
popup.add(new JMenuItem("Copy"));
JTable test = new JTable(5,5);
test.setComponentPopupMenu(popup);
test.setRowSelectionAllowed(true);
test.setColumnSelectionAllowed(true);
UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName());
JFrame frame = new JFrame();
frame.add(test);
frame.pack();
frame.setVisible(true);
}
}
But if you comment out the line
test.setComponentPopupMenu(popup);
so that there is no popup menu then it doesn't work, CntlClick will
change the selection.
Whether this is a bug, or correct behaviour Im not sure ?
But the reason why this is causing an issue for me in my current code
is that Im not using setComponentPopupMenu()instead I'm adding a
mouse handler to the table that then decides whether or not to show a
popup menu so I guess the logic for Jtable must not detect that it
has a popup menu in this case. I've checked and the method was not
added to JTable until Java 1.5 and my code was started before then so
hopefully I can just update my code to use the method and the
problem will go away for me.
Paul
Java 7 Application built on OSX 10.9 crashing on startup on 10.7.5
Ive built a Java 7 bundle for my application on OSX10.9, all appears well but when I try it on OSX 10.7 it crashes on startup But Java 7 is supported on OSX 10.7.3 and later, right ? Details below: Process: launchd [229] Path:/Applications/Jaikoz.app/Contents/MacOS/Jaikoz Identifier: com.jthink.jaikoz Version: ??? (???) Code Type: X86-64 (Native) Parent Process: launchd [110] Date/Time: 2013-10-30 21:10:32.986 + OS Version: Mac OS X 10.7.5 (11G56) Report Version: 9 Interval Since Last Report: 9929716 sec Crashes Since Last Report: 15 Per-App Crashes Since Last Report: 1 Anonymous UUID: 9162B9F6-4E51-4991-9437-5E6CB7C3A73D Crashed Thread: Unknown Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_PROTECTION_FAILURE at 0x7fff5fc01028 Backtrace not available Unknown thread crashed with X86 Thread State (64-bit): rax: 0x0055 rbx: 0x rcx: 0x rdx: 0x rdi: 0x rsi: 0x rbp: 0x rsp: 0x r8: 0x r9: 0x r10: 0x r11: 0x r12: 0x r13: 0x r14: 0x r15: 0x rip: 0x7fff5fc01028 rfl: 0x00010203 cr2: 0x7fff5fc01028 Logical CPU: 0 Binary images description not available External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 2 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 312 thread_create: 0 thread_set_state: 0 Model: Macmini2,1, BootROM MM21.009A.B00, 2 processors, Intel Core 2 Duo, 1.83 GHz, 2 GB, SMC 1.19f2 Graphics: Intel GMA 950, GMA 950, Built-In, spdisplays_integrated_vram Memory Module: BANK 0/DIMM0, 1 GB, DDR2 SDRAM, 667 MHz, 0xAD00, 0x48594D503531325336344350382D59352020 Memory Module: BANK 1/DIMM1, 1 GB, DDR2 SDRAM, 667 MHz, 0xAD00, 0x48594D503531325336344350382D59352020 AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x86), Atheros 5424: 2.1.14.9 Bluetooth: Version 4.0.8f17, 2 service, 18 devices, 1 incoming serial ports Network Service: Ethernet, Ethernet, en0 Serial ATA Device: Hitachi HTS541680J9SA00, 80.03 GB Parallel ATA Device: MATSHITACD-RW CW-8124 USB Device: Keyboard Hub, apple_vendor_id, 0x1006, 0xfd50 / 2 USB Device: Apple Keyboard, apple_vendor_id, 0x0221, 0xfd52 / 3 USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x8205, 0x7d10 / 2 USB Device: IR Receiver, apple_vendor_id, 0x8240, 0x7d20 / 3 USB Device: Microsoft Wireless Optical Mouse® 1.00, 0x045e (Microsoft Corporation), 0x00e1, 0x5d20 / 2
Re: Moving around Jtable with cursor key balnks out values
On 30/10/2013 12:13, Paul Taylor wrote:
With Java 7 on OSX I find that as I move around my JTable cells with
cursor keys it causes it to blank out every field in goes into.
Adding:
table.putClientProperty("JTable.autoStartsEdit", Boolean.FALSE)
stops that issue happening, but then I have to press 'Enter' key to
start editing.
What I want to happen is that cursor keys just move the cursor without
editing, and pressing any other key will start editing in that field.
i.e I move to a field and press 'd', then will be displayed in the
field. This is what happened in Java 6 on OSX (Quaqua) and with Java 7
on Windows.
Paul
Apparently a bug was submitted for this, see
http://stackoverflow.com/questions/11553197/spurious-calls-to-setvalueat-with-jtables-in-java-7-on-os-x-lion
but seems to have disappeared without being fixed, is it still in JIRA ?
Paul
Moving around Jtable with cursor key balnks out values
With Java 7 on OSX I find that as I move around my JTable cells with cursor
keys it causes it to blank out every field in goes into.
Adding:
table.putClientProperty("JTable.autoStartsEdit", Boolean.FALSE)
stops that issue happening, but then I have to press 'Enter' key to start
editing.
What I want to happen is that cursor keys just move the cursor without editing,
and pressing any other key will start editing in that field. i.e I move to a
field and press 'd', then will be displayed in the field. This is what happened
in Java 6 on OSX (Quaqua) and with Java 7 on Windows.
Paul
Re: Possible regressionn, popupmenus not appearing to work correctly with cntl-click
On 28/10/2013 12:29, Leonid Romanov wrote:
Hello,
I've filed a bug:
https://bugs.openjdk.java.net/browse/JDK-8027374
Hi, Ive think Ive found the issue for me , I created this test case and
it works correctly as you say
import javax.swing.*;
public class TableTest
{
public static void main(String[] args) throws Exception
{
JPopupMenu popup = new JPopupMenu("Popup");
popup.add(new JMenuItem("Copy"));
JTable test = new JTable(5,5);
test.setComponentPopupMenu(popup);
test.setRowSelectionAllowed(true);
test.setColumnSelectionAllowed(true);
UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName());
JFrame frame = new JFrame();
frame.add(test);
frame.pack();
frame.setVisible(true);
}
}
But if you comment out the line
test.setComponentPopupMenu(popup);
so that there is no popup menu then it doesn't work, CntlClick will
change the selection.
Whether this is a bug, or correct behaviour Im not sure ?
But the reason why this is causing an issue for me in my current code is
that Im not using setComponentPopupMenu()instead I'm adding a mouse
handler to the table that then decides whether or not to show a popup
menu so I guess the logic for Jtable must not detect that it has a popup
menu in this case. I've checked and the method was not added to JTable
until Java 1.5 and my code was started before then so hopefully I can
just update my code to use the method and the problem will go away for me.
Paul
Re: Possible regressionn, popupmenus not appearing to work correctly with cntl-click
On 27/10/2013 08:06, Hendrik Schreiber wrote:
On Oct 26, 2013, at 9:36 PM, Paul Taylor wrote:
Just moved from Java 6 with Quaqua and Feel to Java 7 with Aqua look and feel
so not 100% sure where the problem lies but previously if I have some fields
selected in a table and then invoked popup menu by either
1. Right click on two button mouse
2. Left Click whilst pressing Cntl Key
it would display the popup menu.
Now with Java 7
Right click on two button mouse works correctly
Left Click whilst pressing Cntl key displays the popup menu BUT also deselects
all fields that was selected except the one the mouse is currently over.
Is this a known problem, seeing as macs are still sold with one-button mice
this looks like a major regression
Command-click starts editing.. (yeah, I know). Does setting
table.putClientProperty("JTable.autoStartsEdit", Boolean.FALSE)
on the JTable make a difference?
No, that doesnt make any difference. Actually the problem is not to do
with editing (these fields aren't even editable). The problem is that
with Cntl-Left Click instead of Right-Click it correctly show the
popups, but it also resets selection, so basically it is doing a
right-click and a left-click, i.e not realizing that it shouldn't do the
left click action because the cntl key was pressed.
Looking at
https://java.net/projects/quaqua/sources/svn/content/trunk/Quaqua/src/ch/randelshofer/quaqua/QuaquaTableUI.java?rev=460
maybe the shouldIgnore() method in line 790 is handling a case that Java
7 is not
Paul
Possible regressionn, popupmenus not appearing to work correctly with cntl-click
Just moved from Java 6 with Quaqua and Feel to Java 7 with Aqua look and feel so not 100% sure where the problem lies but previously if I have some fields selected in a table and then invoked popup menu by either 1. Right click on two button mouse 2. Left Click whilst pressing Cntl Key it would display the popup menu. Now with Java 7 Right click on two button mouse works correctly Left Click whilst pressing Cntl key displays the popup menu BUT also deselects all fields that was selected except the one the mouse is currently over. Is this a known problem, seeing as macs are still sold with one-button mice this looks like a major regression Paul
Is OSX JTable and JList selection color incorrect
On OSX Java 1.7.0_40-b43 the selection colour appears correct ( a light blue) but JTable and JList selection colour is dark blue like on Windows Am I doing something wrong, or is this a bug , or is it meant to be like this ? Paul
Re: Does Java 7 port support the apple.awt-use-dialog-packages system property
On 18/10/2013 14:02, Anthony Petrov wrote: Hi Paul, I've just filed this issue for you: https://bugs.openjdk.java.net/browse/JDK-8026869 It is currently targeted for JDK 9. After it's fixed in the mainline, we can consider porting the fix to 8- and 7-update releases. Hi, thanks alot -I assume I don't submit bugs straight into that. I was trying to use the bugs database Paul
Re: Does Java 7 port support the apple.awt-use-dialog-packages system property
On 17/10/2013 22:34, Sergey Bylokhov wrote: On 18.10.2013 0:31, Paul Taylor wrote: Oh drat, shame as the similar "apple.awt.fileDialogForDirectories" was added, having said that when I use this in another project it was with an early access release of 1.7.0_40 , now with the final release although I can select folders as required , I can also select files I thought they were hidden or greyed out, or is my memory failing me. The possibility to select files in this mode is a bug, and it was fixed in jdk 8 https://bugs.openjdk.java.net/browse/JDK-8025503 Thanks, but with Java 8 not being released until March 2014 is there no chance of it being fixed in Java 7 ? Ive tries to submit a bug report three times now and each time it fails at the end, and yes I do view it as a bug not an rfe because its a regression from java 6. At least the last time I kept the bug report information in a text file so I post here in case anyone can do anything with it Java 7 on Mac no longer supports apple.awt.use-file-dialog-packages property OSX 10.8 Darwin macbook.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64 java version "1.7.0_40" Java(TM) SE Runtime Environment (build 1.7.0_40-b43) Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode) In Java 6 on OSX the apple.awt.use-file-dialog-packages property is used by FIleDialog to display application bundles as leaf node rather than a folder (which is what they actually are). This allows an application to create a dialog that lets the user pick a bundle as an application i.e to let them configure their browser or Texteditor. This option is no longer available I no longer have that installed but this worked with Apples version of Java Create a FileDialog Navigate to the /Applications folder Applications are listed and cannot be expanded, the same behaviour as using a Finder window Use of the the property can be seen in ApplicationDialog within this project https://java.net/projects/mrjadapter/sources/svn/content/trunk/src/net/roydesign/ui/ApplicationDialog.java?rev=35 The problem is that this issue makes it difficult to update my application to use Java 7 rather than Java 6 as we are being advised to do because it degrades the functionality of my application
Re: Does Java 7 port support the apple.awt-use-dialog-packages system property
On 17/10/2013 21:03, Anthony Petrov wrote: Hi Paul, Apparently not: $ grep -r "awt-use-file-dialog-packages" jdk/src/* | wc -l 0 Your best bet is to file an RFE at http://bugs.sun.com/ Oh drat, shame as the similar "apple.awt.fileDialogForDirectories" was added, having said that when I use this in another project it was with an early access release of 1.7.0_40 , now with the final release although I can select folders as required , I can also select files I thought they were hidden or greyed out, or is my memory failing me. I must admit I wasn't aware of the apple.awt-use-dialog-packages property myself, I only found it when I delved into how ApplicationDialog in Mrjadapter project worked https://java.net/projects/mrjadapter/sources/svn/content/trunk/src/net/roydesign/ui/ApplicationDialog.java?rev=35 Paul
Does Java 7 port support the apple.awt-use-dialog-packages system property
Im trying to port an application from Java 6 to Java 7 on Mac does Java 1.7.0_40-b43 support the apple.awt-use-file-dialog-packages option system property so that I can select and application bundle in a FileDialog as if it a file rather than the reality ( a folder), Im having trouble getting existing code to work thanks Paul
