Re: Making an application "active" from java - Part 1

----- Original Message -----

> > This is not going to work (at least not with the suggested oasscript
> solution, I believe).
>
> When using the osascript as suggested in Mary's mail, the script needs
> the process name, not the application name. The process name, for my
> application when I tried this, is "JavaApplicationStub", independent of
> the application name. 'ps' shows the process as
>
>      1593  ??  R      0:03.96 /Applications/BlueJ/BlueJ
> 2.0.2/BlueJ.app/Contents/MacOS/JavaApplicationStub -psn_0_73400321
>
> I could make the suggested solution work by executing the script
>
>       "tell application \"Finder\" to set frontmost of application
> process \"JavaApplicationStub\" to true"
>
> but not using my application name.
>
> This is also the weakness of this solution: I have no idea what happens
> when more than one Java application is running...
>
>

There are a number of things you have to do to make the old-school process manager stuff correctly recognize your application as something other than JavaApplicationStub. I'm not currently on a Mac so this is from memory so some of it probably an approximation at best. But. First you need to actually rename the JavaApplicationStub executable to the application name. Contents/MacOS/JavaApplicationStub more or less changed to Contents/MacOS/ApplicationName. Although I still prefer to have my actual OS X a prelude script as described by Greg Guerin somewhere. Mine looking like...

 

#!/bin/sh

 

# To understand this, read 'man sh' below "substring processing".
# This can also be accomplished with the 'dirname' command,
# but it may not be installed.
here="${0%/*}"

 

# This should be the name of your native Java-app's executable.
cmd='CommandWrap'

 

# add here to PATH environmental variabie
export PATH="$PATH:$here"

 

# Execute the Java-app in the current process.  See 'exec' in 'man sh'.
exec "$here/$cmd" "$@"

 

Which in turn runs CommandWrap the actual renamed JavaApplicationStub. Actually I'm not sure I've verified all the AppleEvent handling and process manager related works correctly since making this script change, I should do that some time.

There is a corresponding plist property that needs updating to reflect this change, either the script executable or the renamed JavaApplicationStub.

That would be the CFBundleExecutable property as shown from appedit.java included with the appedit.zip on my page that plays with some of this...

 

  System.out.println("*** Verifying native executable");
  String execdir = new StringBuffer(APP_PACKAGE).append(fs).append("Contents").append(fs).append("MacOS").append(fs).toString();
  cfexecutable = (String)plist.get("CFBundleExecutable");
  File execfile = new File(new StringBuffer(execdir).append(cfexecutable).toString());
  if (cfexecutable == null) {  // Property not provided
   execfile = new File(new StringBuffer(execdir).append("JavaApplicationStub").toString());
   if (execfile.exists()) {
    System.out.println("No CFBundleExecutable parm property - ERROR, JavaApplicationStub present - OK");
    System.out.println("native executable JavaApplicationStub is set executable is " + isExecutable(execfile.getPath()));
   }
   else System.out.println("native executable - ERROR no CFBundleExecutable parm property and JavaApplicationStub missing");
  }
  else if (execfile.exists()) {
   System.out.println("native executable - CFBundleExecutable named " + cfexecutable + " found - OK");
   System.out.println("native executable " + cfexecutable + " is set executable is " + isExecutable(execfile.getPath()));
  }

 

Notice that also uses some runtime to verify file executable permissions are correct. Runtime can also be used to set them which might of been pertinent to a somewhat recent file permissions list thread.