I need to use netscape.javascript.JSObject but cannot understand how I have to compile the applet. Think I have to download the package, in order to set "import netscape.javascript.JSObject", but where do I find it? Besides, do I have to set some building settings? Xcode 2.5, OSX 10.4. [...]]]>
[...] Have you tried the recent developer preview of Java? The bug should be fixed. If not, please comment in the bug report. Pratik]]>
[...] ID# 6993533 open since 22-Jun-2009]]>
The only other place an app with that CFBundleIdentifier could have been was in the Trash. Putting it on a clean machine (that never had the app) would presumably work, since it worked when changing the CFBundleIdentifier -- but we need this to work on dirty machines. [...]]]>
Nick, Thanks, now I can just stop working on something that I have no ability to fix. The actual number is probably of no use, since you can only view your own stuff, I think. Jeff On 11/6/09 4:23 PM, "Nick Howes" <email@hidden> wrote: [...]]]>
[...] This bug has been around for a while (I'd give you a bug ref number but bugreport.apple.com is down at the moment). - Nick]]>
Tomas, I tried that permutation, and forgot to mention it. I even started making errors in the jnlp, to make sure it was being read every time. Thanks, Jeff On 11/6/09 4:04 PM, "Tomas Hurka" <email@hidden> wrote: [...]]]>
Hi Jeff, On 6 Nov 2009, at 19:56, Jeff Palmer wrote: [...] ^^^^^^^^^^^^^^^^^^^^^^^^^ Xdock:name is a java command line option not a system property. So you should use -Xdock:name='Sample Name' and not -DXdock:... in your JNLP file. HTH,]]>
Title: Application name in JWS The name of my applications in the Apple Menu initially takes on name in the Title tag of my JNLP for a second, then the name changes to com.sun.javaws.Main . In development, Netbeans, the name is the class name. I can put in the command line arg -Xdock:name='Sample Name' & this changes it permanently. I tried adding this in the resources tag of the JNLP, but nothing different happened <j2se version="1.6+" java-vm-args="-DXdock:name='Sample Name' -Dapple.awt.graphics.UseQuartz=true -Dapple.laf.useScreenMenuBar=true"/> A couple of things that might be pertinent. I do not use a Info.plist . I looked at some of those entries, and I already have a way to do that stuff in the JNLP. I think I can even specify stuff by OS there. The other thing is I am not running this yet from a http server. I am using [...] Has anyone seen this before?]]>
[...] It sounds like there's another version of the app, and it has different Info.plist content. After rebuilding the launch services database(s), dump the resulting database and look for the CFBundleIdentifier of your app. Also, try putting the app on a known-clean machine (never had the app on it before). -- GG]]>
We took this advice & built a new Info.plist with the appropriate keys, but are having trouble getting OS X to recognize it. We set the preferred architecture order to be 32bit & then 64bit, added that 10.6 was a minimum requirement for 32bit, and 10.5 was a minimum requirement for 64bit. [...]]]>
Hi, I realize this not the right list but since we are using Java and Mac OS I figured some people on this list might provide pointers. A colleague stored some (this is second hand info, since I do not use Xcode) Xcode projects into StarTeam. If I understood correctly [...]]]>
I have this problem with all java apps; to get around it for now I added a mouseListener to the popupmenu and then hide the menu when mouseExited event occurs; not very elegant but works reasonably well. On Nov 3, 2009, at 12:10 PM, Mike Swingler wrote: [...]]]>
I should also add here, that f.getCanonicalPath(), which getCanonicalFile() uses to make the File, returns an empty string. On Nov 4, 2009, at 8:04 PM, Sam Berlin wrote: [...]]]>
[...] You can enable kernel tracing with the 'ktrace' command. Look through the resulting system calls and see if stat() or lstat() is among them. Then look at what pathname it's getting. I would condense the fail-case down to a non-interactive, non-GUI [...]]]>
On Nov 4, 2009, at 4:16 PM, Greg Guerin wrote: Scott Kovatch wrote: > quoted text [...] Seems like a bug to me. Exactly what kind of bug depends on which native API File.exists() is actually using. Still, since the names came from File itself, as a listing, the names should work as inputs to File. > quoted text [...] While I can't see the full implementation of exists(), I can see that it eventually passes the File object into native code in UnixFileSystem. I also know that the file system represents file names in UTF-8. NSFileManager's fileSystemRepresentation effectively does this for you, but calling that via JNI (or, in my case, Eclipse SWT's OS layer) gave me the same results as calling String.getBytes("UTF-8"), so something else is going on. > quoted text [...] FSRefs may be the way to go. There's other code in the SWT that boils file names down to FSRefs, so I should be able to adapt that code for my needs. Figuring out how to make this file name work with exists() may turn out to be an interesting side-effect, because what I really need to do is read the file. If I have to use native code to accomplish that, so be it. I'll post the results here, because this seems like a common-enough problem that someone else would encounter. -- Scott ---------- Scott Kovatch Flex Engineering email@hidden I am Scott Kovatch, and I approve this message.]]>
[...]]]>
[...] Seems like a bug to me. Exactly what kind of bug depends on which native API File.exists() is actually using. Still, since the names came from File itself, as a listing, the names should work as inputs to File. [...] I don't know why you think that. [...]]]>
Hello!
I would like to use default menu bar. Here is code I am using:
public class ApplicationAdapter implements ApplicationListener {
public static void installSupport() {
Application app = Application.getApplication();
app. [...]]]>Hi everyone. I think I've found a bug and I'd like to know if you are able to reproduce it. As far as I can tell, it only happens on Mac OS X, at least on 10.5 and 10.6... I've asked this question over at stackoverflow.com but nobody had an idea so far: http://stackoverflow. [...]]]>
Michael, I recommend perservering with Rococoa. I had trouble getting started with it some weeks ago, then suddenly things 'clicked'. It became a straight-forward way to get Objective-C libraries working in Java. Regarding the problems getting the java.library. [...]]]>
Why do you need to do this? The reason I ask is that I've tried similar things to do animations and such, but the results were unsatisfactory. (There was a book named Swing Hacks that takes that approach, for example.) It's far too common for users to be doing something animated (like playing a game or video or animated web page) in the background. Bringing up a still snapshot in front of that makes it look like everything else has stopped or frozen. I've had good results doing animation on JFrames that are partially transparent. -- John On Nov 4, 2009, at 3:58 AM, Satyaprasad Mylavarapu wrote: > quoted text
]]>Hi, We're having some problems doing file operations in Java with filenames that have surrogate pairs. When I run this program: import java.io.*; import java.nio.*; import java.nio.charset.*; public class SurrogateTesting { /** * @param args * @throws IOException */ public static void main(String[] args) throws IOException { System.out.println("Default charset = " + Charset.defaultCharset().name()); java.awt.FileDialog fd = new java.awt.FileDialog( new java.awt.Frame () ); fd.setVisible(true); String directory = fd.getDirectory(); File directoryObj = new File(directory); File children[] = directoryObj.listFiles(); for (File f : children) { bb1 = java.nio.ByteBuffer.wrap ( f.getName().getBytes("UTF-8") ); System.out.println( "Filename:" ); // printHexOn( System.out, bb1 ); System.out.println("file = " + f + ", " + f.exists()); } } } (I removed the printHexOn method, as it's not relevant to the problem.) and select a file from a directory with filenames containing surrogate pairs, I get this output. ---------- Default charset = MacRoman Filename: 0000 e8 8d 89 f0 a6 bf b6 e9 b7 97 e5 a4 96 2e 67 69 |..............gi| 0010 66 |f| file = /Users/skovatch/Downloads/surrogates/????.gif, false ---------- The byte output looks correct. I did a test in Python and saw that I was getting the same UTF-8 values for the filename. Why is File.exists() failing? The raw file object shows the split UTF-16 values for the second character in the filename (\ud85b, \udff6). This makes me think I need to do some kind of conversion on the filename so it gets turned into properly decomposed UTF-8, but if I make a new string from the UTF-8 interpretation of the bytes using String UTF8Filename = new String(fileName.getBytes("UTF-8"), "UTF-8"); File.exists still fails. I also tried calling fileSystemRepresentation and bringing the characters back into Java, but it didn't look any different. I'm hoping the collective wisdom of this list has dealt with this problem before, as it seems like a common thing to do. Am I off on my assumption that exists() should be working in this case? I haven't yet tried reading the file with an InputStream or SWT Image - that's probably my next try. Thanks, Scott K. ]]>
Hi Satya, On 4. nov.. 2009, at 09.58, Satyaprasad Mylavarapu wrote: > quoted text
There is the Java "full-screen exclusive" API, but I'm not sure if that fits your needs ("desktop mode"). You could at least have a look: http://java.sun. [...]]]> Hi Nikolas, I tried by placing the System Properties which are mentioned at the URL provided by you. I am not finding any difference if I set "apple.awt.fakefullscreen" to true. My captured frame is not coming on top of MAC Menu bar as well as Dock. [...]]]>
Home
Archives
FAQ
Terms/Conditions
Contact
RSS
Lists
About
Visit the Apple Store online or at retail locations.
1-800-MY-APPLE
Contact Apple | Terms of Use | Privacy Policy
Copyright © 2007 Apple Inc. All rights reserved. [...]]]>Hi All, I have a requirement of doing a full screen capture and then displaying the captured image in a full screen size undecorated frame. The frame is also set to display on top of all other windows by using "setAlwaysOnTop(true)". The problem is, I am unable to display the frame [...]]]>
On Oct 31, 2009, at 3:30 PM, Mike Swingler wrote: > quoted text
This turns out to have some interesting performance implications. I wrote a trivial runnable that does nothing but call System.nanoTime() to measure average elapsed time to get into the Java code. [...]]]>I am trying to incorporate a small objective C widget into my OSX java app. This widget would only take a few lines of objective-c to work but I am having trouble with both Rococoa and JNI. In setting up Rococoa I am having trouble because the direction instruct me to add [...]]]>
Got it -- thanks for the explanation. If I can paraphrase the outcome: there's no way preferred way to say in an Info.plist, "run in the 32bit architecture if you have 32bit Java, run in 64bit if you don't". However, we can get close by assuming that 10.5 only has 64bit and 10. [...]]]>
The issue is in our bug tracker at <http://bugreporter.apple.com>. Unfortunately, you cannot search for bugs originated by other users. If you file a duplicate you might (I'm not sure) be able to request visibility of the original. Regards, Mike Swingler Java Runtime Engineer Apple Inc. [...]]]>
Mike, thanks for you reply. Do you pointing me to a link where this issue is logged? thanks, Melissa On Nov 3, 2009, at 1:42 PM, Mike Swingler wrote: [...]]]>
[...] This is a known issue with JPopupMenus. They are also in the wrong window level, so they tend to float on top of _everything_, including other applications and the screen saver. Sorry, Mike Swingler Java Runtime Engineer Apple Inc.]]>
On Nov 3, 2009, at 10:56 AM, Sam Berlin wrote: > quoted text
The issue is that LaunchServices does not know it's launching a Java application, and it has no knowledge of Java, it's versions, their architectures, or the phases of the moon. It simply picks an architecture in the Mach-o executable, and starts it. Once that occurs, the JavaApplicationLauncher.framework and JavaVM.framework scans the available JVMs, their architectures, the user's preferences, and chooses the "best" JVM to launch in the current architecture*. Also, now that Mac OS X 10.6 has shipped, it's not a particularly creative leap of imagination to guess that Apple will _not_ be expanding it's configuration, support, and testing matrix of Java versions on Mac OS X 10.5. Removing 32-bit support from 10.6 doesn't make any sense, because that would leave 32-bit only machines without a functioning Java. Cheers, Mike Swingler Java Runtime Engineer Apple Inc. * Launching situations involving PPC/Rosetta, broken i386 stubs, impossible version requests, and JVMArchs/JVMArches may result in re-executing using the system-provided JavaApplicationStub with any number of skanky hacks attempting to avoid infinitely re-exec()'ing or fork() bombing your computer. On Tue, Nov 3, 2009 at 1:50 PM, Mike Swingler <email@hidden> wrote: > quoted text
]]>[...] I remember having seen the following: open a context menu (e.g. right clicking on a table), clicking the main menu bar: the context menu remains open. :( Tom Amoros, Melissa wrote: [...]]]>
[...] I don't think it can be done easily, from pure Java. You CAN get a window to lie above the menu bar, but it requires native code, using JAWT to gain access to the NSView and NSWindow Cocoa objects, and setting the window level of the NSWindow object to a value above the [...]]]>
Yup, there's a CFBundleIdentifier. I'll give the LSMinimumSystemVersionByArchitecture a shot, but I was trying to stay away deciding the logic based on OS version (from advice on this list). My hope was that LSArchitecturePriority by itself would work, and the launcher would refuse to use the 32bit architecture on platforms where there was no 32bit Java (so that, if pigs started flying and a 32bit Java came out for 10.5, it would automagically work -- or if Apple removed 32bit support from 10.6, the app would continue to launch). Is LSArchitecturePriority supposed to be doing what it's doing, or should it be recognizing the Java architecture support? Sam On Tue, Nov 3, 2009 at 1:50 PM, Mike Swingler <email@hidden> wrote: > quoted text]]>
[...] Does your app have a CFBundleIdentifier? Without one, LaunchServices can't reliably track it's settings for your app. I've also found that if LaunchServices is being flaky about picking up changes to the Info.plist, sometimes I can get it "unstuck" by moving that app to another directory, and moving it back. To specify an OS to architecture minimum boundary, try adding a LSMinimumSystemVersionByArchitecture dictionary to your Info.plist. You can specify a minimum of i386=10.6.0, x86_64=10.5.0, and prioritize i386 above x86_64 with LSArchitecturePriority. Please see <http://developer.apple.com/Mac/library/releasenotes/Carbon/RN-LaunchServices/index.html> for more information about these two Info.plist keys. Regards, Mike Swingler Java Runtime Engineer Apple Inc.]]>
Folks, There was a discussion a while back on this list about 32bit & 64bit Java Preferences. In summary, Snow Leopard supports 32 & 64bit Java, and Leopard supports 64bit Java only. In our case, we want Snow Leopard to run 32bit (because we use native libraries that are only available in 32bit), but want Leopard to still run properly with 64bit Java (and we'll detect the architecture and not load the native libraries). So we need our JavaApplicationStub to have both 32bit & 64bit slices (since we don't want to build & ship two different apps) and whichever is preferred will be used. Mike Swingler suggested that we use LSArchitecturePriority in the Info.plist (as opposed to the deprecated JVMArchs key in the Java element in Info.plist). However, this does not seem to work right. The immediate issue we found was that altering the elements in LSArchitecturePriority in an existing Info.plist did nothing. It was as if it the order of the items in it (or the existence of it at all) just didn't matter. OTOH, right-clicking on the app and choosing whether to run in 32bit or 64bit mode did change the mode. Then we found that it seems like LSArchitecturePriority is being applied to new applications when they are installed. (For example, after running the pkg installer, it accepted the priority in order of LSArchitecturePriority.) However, the catch was that it was accepting the priority on Leopard too, even though there was no 32bit Java available. When installing an app into Leopard with an LSArchitecturePriority that had i386 before x86_64, Java failed to start (giving an error message). It seems like the only reliable way to prefer 32bit & fall back to 64bit if 32 isn't available is to use the deprecated JVMArchs element. Am I going about this the wrong way? Thanks for any help. Sam]]>
Hi, I am facing this issue with my app where the JPopupMenu and JMenu that are showing in my app do not disappear (or go away, get dismissed) if I click on another app. I would have to dismiss it myself by clicking outside the pop-up menu when inside my app. Anybody seeing this issue? [...]]]>
Hi Doug Zwick, [...] Thanks for your valuable suggestion. I tried the above approach. Everything is working fine with one exception. The only problem with this approach is, the frame inside which I am showing the captured image is not coming on top of MAC Menubar. [...]]]>
[...] It would have to be an Objective-C++ compiler, since JNF requires Objective-C. Compiling with just a C++ compiler would fail. [...] Sounds like it to me. At the very least, it's a documentation bug: failing to say whether it's Objective-C++ friendly or not. [...]]]>
On Oct 31, 2009, at 3:30 PM, Mike Swingler wrote: > quoted text
Ah, you've just made me realize there's been an error in my thinking about GCD. I've been assuming without questioning it that it is, at its core, an operating system wide thread pool, where the OS manages some total pool of available threads and these can do work for any application. In my imagination, one minute a thread might be servicing Java and another minute it might be servicing Finder. But that's nonsense. Somehow I'd read all this talk of system wide load management and forgotten that a thread lives within a single process. Of course, GCD could be implemented on some other abstraction - processes, messages etc, but there'd be some fierce problems to solve moving arbitrary blocks of code and data around between processes! And to do it securely, not plausible!?! So of course, however few or many threads GCD creates for the JVM belong to the JVM process. And following on from that thought, given you think it's OK, then indeed, why not let them stay attached to the JVM until they die? If there is a tradeoff to me made what I could do is give the GCDExecutor a boolean constructor parameter to let the caller decide, but even that might just be adding unnecessary complexity. Thanks again - I'll incorporate your feedback this week as time allows.
AndyT (lordpixel - the cat who walks through walls) A little bigger on the inside (see you later space cowboy, you can't take the sky from me)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
]]>[...] OK. I have that. I didn't realize *that* contained the code. [...] After some more probing, I noticed JNFAutoreleasePool.h that has the declarations: JNF_EXPORT JNFAutoreleasePoolToken *JNFNativeMethodEnter(); JNF_EXPORT void JNFNativeMethodExit(JNFAutoreleasePoolToken *token); [...]]]>
[...] Post what you see in JavaVM.framework. Also post your OS and JVM versions. A framework's library code isn't necessarily in a Libraries sub-dir. For example, the JavaVM.framework has a JavaVM symlink in JavaVM.framework, not one level down in the Libraries sub-dir. [...]]]>
On Nov 2, 2009, at 12:08 PM, Tomas Hurka wrote: On 2 Nov 2009, at 18:53, Paul J. Lucas wrote: [...] I did. It doesn't change the apparent fact that there are no libraries in said framework to link against. I think you also need a: -F/System/Library/Frameworks/JavaVM. [...]]]>
Hi Paul, On 2 Nov 2009, at 18:53, Paul J. Lucas wrote: On Oct 30, 2009, at 4:54 PM, Mike Swingler wrote: [...] -framework JavaNativeFoundation for more details see man page for ld command. Bye, References: [...] Re: Java application launch question Previous by thread: [...]]]>
Take a look at this: http://markmail.org/message/7jeg257227n2yc3r?q=java+singleinstancelistener&page=1&refer=ri377bshwpfbwpji Bill Janssen <email@hidden> wrote: [...]]]>
That may be an option - I'll take a look. Another possibility I ran into is to run the app as a launch agent with a .app file in /Applications to allow the user to start the UI. I created a plist for this and placed it into ~/Library/LaunchAgents, then used launchctl to start it; [...]]]>
I don't think you can launch an application more than once in a single user context (LSMultipleInstancesProhibited is for multiple user contexts). But you might try using the Java Web Start class "javax.jnlp.SingleInstanceService" here... Bill]]>