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
File watching on Oracle JDK on Mac OS X and other platforms
Hello, As I understand it, the file watcher service introduced with JDK 7 uses native (near real-time) notifications on Windows and Linux, but polling on Mac OS X. First off, is this correct? Second, if it is, what is the polling interval on Mac OS X (and can it be configured)? (I originally posted this question to java-...@lists.apple.com but reposted here following a reply on that list). Thanks, Christopher
Re: FullScreen (Exclusive) Swing Components Fail to Receive Keyboard Input on Java 7 on Mac OS X (Mountain) Lion
On 10/30/13 1:05 PM, "Leonid Romanov" wrote: >I've just pushed the fix for this issue. Should appear in main JDK 8 repo >after a while. Thanks so much Leonid. I'd love to try building with this patch and testing our application. Is it the one at http://cr.openjdk.java.net/~leonidr/8013581/webrev.00/jdk.patch>? And, I'm a little bit unfamiliar with the process so what timeframe (just days vs weeks vs months) is "a while" as far as appearing in the repo? Is there any chance this might get dropped into a future JDK 7 update as well? It appears the original bug was introduced in a JDK 7 update. Thanks, Tim This email message, including any attachment(s), is for the sole use of the intended recipient(s) and may contain confidential and legally privileged information. If you believe that you are not an intended recipient of this message, please contact the sender by reply email and destroy all copies of the original message. Any unauthorized use, dissemination, or reproduction of this message by anyone other than an intended recipient is strictly prohibited. BLOODHOUND is a trademark of Constitution Medical, Inc.
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: 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
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: 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: File watching on Oracle JDK on Mac OS X and other platforms
On Nov 1, 2013, at 11:33 AM, Christopher Brown wrote: > Hello, > > As I understand it, the file watcher service introduced with JDK 7 uses > native (near real-time) notifications on Windows and Linux, but polling on > Mac OS X. > > First off, is this correct? Yes, polling > > Second, if it is, what is the polling interval on Mac OS X (and can it be > configured)? Don't know This was part of nio.2 for JDK 7. There a couple mailing lists for that. nio-...@openjdk.java.net nio-disc...@openjdk.java.net 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: File watching on Oracle JDK on Mac OS X and other platforms
On 11/01/2013 03:45 PM, Michael Hall wrote: On Nov 1, 2013, at 11:33 AM, Christopher Brown wrote: Hello, As I understand it, the file watcher service introduced with JDK 7 uses native (near real-time) notifications on Windows and Linux, but polling on Mac OS X. First off, is this correct? Yes, polling Second, if it is, what is the polling interval on Mac OS X (and can it be configured)? Don't know This was part of nio.2 for JDK 7. There a couple mailing lists for that. nio-...@openjdk.java.net nio-disc...@openjdk.java.net 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 Hi Christopher, We are aware that polling in Mac platform is not performance-friendly, and we are going to enhance it with the native facility provided on Mac platform, like kqueue-based WatchService. Thanks! -Dan
