com.apple.concurrent.Dispatch in the modular JDK
Andrew Thompson
lordpixel at me.com
Mon Sep 21 22:05:22 UTC 2015
That seems reasonable.
The question of whether the Java platform should play nicely with power management and whether threadpools are the right abstraction for that is a worthy one but keeping this little known API around isn't going to solve that.
In any case there's always my own implementation which predates
Apple's that folks can use if they want to.
http://pixel.recoil.org/code/rococoa/
Andrew
> On Sep 21, 2015, at 5:25 PM, Phil Race <philip.race at oracle.com> wrote:
>
> An update on this. We have not found any widespread use of this API
> The expectation (nascent plan) is that this package will not be carried
> forward into the modular JDK. I suppose it is possible some new JEP may
> revive it as a standard API for in JDK 10 but there is no plan for that.
>
> -phil.
>
>> On 05/19/2015 09:28 PM, Andrew Thompson wrote:
>> A few years ago I had a brief email exchange with Doug Lea I the idea of providing an SPI so platforms could plug in implementations for a "default" ExecutorService. The idea was this could be a regular fixed thread pool or something more exotic like libdispatch, which is, after all OS managed and supposedly plays nicely with power management etc.
>>
>> I didn't take the idea any further, but something similar cropped up when lamdas were added in Java 8, the idea of a default mechanism for parallel lambda execution.
>>
>> I still think there's a good idea in there. The notion of a default thread pool that could be backed by more native code on various platforms. But that whole infrastructure would need to be created. It's more like a JEP. If that were to exist then the Dispatch class would be a natural way to implement on OS X.
>>
>> Andrew
>>
>>> On May 19, 2015, at 8:01 PM, Phil Race <Philip.race at oracle.com> wrote:
>>>
>>> Apple's JDK 6 provided the non-standard "com.apple.concurrent.Dispatch" class
>>> which was a means for Java code to access Apple's "libdispatch".
>>> To quote the documentation at
>>> http://www.coderanch.com/how-to/javadoc/appledoc/api/com/apple/concurrent/Dispatch.html
>>>
>>> " Factory for |Executor|s and |ExecutorService|s backed by libdispatch.
>>> Access is controlled through the Dispatch.getInstance() method,
>>> because performed tasks occur on threads owned by libdispatch"
>>>
>>> The class carried over into Oracle JDK for OS X and is there all the way up
>>> to current JDk 9 dev builds.
>>>
>>> The question is what to do with this class in the 'modular JDK' where
>>> we need to decide on the 'supportedness' of many APIs and what
>>> to do with them as a result.
>>>
>>> There is one Eclipse bug from 2010 where one of the methods was
>>> added to support embedding SWT in AWT applets in the browser :
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=303869
>>>
>>> but that was for JDK 6 and SWT can't be embedded in the current JDK 7/8/9
>>> Java Plugin for OS X which runs out of process .. so that usage is moot.
>>>
>>> So the current thinking is that since we do not know of anyone who
>>> uses this class that it should be unsupported in JDK 9 and not
>>> visible in the modular JDK image.
>>>
>>> So .. any comments ?
>>>
>>> -phil.
>
More information about the macosx-port-dev
mailing list