Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Standard Widget Toolkit (SWT) » SWT application cannot be started with Oracle Java 7 on Mac(org.eclipse.swt.SWTException: "Invalid thread access" is printed when starting application)
icon4.gif  SWT application cannot be started with Oracle Java 7 on Mac [message #912347] Thu, 13 September 2012 11:52 Go to next message
Albert Pikus is currently offline Albert PikusFriend
Messages: 70
Registered: October 2009
Member
Hi,

my SWT application won't start from Eclipse on Mac (Mac OS X Lion) when using 64-bit Oracle Java 7 (build 1.7.0_05-b05), I get ***WARNING: Display must be created on main thread due to Cocoa restrictions.

It's a known requirement that -XstartOnFirstThread program argument must be passed when running SWT applications on Mac, which I have set inside Run > Debug Configurations > Arguments > Program Arguments for my debug configuration. It seems that Eclipse simply ignores this argument when running SWT app on Java 7, like it wasn't there. As soon as I switch to Java 6, everything is back to normal again. I'd be surprised if no one else encountered this problem.

The other problem that surfaced with Oracle Java 7 is starting (SWT) application bundled as a JAR. I have built a single JAR that also bundles other JAR libraries that my application uses, using the approach that worked perfectly for me for a long time, on all platforms (Windows, Mac and Linux), please see: http://stackoverflow.com/questions/2706222/create-cross-platform-java-swt-application

For starting my program on Mac, I use the following shell script:

#!/bin/sh

PROGRAM_DIR=`dirname "$0"`
PROGRAM_DIR=`cd "$PROGRAM_DIR"; pwd`
cd "${PROGRAM_DIR}"

for FILE in ./*.jar; do
  CLASSPATH="${CLASSPATH:+${CLASSPATH}:}$FILE"
done

exec java \
-jar \
-Xms256m -Xmx512m \
-XstartOnFirstThread \
-cp "$\{CLASSPATH\}" \
application.jar


When I try to start my application on Mac with Oracle Java 7, this is the error that is printed in Terminal:

Error: Could not find or load main class application.jar

It seems that Java thinks that application.jar is a main CLASS that should be run. Again, this problem only appears with Java 7 and I don't have a slightest idea what is causing it.

I have no problems running my application with Java 7 on Windows, not from Eclipse and also not as a standalone JAR:

Has anyone encountered similar issues with Java 7 on Mac?


Thanks in advance, best regards,

Albert

[Updated on: Mon, 17 September 2012 14:31]

Report message to a moderator

Re: SWT application cannot be started with Oracle Java 7 on Mac [message #912452 is a reply to message #912347] Thu, 13 September 2012 15:57 Go to previous messageGo to next message
David Wegener is currently offline David WegenerFriend
Messages: 1445
Registered: July 2009
Senior Member
Your second problem is likely caused by a change in the way that Java 7 parses arguments. The -jar argument is supposed to be followed immediately by the jar file name. You have it separated by a number of other arguments. Move the -jar to the end right before application.jar and see what happens.
Re: SWT application cannot be started with Oracle Java 7 on Mac [message #912790 is a reply to message #912452] Fri, 14 September 2012 07:35 Go to previous messageGo to next message
Albert Pikus is currently offline Albert PikusFriend
Messages: 70
Registered: October 2009
Member
David Wegener wrote on Thu, 13 September 2012 11:57
Your second problem is likely caused by a change in the way that Java 7 parses arguments. The -jar argument is supposed to be followed immediately by the jar file name. You have it separated by a number of other arguments. Move the -jar to the end right before application.jar and see what happens.



Hi,

thank you for your fast answer. Regarding my second problem, you are right about the arguments order, although I established after a few tries that the correct order is the following:

#!/bin/sh

PROGRAM_DIR=`dirname "$0"`
PROGRAM_DIR=`cd "$PROGRAM_DIR"; pwd`
cd "${PROGRAM_DIR}"

for FILE in ./*.jar; do
  CLASSPATH="${CLASSPATH:+${CLASSPATH}:}$FILE"
done

exec java \
-XstartOnFirstThread \
-jar \
application.jar \
NOTE THE EMPTY LINE!!!!
-cp "$\{CLASSPATH\}" \
-Xms256m -Xmx512m \


It's particularly odd that if there is no empty line before -cp "$\{CLASSPATH\}" \, java.lang.ClassNotFoundException: -cp is thrown.


Other reasonable combinations that I tried are also throwing exceptions.

This arguments order produces java.lang.ClassNotFoundException: -Xms256m
exec java \
-XstartOnFirstThread \
-jar \
application.jar \
-Xms256m -Xmx512m \
-cp "$\{CLASSPATH\}" \


This arguments order produces SWTException: Invalid thread access (and dialog stating "(SWTException: Invalid thread access) Try adding -XstartOnFirstThread to your command line arguments" is shown):

exec java \
-jar \
application.jar \
-Xms256m -Xmx512m \
-XstartOnFirstThread \
-cp "$\{CLASSPATH\}" \


Considering that only the topmost example works (with obligatory additional line break before the -cp argument), I would say that Oracle Java 7 for Mac has problems with arguments parsing. This could also be a reason for Eclipse Run configuration that doesn't correctly recognize -XstartOnFirstThread argument anymore.


Best regards,

Albert

[Updated on: Fri, 14 September 2012 07:37]

Report message to a moderator

Re: SWT application cannot be started with Oracle Java 7 on Mac [message #913054 is a reply to message #912790] Fri, 14 September 2012 17:11 Go to previous messageGo to next message
David Wegener is currently offline David WegenerFriend
Messages: 1445
Registered: July 2009
Senior Member
What your test say to me is that -jar has to be the last option on the command line. Anything after the -jar argument is taken to be the program arguments and not vm arguments.
Re: SWT application cannot be started with Oracle Java 7 on Mac [message #915454 is a reply to message #913054] Mon, 17 September 2012 10:07 Go to previous message
Albert Pikus is currently offline Albert PikusFriend
Messages: 70
Registered: October 2009
Member
David Wegener wrote on Fri, 14 September 2012 13:11
What your test say to me is that -jar has to be the last option on the command line. Anything after the -jar argument is taken to be the program arguments and not vm arguments.


You are right, my arguments order was simply wrong. I should just check the output of "java" command, which is the same for Java 6 and Java 7:

Usage: java [-options] class [args...]
           (to execute a class)
   or  java [-options] -jar jarfile [args...]
           (to execute a jar file)

where options include:
    -d32          use a 32-bit data model if available
    -d64          use a 64-bit data model if available (implies -server, only for x86_64)
    -client	  to select the "client" VM
    -server	  to select the "server" VM
    -jvm	  is a synonym for the "client" VM  [deprecated]
    -hotspot	  is a synonym for the "client" VM  [deprecated]
                  The default VM is client.
                  
    -cp <class search path of directories and zip/jar files>
    -classpath <class search path of directories and zip/jar files>
                  A : separated list of directories, JAR archives,
                  and ZIP archives to search for class files.
    -D<name>=<value>
                  set a system property
    -verbose[:class|gc|jni]
                  enable verbose output
    -version      print product version and exit
    -version:<value>
                  require the specified version to run
    -showversion  print product version and continue
    -jre-restrict-search | -jre-no-restrict-search
                  include/exclude user private JREs in the version search
    -? -help      print this help message
    -X            print help on non-standard options
    -ea[:<packagename>...|:<classname>]
    -enableassertions[:<packagename>...|:<classname>]
                  enable assertions
    -da[:<packagename>...|:<classname>]
    -disableassertions[:<packagename>...|:<classname>]
                  disable assertions
    -esa | -enablesystemassertions
                  enable system assertions
    -dsa | -disablesystemassertions
                  disable system assertions
    -agentlib:<libname>[=<options>]
                  load native agent library <libname>, e.g. -agentlib:hprof
                    see also, -agentlib:jdwp=help and -agentlib:hprof=help
    -agentpath:<pathname>[=<options>]
                  load native agent library by full pathname
    -javaagent:<jarpath>[=<options>]
                  load Java programming language agent, see java.lang.instrument
    -splash:<imagepath>
                  show splash screen with specified image


So first come VM arguments, then -jar followed by a jar file name and optional program arguments. It still seems funny to me that Java 6 permitted wrong arguments order.


Thank you again for your help, best regards,

Albert
Previous Topic:SWT DateTime - SWT.NONE
Next Topic:Enabling focus listeners on the composite container
Goto Forum:
  


Current Time: Fri Mar 29 00:37:55 GMT 2024

Powered by FUDForum. Page generated in 0.03224 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top