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 two modules requests different
FJPool settings.
public final class ForkJoinUtils {
// should this be replaced?
public static ForkJoinPool defaultFJPool() { ... }
public static byte[] parallelSort(byte[] a) { ... }
public static byte[] parallelSort(byte[] a, int fromIndex, int toIndex)
{...}
// with this?
public static SortTask<byte[]> createParallelSortTask(byte[] a) {...}
public static SortTask<byte[]> createParallelSortTask(byte[] a, int
fromIndex, int toIndex) {...}
...
}
Reaction to Mr. Harned post
I work as a Java SE software developer for several years. I think that Mr.
Harned opinion to freeze Java in software history ('30' years ago) is not good
idea.
JSR 166 Fork/Join is great contribution to make Java better (thank you very
much Doug Lea). Today CPUs just adds new cores so there have to be better
support for parallelism.
j.u.c package isn't only about sorting long arrays (huge overhead). Programs do
a lot more.
Thread, ThreadPool, FJPool and j.u.c are just small pieces in real application.
They are solid and can be extended/controlled to support specific needs.
I think that Mr. Harned should improve his own libraries to comply with his
objections. I looked at his source code, demos and I prefer j.u.c to his work.
Thank you everybody who works on Java
Sincerely
Martin JANDA
PS sorry for my english
