Re: OS/X Java native bug

> On Mar 19, 2023, at 1:02 PM, Alan Snyder wrote: > > Your comments don’t make sense to me. > > You either post an event to run the code on the main thread or, if you are on > the main thread, you run the code directly. > > Running the code directly is what invoking a block does. > > How

Re: OS/X Java native bug

> On Mar 19, 2023, at 11:48 AM, Michael Hall wrote: > > > >> On Mar 19, 2023, at 10:50 AM, Alex Zavatone wrote: >> >> Would it make sense to intentionally cause this in one test case and then >> try dispatching on another queue at an intentional lower priority? >> >> I’m just

Re: OS/X Java native bug

> On Mar 19, 2023, at 10:50 AM, Alex Zavatone wrote: > > Would it make sense to intentionally cause this in one test case and then try > dispatching on another queue at an intentional lower priority? > > I’m just brainstorming here to create a specific case that we know causes it, > then

Re: OS/X Java native bug

> On Mar 19, 2023, at 10:37 AM, Alex Zavatone wrote: > > So while I am waiting for my coffee to actually start working, which > approaches do we think make sense here? > > When starting up, check if thread == main and if so, do one thing, else do > the other? > > If this is correct, what

Re: OS/X Java native bug

> On Mar 18, 2023, at 4:46 AM, Michael Hall wrote: > >> On Mar 17, 2023, at 7:49 AM, Alan Snyder > > wrote: >> >> block() means invoke the block > > > Not exactly and it still seems unnecessary here. > > It appears to convert the block to a selector and then

Re: OS/X Java native bug

> On Mar 18, 2023, at 4:46 AM, Michael Hall wrote: > > The main differences seeming to be that it takes a pass through the CFRunLoop > doing an invokeBlockCopy After seeing this (java_md_macosx.m JVMInit sameThread is true)… /* * We cannot use dispatch_sync here,

Re: OS/X Java native bug

> On Mar 17, 2023, at 7:49 AM, Alan Snyder wrote: > > block() means invoke the block Not exactly and it still seems unnecessary here. It appears to convert the block to a selector and then to invoke it. Eliminate the comments and NSLog’s and I think the following is equivalent and a bit

Re: OS/X Java native bug

> On Mar 17, 2023, at 7:49 AM, Alan Snyder wrote: > > block() means invoke the block > >> On Mar 17, 2023, at 5:34 AM, Michael Hall via Cocoa-dev >> wrote: >> >> >> >>> On Mar 17, 2023, at 6:51 AM, Michael Hall wrote: >>&g

Re: OS/X Java native bug

> On Mar 17, 2023, at 6:51 AM, Michael Hall wrote: > >> > > Sorry, I looked at your link and am still not sure this is correct if you are > already on the main thread. > Searching shows this used enough places you would think it has to be correct. Again, I guess maybe I’ll try a little

Re: OS/X Java native bug

> On Mar 17, 2023, at 6:31 AM, Michael Hall wrote: > > > >> On Mar 17, 2023, at 4:07 AM, Saagar Jha wrote: >> >> The implementation of -[ThreadUtilities performOnMainThreadWaiting:block:] >> does the right thing here, which is calling the block directly if it’s >> already running on the

Re: OS/X Java native bug

> On Mar 17, 2023, at 4:07 AM, Saagar Jha wrote: > > The implementation of -[ThreadUtilities performOnMainThreadWaiting:block:] > does the right thing here, which is calling the block directly if it’s > already running on the main thread: >

OS/X Java native bug

This was just brought to my attention on a java mailing list. An option was added to java startup options on OS/X -XstartOnFirstThread so the code starts on the main Appkit thread. Currently if a java Swing application starts with that option it hangs.

Re: Question about Info.plist's

> On Aug 19, 2020, at 10:04 PM, Ben Kennedy wrote: > > >> On 19 Aug 2020, at 7:45 pm, Michael Hall via Cocoa-dev >> wrote: >> >> Something else I’m curious about is doesn’t this somehow invalidate any >> application signing that’s been done? > &g

Re: Question about Info.plist's

> On Aug 19, 2020, at 9:04 PM, Michael Hall wrote: > > > I’m not familiar with the Plistbuddy that’s been mentioned. I see that is in fact builtin. Wasn’t aware. Something else I’m curious about is doesn’t this somehow invalidate any application signing that’s been done?

Re: Question about Info.plist's

> On Aug 19, 2020, at 11:07 AM, Gabriel Zachmann via Cocoa-dev > wrote: > > Question: > > Is there a way to use a key/value that was defined earlier in the plist file > to define a value for a later key? > Maybe off-topic but this used to be supported for Java applications for pre-set

Re: Thoughts on Cocoa

> On Oct 4, 2019, at 2:41 PM, Lars C. Hassing via Cocoa-dev > wrote: > > > On 4 Oct 2019, at 21.00, Jens Alfke wrote: > > The people I hear complaining about this are those who, like you, didn't move > to Cocoa. Carbon was a _temporary_ transition API*. It was necessary when Mac > OS X