Web Start: Invalid thread access

• Web Start: Invalid thread access 

• Web Start: Invalid thread access with SWT APPS in MAC

I m getting an invalid thread access error when starting my app with Mac OS X. It works fine under windows and Linux. That s what makes me think it s a SWT Mac OS X bug... Attached is a screenshot of the error /app .

Comment 1 Irwin 2004-05-20 16:03:33 EDT

Created attachment 10916 [details]
Mac OS X invalid thread access

I know this bug is going to be difficult to fix with only that info. But such a
general error makes me think : 1) either I miss something  2) or we are in big
trouble :)

Comment 2 Grant Gayed 2004-05-21 09:54:42 EDT

SSQ should we ever receive events in a non-UI thread?

Comment 3 Silenio Quarti 2004-05-21 14:41:50 EDT

How do you start your app? Do you run the "java_swt" executable?

Comment 4 Irwin 2004-05-21 20:48:52 EDT

My app is started directly from Java Web Start, from the browser.

I also started it directly command line under mac os X, with Java\ Web\ Start .

In both cases I have the same exceptions.

Comment 5 Andre Weinand 2004-05-24 11:17:29 EDT

Java Web Start is not supported with SWT based applications.

Comment 6 Tomas Nord 2004-05-24 12:57:24 EDT

Ouch... Will it ever be?

Comment 7 Irwin 2004-05-24 15:53:32 EDT

Java web start not supported ? This is weird.
1) many articles from IBM show how to use JWS & SWT. And it works like a charm
under Linux & Windows.
2) I don t think there is a need for JWS support. Everything Java is supposed to
run with JWS, and I m very confident on that point. If SWT does not support JWS,
it looks like SWT does not support Java somewhere.

I d like more clarifications on that point.... should it be the answer of that bug.

Comment 8 Irwin 2004-06-01 08:59:43 EDT

I was able to run the application from command Line instead of Java web start,
at my surprise.
I am used to run JWS & SWT under windows & linux. Is there any specific reason
why  it does not work with Mac. ? Shall we take the windows & linux
compatibility as a lucky fact ? 

Comment 9 Silenio Quarti 2004-06-01 11:39:25 EDT

Andre,

You know more about this problem than me. Please could you explain why we need 
the java_swt executable?  For a short answer, we need to run main() in the 
carbon UI thread.

Comment 10 Andre Weinand 2004-06-01 11:51:22 EDT

You find the full story why we need java_swt in comment 3 of bug #40003.

> I was able to run the application from command Line instead of Java web start,
at my surprise.
In MacOS X? If yes, what exactly did you do?

Comment 11 Irwin 2004-06-01 12:27:09 EDT

Yes under Mac OS X. I just run from command line using java , not java_swt.
So it appears to be a well known 'bug' of javaswt / mac OS X. I think we can
close this bug, unless you have other comments.

Comment 12 Andre Weinand 2004-06-01 15:32:23 EDT

And your app uses SWT ?

Comment 13 Irwin 2004-06-01 15:42:41 EDT

yes it does. This is the app described above, which when launched from javaws
gives the invalid thread access. When run from command line, it works fine.
Both tries under mac OS X.

Comment 14 Veronika Irvine 2005-06-07 09:18:04 EDT

*** Bug 98553 has been marked as a duplicate of this bug. ***

Comment 15 Andre Weinand 2005-06-24 07:21:02 EDT

I've debugged webstart with SWT on MacOS X and here is the result:
- the attribute java-vm-args="-XstartOnFirstThread" doesn't have an effect.
   As a consequence the Java VM runs in the wrong thread and SWT apps appear,
   but don't react to user input.
- I replaced /usr/bin/java with a shell script that passes a -XstartOnFirstThread
   to the original java VM. In this case webstarts aborts because it tries to launch AWT which fails
   because it runs in the wrong thread. This scenario shows that even if 
   java-vm-args="- XstartOnFirstThread" would be passed to the VM,
   running SWT would still not work.

This Catch-22 can only be solved by either fixing the SWT/AWT interoperability issues,
or by running a fresh Java VM for the application being launched via webstart (so that AWT and SWT
are not used within the same Java VM).

Comment 16 Andre Weinand 2005-07-20 06:34:32 EDT

Since I cannot solve the SWT/AWT interoperability issues, I'm reassigning bug to SWT inbox.

Comment 17 Steve Northover 2005-07-20 17:20:12 EDT

Todd, is there anything we can do on the Mac to have JWS start on the *right* 
thread?  

NOTE: If JWS uses AWT, then this is bug is another instance of bug 67384 and 
can possibly be closed as a dup.  When multiple operating system GUI threads 
work in the same process on a Mac, then JWS should work the same way it does 
on Windows and Linux.

Comment 18 Steve Northover 2006-06-05 10:46:57 EDT

Scott, now that we can interoperate with AWT/Swing, working with WebStart would be great.  Any ideas?

Comment 19 Scott Kovatch 2006-06-05 11:22:48 EDT

This will need some work on our part. I can make -XstartOnFirstThread a 'safe' VM option, so that it gets passed to the JVM, but the problem is that a lot of AWT code is executed long before the SWT's event loop starts. My current thinking is that we need the runloop running on thread 0, much like we do in the AWT.

Another possibility is to start up the AWT as we do now, but when the actual application is about to launch, shut down the NSApplication and let the SWT event handling take over.

Comment 20 Brant Hahn 2006-07-31 11:00:18 EDT

adding myself to the CC list

Comment 21 Brant Hahn 2006-07-31 11:12:47 EDT

Does this bug depend on bug #145890? (which was spawned from bug #67384)

Comment 22 Scott Kovatch 2006-07-31 11:18:08 EDT

Completely unrelated. 145890 involves embedding an SWT shell into an AWT window. This bug deals with the fact that Web Start on Mac OS X is starting up in such a way that the SWT cannot be used.

Comment 23 Steve Northover 2006-09-25 19:48:53 EDT

Any progress on this?  It would be nice for Webstart to work on the Mac.

Comment 24 Scott Kovatch 2006-09-25 20:05:31 EDT

Nothing new to report right now. We have some core problems with SWT and AWT running together that I need to address first. Once that happens I can look at having the SWT start after the AWT which is the root problem here.

Comment 25 Patrick _ 2006-11-06 14:32:59 EST

added myself to cc

Comment 26 Dimitry E Voytenko 2006-12-01 14:24:17 EST

added myself to cc

This is critical for us as well. Is there any dirty fixes at all?

Comment 27 Brant Hahn 2006-12-06 13:22:28 EST

Do we have any updates on this issue?  Just curious here...

thx

Comment 28 Scott Kovatch 2006-12-06 13:43:30 EST

See comment 24. This may not get fixed until the AWT can do work on the main thread.

Comment 29 Remi Nodet 2007-02-21 01:18:33 EST

It seems that the latest version of java 1.5.0 released by apple fixes some SWT-AWT problems. Does this mean we will be able to start SWT applications from java web start soon ? ;-)

http://developer.apple.com/releasenotes/Java/Java104R5RN/ResolvedIssues/chapter_3_section_10.html#//apple_ref/doc/uid/TP40005278-CH3-DontLinkElementID_26

Comment 30 Brant Hahn 2007-02-21 09:10:00 EST

We've been running 1.5 since the summer, and this bug still exists.  1.6 is the latest 'stable' version... I haven't seen if 1.6 fixes the issue yet or not since we are holding off from upgrading.

Comment 31 Johannes Rudolph 2007-03-14 18:00:52 EDT

added myself to cc

Comment 32 Scott Kovatch 2007-05-23 20:15:38 EDT

Lots of progress here, but unfortunately it requires a change to the JVM and Web Start, not the SWT. Look for an update in the next day or so.

Comment 33 Scott Kovatch 2007-05-25 11:20:41 EDT

Checked this in last night for our Java 1.5 in Leopard. To use this, you will need to let the JVM know you're going to use the SWT:

  <resources os="Mac OS X">
    <j2se version="1.5*" java-vm-args="-XstartOnFirstThread"/>
    <jar href="SWTWebStart.jar"/>
  </resources>

I will move to resolved/fixed when a public build with this fix is available.

Comment 34 Steve Northover 2007-05-25 12:06:19 EDT

We need to remember to update http://www.eclipse.org/swt/jws/ to include a Mac example and get rid of the warning.

Comment 35 Brant Hahn 2007-06-01 10:06:24 EDT

Ok, so let me understand this (correct me if I'm wrong here): the next public build for Java 1.5/1.6 on Leopard will contain this fix and when it's out there, we just need the reference to the SWTWebStart.jar in the JNLP?

Comment 36 Scott Kovatch 2007-06-01 23:11:48 EDT

Sorry, my previous comment wasn't clear:

  <resources os="Mac OS X">
    ....
    <j2se version="1.5*" java-vm-args="-XstartOnFirstThread"/>
    ....
  </resources>

The 'java-vm-args="-XstartOnFirstThread"' is the important part. The next public build of Leopard 1.5 will have this support, which is why I wrote the resources section this way. The JAR file was from a local test, and not relevant here.

I still need to merge it into 1.6, but I'm also not commenting when that will be released. I'll update here when that happens.

Comment 37 Ivan 2007-06-01 23:16:02 EDT

Hi, will this "features" available in Tiger ?

Thanks

Comment 38 Scott Kovatch 2007-06-04 12:02:13 EDT

I should be able to put this back into a Tiger update, but I make no promises as to when that will be right now.

Comment 39 Laurent Jourdren 2007-06-05 10:02:47 EDT

(In reply to comment #36)
> Sorry, my previous comment wasn't clear:
> 
>   <resources os="Mac OS X">
>     ....
>     <j2se version="1.5*" java-vm-args="-XstartOnFirstThread"/>
>     ....
>   </resources>
> 
> The 'java-vm-args="-XstartOnFirstThread"' is the important part. The next
> public build of Leopard 1.5 will have this support, which is why I wrote the
> resources section this way. The JAR file was from a local test, and not
> relevant here.
> 
> I still need to merge it into 1.6, but I'm also not commenting when that will
> be released. I'll update here when that happens.
 
  Does your fix works also with others java graphical toolkits that need "-XstartOnFirstThread" JVM argument on start like QtJambi ?

  Thread about the issue between JWS and Jambi under OSX:
  http://lists.trolltech.com/qt-jambi-interest/2007-03/thread00073-0.html

  How build native QtJambi jar for Mac OS X:
  http://lists.trolltech.com/qt-jambi-interest/2007-06/thread00003-0.html

Comment 40 Scott Kovatch 2007-06-05 11:47:23 EDT

Does QT-Jambi run its own event loop like the SWT does? Looking at QApplication's javadoc page, it looks like it does, so then, yes, this change is probably useful for QTJambi as well.

Comment 41 Scott Kovatch 2007-06-18 17:07:04 EDT

Fixed in the Leopard seed distributed at WWDC. If you have this build, you can verify that the fix is there.

Comment 42 James Kenny 2008-03-17 07:06:48 EDT

I noticed this bug is marked as fixed so does that close the book for Tiger compatibility? :(

Comment 43 Scott Kovatch 2008-03-17 13:29:27 EDT

(In reply to comment #42)
> I noticed this bug is marked as fixed so does that close the book for Tiger
> compatibility? :(

I can't recall right now if we back-ported this into the last Tiger update released at the end of 2007. I have this vague recollection that I did, but I'm not sure now.

I no longer work for Apple, but please file a bug at bugreport.apple.com to remind  someone that this can and should go back into Tiger.

Comment 44 Rafael Chaves 2009-06-17 21:25:15 EDT

Shouldn't this issue have a target milestone? That is usually the field used for reporting when an issue was fixed, whereas the Version field describes what version it was reported against.

Comment 45 Silenio Quarti 2009-06-18 10:47:43 EDT

This was fixed in the JRE, not in SWT. So there is no eclipse target milestone we can set.

Scott, do you call what java update fixed this?

Comment 46 Rafael Chaves 2009-06-18 10:50:09 EDT

Thanks for clarifying, Silenio. I guess the FIXED resolution is misleading.

Comment 47 Silenio Quarti 2009-06-18 11:02:24 EDT

Yes, it should have been NOT_ECLIPSE.

Comment 48 Scott Kovatch 2009-06-18 16:21:03 EDT

This was fixed in the released Mac OS X 10.5 (see comment #41) -- no additional updates needed. I'm changing the resolution to NOT_ECLIPSE since it was a Mac JVM fix that took care of it.

I'm almost certain it was not back-ported to 10.4, since it's not security-related.

Comment 49 Hendy Irawan 2010-03-31 18:10:06 EDT

Please update http://www.eclipse.org/swt/jws/ noting that this bug no longer applies with recent Mac OS X versions.

Comment 50 Scott Kovatch 2010-03-31 18:59:14 EDT

(In reply to comment #49)
> Please update http://www.eclipse.org/swt/jws/ noting that this bug no longer
> applies with recent Mac OS X versions.

Good catch -- the comment at the bottom of that page is indeed no longer valid.

I believe Carolyn owns the web pages, so I'll ask her to update it.

Comment 51 Carolyn MacLeod 2010-04-01 10:06:23 EDT

Done. I took it out of the SWT FAQ also.

Comment 52 Heiko Roth 2011-02-09 08:19:42 EST

Please reopen this bug because of Mac OS X 10.6.6 this bug exists.
I think, javaws ignores parameter -XstartOnFirstThread. This problem only occurs on launching application with Java Webstart.

Starting on shell only with java and parameter -XstartOnFirstThread does well.
Without this parameter, the same error occurs.

javaws -J-XstartOnFirstThread

doesn't work, too.

Comment 53 Felipe Heidrich 2011-04-11 15:09:16 EDT

Mike, Scott

Do you guys know anything about -XstartOnFirstThread being broken for web start with 10.6.6 ?

Comment 54 Mike Swingler 2011-04-11 16:05:33 EDT

(In reply to comment #53)
> Do you guys know anything about -XstartOnFirstThread being broken for web start
> with 10.6.6 ?

I do not believe we have changed the -XstartOnFirstThread code path at all in any of the Java updates for Mac OS X 10.6.

If you have specific steps to reproduce, I would suggest that you file a new bug.

Comment 55 Silenio Quarti 2011-04-11 16:23:35 EDT

I just tried the latest SWT code on 10.6.7 and found this bug#342488 which was caused by the changes released for bug#329456 on March 3th, 2011 (which is after the date of comment#52).

Other than bug#342488 everything seems to be working fine. I do not get an Invalid
thread access exception if the jnlp file specifies -XstartOnFirstThread properly. 

Heiko Roth, please try the test case attached to bug#342488 (note that you need to update the path in the jnlp file) and let me know if it works for you. I do not think this bug is back.

Comment 56 Heiko Roth 2011-04-13 09:07:26 EDT

(In reply to comment #55)
> Other than bug#342488 everything seems to be working fine. I do not get an
> Invalid
> thread access exception if the jnlp file specifies -XstartOnFirstThread
> properly. 
> 
> Heiko Roth, please try the test case attached to bug#342488 (note that you need
> to update the path in the jnlp file) and let me know if it works for you. I do
> not think this bug is back.

Thank you for the example in bug#342488. It worked out of the box.
We found the problem inside our jnlp file.

    <resources>
  <!-- REMOVED   <j2se version="1.6+" />  REMOVED -->
       <!-- Application Resources -->
        <jar href="javaclient-3796.jar" main="true" />
        <jar href="lib/apache-mime4j-0.6.jar" />
        <jar href="lib/commons-codec-1.3.jar" />
        <jar href="lib/commons-httpclient-3.1.jar" />
        <jar href="lib/commons-logging-1.1.1.jar" />
        <jar href="lib/json_simple-1.1.jar" />
    </resources>
    <resources os="Mac OS X" arch="x86_64">
  <j2se version="1.6+" java-vm-args="-XstartOnFirstThread" />
  <jar href="lib/swt-macosx.jar" />
    </resources>

We removed the first <j2se version="1.6+" /> entry and everything worked fine.
Thanks.

Comparing Eclipse and NetBeans RCPs

Eclipse RCP:

 

Eclipse RCP is a good platform once you get to know it, but even now that I feel like I understand it ok, I'm still doing more work and dealing with more complexity than I should. I can  understand the need to support a Java version that has been dead for years but I don't need to be punished for that on a daily basis.

 

NetBeans :

Oracle has already made a strong statement of commitment to the NetBeans Platform. Ted Farrell, Chief Architect and Senior Vice President of Oracle: "The NetBeans Platform is very important to a lot of our customers, who are actually building their products on top of the NetBeans Platform. We want to make that the best platform that we can for doing that for you."

 

Source different Blogs and Post.

RCP applications are developed exactly the same way with NetBeans or Eclipse

Most of differences between Eclipse RCP and NetBeans RCP development are just in terminology. In NetBeans we speak of modules, in Eclipse, of plugins; we use the NetBeans Platform instead of Equinox, we have Matisse instead of Window Builder. We also have an extension registry with extension points on both platforms, to contribute extensions, and an RCP application is a set of provided modules/plugins + some of your own extensions.

It is the same thing; we can develop them the same way with either Netbeans or Eclipse.

Eclipse RCP vs NetBeans RCP starts with… SWT vs Swing

When getting started with RCP development, here is the main thing encountered, and this is technically the main difference between both Platforms: Netbeans uses Swing as a widget library, whereas Eclipse uses SWT. In my opinion, that's not a big difference, but when it comes to choosing between Netbeans and Eclipse, there is a bigger impact when you start a new application or migrate a legacy one. People will probably choose the product with their favorite widget API.

This is the main technical difference, but it is really minor. In my opinion, this difference is not important enough to make a distinction.  Let's look deeper, to see what these solutions provide as extensions and so on.

NetBeans is not an OSGi platform, but…

It provides exactly the same necessary features as what is used when developing Eclipse RCP plugins. MANIFEST has different keywords, but there are still modules (or plugins in Eclipse terminology) with their own classloaders and so on.

Additionally, there are a lot of integrations with OSGi. The NetBeans platform can run along with an OSGi container, and it can handle OSGi Bundles. For RCP development, the NetBeans platform provides all the necessary OSGi stuff RCP developers use. During his presentation, Geertjan highlighted some NetBeans OSGi integration by starting Netbeans over Equinox and loading EMF bundles in NetBeans.

NetBeans has an publisher, Eclipse has an ecosystem

That's probabably one of the key arguments in the debate, and it has a very strong influence on both products. The entire NetBeans roadmap is piloted by Oracle which is wholly responsible for it. At Eclipse, there is no such single pilot. The Eclipse Fundation oversees Eclipse development, but there is not ONE single publisher, there are lots of contributors from different companies. Eclipse is not only modular technically, it is also modular in term of organization. There are several projects that are developed by independent groups. There might be some dependencies between them, but in the end, you have different teams developing different projects.

NetBeans is a single project developed by a company, whereas Eclipse is an amalgamation of different projects developed by a community of individuals and companies. Then…

NetBeans is homogeneous, Eclipse is heterogeneous

Eclipse developers must admit this: NetBeans is much more homogeneous than Eclipse. And this is true in several domains: UI, ergonomics, code quality (which by the way is quite good, according to NetBeans users who find it less buggy than Eclipse code). This is a plus for NetBeans since users who know how to do one task with NetBeans will easily figure out how to do another. It is pretty user-friendly, especially for users who are new to the Java IDEs world.  They can easily leverage most of the IDE and the platform; thanks to its high consistency (standardization). Thus NetBeans rapidly becomes straightforward to use and leverage.

Compared to NetBeans, Eclipse seems difficult to fully manipulate. There can be a lot of differences between 2 projects, in term of usability (creating a web project is quite different than creating a plug-in project, as you often need to learn how to do something), and also in term of quality. The Eclipse platform quality is very good, and so are most of the mature projects, but there are some others are more buggy and makes the IDE less comfortable. Also, when you reuse some code from other projects, you often have to tweak it to get it working well. For Eclipse developers like me, that's no big deal; but for new users or for people coming from NetBeans, that can be a major issue.

and…

NetBeans has some tools, Eclipse has a lot of projects

The openness of Eclipse provides something very different from NetBeans. NetBeans is one product with different tools. Eclipse is one platform with different projects. These projects are much more numerous than NetBeans components, and they allow you to take several roads at the same time. Eclipse has a kind of wide usefulness that can handle classic IDE problems, Mobile-Development
problems, Model-Driven problems, Rich Internet Application problems, and so on.

Source:

http://www.bonitasoft.org/blog/eclipse/comparing-eclipse-and-netbeans-rcps/