On Saturday, October 22, 2011 7:46:40 AM UTC-4, Russel wrote:
>
> On Sat, 2011-10-22 at 04:32 -0700, opinali wrote:
> [ . . . ]
> > The single serious criticism I've ever heard about j.u.c. and the
> continuing
> > work of JSR-166, is that it furthers the paradigm of shared-memory
> > concurrency. But, like it or not, it's the appropriate thing to do at the
> (...)
>
> Well here we have a real bone of contention. Java reified shared memory
> multithreading in the early 1990s. It was an error then and is certainly
>
We don't need to debate this -- the past is the past, and like it not this
is the paradigm of concurrency embedded in Java and in billions of existing
LOC of Java apps, this this must be supported forever and also improved
continuously in the extent that's possible. I don't claim that we cannot
have a new concurrency model as an additional option (hi @Kirk), I just say
that the existing system must keep moving'. Deprecating the shared-memory
concurrency model is not realistic - it's not like, say, deprecating entity
beans for JPA or deprecating Swing for JavaFX; it's not a single library
that is only used by a subset of applications, it's a core feature that is
used directly or indirectly by 100% of all code (apps, core libs,
third-party libs... including the implementation of alternative languages
and concurrency frameworks). Even the introduction of j.u.c. in JDK 5 was
not a radical break with the past; I for one, had significant legacy code
written with straight threads/monitors or with other libs (like Apache
commons-pool) that I was able to quickly review to benefit from j.u.c.
> an error now -- at least as being pushed as the "one true way" of
> concurrency since it makes parallelism very hard. Why should it remain
> the "one true way" in Java? It is this closed mindset that is a big
> problem with Java. Java should have actor libraries, dataflow
> libraries, CSP, that applications folk use. Certainly shared memory
>
I agree, but I think this kind of innovation already happens in the right
places - the JVM-languages communities (Clojure, Scala etc.). We Java-lang
diehards may complain about learning and adopting a new language as
precondition for a new concurrency model (for one, I'm envious of Clojure's
persistent collections), but that's the only *good* way to do it, because
Java lacks even the slightest amount of support for these other models. For
one thing, there's no real support for immutability ('final' is not good
enough, we need full "constness" support a la C++).
Something like an actor library could be added to core Java, but
1) who would shoulder the effort? Oracle is busy enough improving the core
paradigm (as it should), including hard low-level optimizations like lock
elision etc. Concurrency is not everything, there's a ton of other
big-ticket RFEs that are pet ideas of many hackers, should Oracle do them
all?
2) and even assuming that Oracle has the resources to implement all our pet
RFEs, should all of them be thrown into the JRE? Many people already
complain of bloat when APIs that *are* used by a massive number of apps,
like XML / Web Services stuff, are added to the core...
3) so maybe they add actors, only to make 50% of the community pissed of
that they didn't pick some other next-gen concurrency idea, such as STM?
4) what to do when people start claiming for language syntax support for the
new concurrency system? Add tons of extra syntax on top of the already big
and hard-to-evolve Java language?
A+
Osvaldo
> multithreading is an important framework level technique, but no
> applications programmer should ever have to use such a low level model
> of concurrency and parallelism.
>
> GPars (http://gpars.codehaus.org) brings all of these things to Groovy
> and Java programmers. JCSP is a CSP framework for Java. DataRush is a
> commercial offering from Pervasive that offers dataflow. These models
> thrash explicit use of shared memory multithreading for applications
> development.
>
> Please can we ditch the idea that Java means using shared memory
> multithreading and that to use other models we have to use other
> languages. It is not true and it is damaging in the face of ubiquitous
> parallel hardware.
>
> --
> Russel.
>
> =============================================================================
> Dr Russel Winder t: +44 20 7585 2200 voip: sip:russ...@ekiga.net
> 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>
>
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/javaposse/-/DPdstDGotp4J.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
