JEP 103: Parallel Array Sorting - proposal, reaction to Mr. Harned post

[Janda Martin]

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