Both JEP 103 and JEP 108 are interesting to me because they remind me of
something I've discussed a couple of times with one of the engineers working on
the JDK at Apple. (I'll not name him solely because his input was a casual
'that sounds interesting' and I don't want to imply he endorses this
On 10/05/11 03:53, Kasper Nielsen wrote:
On 05-10-2011 05:08, Andrew Thompson wrote:
So is there any convergence between these ideas? Should we be thinking about
adding a default ForkJoinPool to the platform, or should we be thinking about
adding a default ExecutorService to the platform,
Ther
On 05-10-2011 05:08, Andrew Thompson wrote:
So is there any convergence between these ideas? Should we be thinking about
adding a default ForkJoinPool to the platform, or should we be thinking about
adding a default ExecutorService to the platform, which may or may not be a
ForkJoinPool based
Both JEP 103 and JEP 108 are interesting to me because they remind me of
something I've discussed a couple of times with one of the engineers working on
the JDK at Apple. (I'll not name him solely because his input was a casual
'that sounds interesting' and I don't want to imply he endorses this
Hi Janda,
Thanks for the comments.
On 4/10/2011 7:48 PM, Janda Martin wrote:
I hope that this is correct mailing list to comment JEP 103.
It certainly is.
Proposal: provide static methods for creating sort tasks. This allows
developers to have full control over ForkJoinPool.
I'd persona
I hope that this is correct mailing list to comment JEP 103.
Proposal: provide static methods for creating sort tasks. This allows
developers to have full control over ForkJoinPool.
There can be problem with one shared defaultFJPool() in multi-module
applications (like Netbeans platform) when
Re: In opposition to JEP 103
I oppose the JEP 103 proposal for four major reasons as stated in this PDF:
http://coopsoft.com/dl/Oppose103.pdf
If preferred I can post the text here.
Ed
Posted: http://openjdk.java.net/jeps/103
- Mark
