river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Venners <bv-...@artima.com>
Subject Re: Concurrency and River
Date Thu, 04 Oct 2007 00:05:29 GMT
Hi Jeff,

On Oct 3, 2007, at 1:38 PM, Jeff Ramsdale wrote:

>> I had forgotten we talked about this several years ago with regards
>> to CruiseControl. How did your effort to distribute JUnit tests with
>> Jini and CruiseControl work out?
> Well, by the time I neared release I realized I'd done a lot of things
> wrong, or at least less than optimally. It was my first Jini project,
> and it showed. However it did (mostly) work and others have kept the
> code current (big thanks to Dan Rollo). My new designs (never
> implemented) involved JavaSpaces, but never went so far as to
> parallelize the running of TestCases. The goal of the project was
> really to parallelize builds on different platforms. Without realizing
> it I'd reimplemented some of the features of Rio regarding
> identification of a node's capabilities.

>> Anyway, the assumption in your response seems to be that if something
>> (such as Scala and SuiteRunner) isn't mainstream today that it will
>> never be mainstream. If that's true in general there's not much point
>> in trying to market Jini, because Jini isn't mainstream today either.
> I wouldn't want to suggest Scala and SuiteRunner won't ever be
> mainstream, but I don't think we should necessarily depend on their
> becoming so. Clearly Jini isn't mainstream and if we want it to be we
> should try to minimize the unfamiliar dependencies. (Think Jini
> configuration here. As brilliant as it might be many potential users
> are confused by it. There should be an easier starting point.)

>> My situation is that unlike the old days when I could take a few
>> weeks off full time to code up the ServiceUI API if I felt like it, I
>> don't have time to do stuff today that Artima doesn't have a chance
>> to make money from. I didn't really transform into a greedy person. I
>> hired people. I have to meet payroll now and that really changes your
>> perspective about what you need to do with your time. Some of you may
>> miss the old me, and I do too honestly, but that's how it is these
>> days. I have felt bad that I haven't had much time to contribute to
>> this project, and have been on the lookout for ways I could
>> contribute to River that also had potential to help bring revenue to
>> Artima.
> I completely understand. I used to have some funding to work on
> Jini.org and I no longer do. Time is hard to come by. In any case, I
> wasn't meaning to suggest SuiteRunner and Scala be left out of the
> loop--I think your argument for trying to position SuiteRunner as the
> de facto standard for Scala is a great idea. I was only suggesting
> that most Java users wouldn't want be be required to use those
> technologies to try out the distributed build technology. I could see
> a situation where the most advanced features required some
> understanding of Scala and/or SuiteRunner--that would be good for you
> and your business. But I'd hook 'em with a straight-up JUnit
> connection.
I see your point. The requirements for the new SuiteRunner should  
include that it can be used to parallelize JUnit and TestNG tests.  
SuiteRunner was always a bit more about running tests than writing  
them, and always allowed you to run JUnit 3 tests. We did some  
enhancements when JUnit 4 came along to support that, and that works,  
but never made a release, and then I decided to go Scala.

>> The missing context in my previous post is that I've made a business
>> bet on Scala. Artima will be publishing a Scala tutorial, and later
>> possibly other Scala books, and offer other educational materials.
>> And we're going to use Scala to write our software internally. I
>> started rewriting SuiteRunner in Scala because I want to use it
>> internally at Artima, and because I want to use it as a talking
>> point, an example, to promote better software practice in the context
>> of Scala at conferences.
> Sounds great!
>> What I realized yesterday is that with multi-core coming, if I
>> architected the new SuiteRunner from day one as a Jini-based
>> distributed system that can also scale gracefully down to one box,
>> then I could also talk about Jini and JavaSpaces at those
>> conferences, and help spread the word about River a bit while I'm
>> spreading the word about Scala. I think that with multi-core coming,
>> it honestly makes a lot of sense to architect SuiteRunner this way
>> anyway. How would I parallelize tests if I didn't use JavaSpaces? I
>> wouldn't even know where to begin.
> I think in the context of this conversation I'd like to make the point
> that multi-core is HERE, no longer "coming". You have to work to buy a
> machine that isn't multi-core this days. Just saw a number of Brian
> Goetz sessions on the No Fluff conference circuit, and he made that
> point loud and clear.
> I agree with your point above!
Well, you can get 2 cores today easily. But what's going to be  
interesting is when it is 4, 8, 16, 32, ..., 128 cores etc. With two  
cores you don't get that much more throughput compared to 32 cores,  
for parallelizable work. "Make test run 10 times faster" is more  
compelling than "Make tests run 1.5 times faster." I don't get the  
feeling people worry they are wasting CPUs today, but a few years  
from now, that may be on the forefront of their minds. The marketing  
goal with respect to River should be that JavaSpaces is one of the  
things they automatically think about when they want to exploit  


>> SuiteRunner was always a JUnit runner. It runs JUnit tests. But that
>> didn't help make it interesting to folks. Cedric Beust did get some
>> uptake with TestNG because he kept adding features and tirelessly
>> promoting it. But JUnit has improved since 1993, and I don't see a
>> compelling reason for Java programmers to switch from JUnit even to
>> TestNG honestly, and certainly not to the Java SuiteRunner. But the
>> Scala community doesn't really have a de facto standard testing tool
>> yet, and so I think there's a good chance I can get folks to use the
>> new SuiteRunner. It is a smaller community than the Jini community,
>> even, but to the extent Scala is adopted, SuiteRunner would then ride
>> that wave. I do agree with you that SuiteRunner would need to
>> continue to run JUnit tests as well, and also should be able to run
>> TestNG tests, so people can hook their legacy tests into it if they
>> start using Scala for writing tests.
> Good to hear. I think there's a lot of interest in unit testing and
> TDD currently. Should really help build demand for what you're
> offering.
>> Another thing that perhaps Artima could help with is I'd be open to
>> publishing a Jini book if we could figure out a way to market it. My
>> understanding has been that mainstream publishers won't touch Jini,
>> and that there isn't even a book that describes Jini 2.0. Is that
>> still the case? For example, a book focused on how to exploit multi-
>> core processors with JavaSpaces might hit a nerve a year from now. So
>> if anyone has a Jini book idea or an desire to contribute to one,
>> please contact me privately.
> Jan Newmarch did update his book last year:
> <http://www.apress.com/book/view/1590597168>
> Not to say there wouldn't be a market for another, particularly if it
> took a different slant. Might be an opportunity to play on the Apache
> River name too.
> Thanks for the conversation--good topic!
> Jeff
>> Thanks.
>> Bill
>> ----
>> Bill Venners
>> President
>> Artima, Inc.
>> http://www.artima.com

View raw message