David Holmes and others keep pushing the Fork-Join framework for inclusion in JDK7 while this framework is an utter calamity. http://www.coopsoft.com/ar/CalamityArticle.html
The latest framework update makes it even more complex without addressing the fatal flaws (archaic work-stealing algorithms, faulty task management, lack of scalability and others). This is further proof that the architect is totally alienated from understanding the needs of application developers. I love Doug Lea. He has done wonders for the advancement of concurrent programming in Java. His concurrent utilities have made code better and programming easier. However, he is a professor with absolutely no commercial application development experience (malloc is a systems program.) This is why his framework is so lacking in industry professional attributes. Doug Lea has been tinkering with these same classes for the past eleven years. The framework is based on papers written in the 1990’s for techniques popular before then. In those eleven years, many more advanced, superior Fork-Join frameworks have emerged: [yes, I maintain three of them] http://coopsoft.com/JavaProduct.html http://supertech.csail.mit.edu/jCilkImp.html It is not too late to address the issue. Notwithstanding the deference the committee has given to the architect for his enormous contribution to Java, it is not worth the harm to core Java to including this framework in JDK7. Deference granted for including Classes that had absolutely nothing to do with concurrency into the original concurrency package (Executor, Future, etc.) The Fork-Join Classes also have nothing to do with concurrency. In fact, the architect specifically warns users not to use any concurrency methods as this may break the framework. Deferred to JDK8 are 486 extra classes and interfaces, having nothing whatsoever to do with concurrency, the architect wants to add to core Java to support the framework. The time to stop this is now. Ed Harned On Mon, Feb 21, 2011 at 8:44 PM, David Holmes <[email protected]>wrote: > FYI > > David Holmes > > -----Original Message----- > From: [email protected] > [mailto:[email protected]]On Behalf Of Doug Lea > Sent: Tuesday, 22 February 2011 11:21 AM > To: [email protected] > Subject: [concurrency-interest] ForkJoin Improvements > > Another round of improvements to ForkJoin framework is > now available in the usual places (see below). The main > change is an overhaul to core control that better avoids > creating or restarting more threads than needed. You'll > probably see better overall performance too. > Also, exceptions stemming from user errors are now > more informative. > > Please try these out let us know about any problems. > Pasting from http://gee.cs.oswego.edu/dl/concurrency-interest/index.html > > > jsr166y versions > * API specs: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/ > * jar file: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166y.jar > (compiled > using Java6 javac). > * Browsable CVS sources: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166y/ > > java7 java.util.concurrent versions > * API specs: http://gee.cs.oswego.edu/dl/jsr166/dist/docs/ > * jar file: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166.jar > * Browsable CVS sources: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/ > * Browsable CVS TCK test sources: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/tests/tck/ > > You may be able to use these versions now, without waiting for JDK > releases, > by > obtaining jsr166 jar and running java using the option > -Xbootclasspath/p:jsr166.jar (You may need to precede "jsr166.jar" with its > full > file path.) > > _______________________________________________ > Concurrency-interest mailing list > [email protected] > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > >
