ansaurus

Question

Ant <input/> no longer working in Eclipse Helios (3.6)

Answer 1

+2 A:

It does look like bug 303869

I've submitted at feature request to Apple: Bug ID# 7840189 .
If we have the possibility to run the display code on the main thread via this new Dispatch object/method, I think that SWT can be made to work in applets without changing too much code, isn't it ?

Check also bug 288436 to see if it is relevant in your case.

VonC 2010-07-15 06:52:14

It looks relevant, yes. But they don't provide a path or workaround there, and the bug is not yet resolved (5 months later), so I still don't have a solution unfortunately.

Peter Kruithof 2010-07-15 07:02:09

Answer 2

+1 A:

Regarding my previous answer, both bugs are now closed as fixed.

bug 303869 in particular have been closed early this month with:

I think we can close this bug, it works well now with the latest Java Update for Mac OS X 10.6.
We can execute code on the main thread and now the UI is displayed. In the applet we use code like the following to instantiate the display:

com.apple.concurrent.Dispatch.getInstance().getNonBlockingMainQueueExecutor().execute(
new Runnable(){

            @Override
            public void run() {

                if( dDisplay == null )
                {
                    dDisplay = Display.getDefault();    
                    sShell  = SWT_AWT.new_Shell(dDisplay, cCanvas);
                    mLogger.info("Display is created");
                }
...
            } 
        } );
...

Thanks all and especially Mike from Apple to have solved the problem, it was not so much related to SWT IMHO.

For bug 288436:

Yes, the JNLP file has a small error that is triggering the problem.
Specifying "<j2se version="1.6*" />" in the "<resources>" tag without any other attributes is throwing off the JNLP parser and causing the later line "<j2se version="1.6*" java-vm-args="-XstartOnFirstThread"/>" to be ignored.
The two lines end up referring to two separate JVMs, and the first specification is 'winning'. That spec has no VM arguments on it, so the JVM starts normally, and the SWT is loaded on the wrong thread.

The option -XstartOnFirstThread is mentioned in bug 211625:

It's needed because Cocoa has a requirement that all user event dispatch must happen on thread 0.
Without -XstartOnFirstThread, Display will create an NSApplication on a non-main thread, and the SWT won't be able to pull and dispatch events from the non-main thread.

Be careful though with the -XstartOnFirstThread option: liek this bug mentions:

The reason for this is that the new Developer Mode is implemented in Swing, and the old Hosted Mode was implemented in SWT.
SWT requires -XstartOnFirstThread to be working on a Mac.
But this however breaks any java program using Swing.

So you cannot add -XstartOnFirstThread from version 2.0 and forward. On the older versions however it is still a requirement.

VonC 2010-08-30 19:06:23

Unfortunately my java version was already up to date. But I did find out the solution, I'm posting it below. The `-XstartOnFirstThread` bit in your answer set me on the right track: +1

Peter Kruithof 2010-08-31 07:53:19

Answer 3

A:

Finally found a solution for this problem:

First, make sure your Java version is up to date (1.6.0.20 at the moment of writing this). Second, change your Ant runtime arguments by doing this:

Open: Run > External Tools > External Tools Configurations
Select your build file
Open the JRE tab
In the VM arguments input box, add the following: -XstartOnFirstThread

Peter Kruithof 2010-08-31 07:58:36

Great to know you did find a solution :)

VonC 2010-08-31 10:23:35

Just updated my answer with some references and warnings regarding option `XstartOnFirstThread`

VonC 2010-08-31 10:30:20

ansaurus

tags:

views:

answers:

Ant <input/> no longer working in Eclipse Helios (3.6)

related questions