river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Hoffstätte <hol...@wizards.de>
Subject Re: Split JavaSpaces and JINI
Date Wed, 10 Dec 2008 11:43:30 GMT
Niclas Hedhman wrote:
> On Wed, Dec 10, 2008 at 5:23 PM, Dan Creswell <dan@dcrdev.demon.co.uk> wrote:
>> Personally I think a more interesting question is:
>> "What do you gain by not bothering with the Jini part?"
> Since you asked (take your pick);
>  1. An appealing programming model that is also suitable for
> single-JVM applications, which could (IF need arise!!) be complemented
> with a distributed version without change of the application sources.

Surprise! That was Gelernter's motivation behind Linda, tuplespaces and
the blackboard model. :)

> People tend to like solutions that are easy to start with and that can
> become powerful if/when that need arises. I think that the failure of
> the Jini folks (then and now) to acknowledge this is one of the
> biggest mistakes done. The same argument could be done for the entire
> Jini platform.

All true, though you're mixing conceptual R&D and delivery of the platform
as product. With the exception of GigaSpaces, Jini was never "productized"
or engineered for usability outside of Sun, and yes that shows. It's moot
to lament this today, and IMHO it's more constructive to look forward to
the ability to remedy these decisions. Also keep in mind that Jini
development started in ~98 or so - lots of concerns and constraints have
radically changed since then.

Ironically enough, when you look at "cloud" development, the resurgence of
secure mobile code and the networking war zone that is EC2 then it seems
that everything old is new again, just in time for the usual technological
10-year adoption anniversary. GigaSpaces and Rio and elastic-grid on top
use Jini, but don't advertise that fact because it would shut many doors
immediately. Advertise a _solution_, not a technology! This has been the
real failure of Jini. Well, that and the idiotic "device driver" meme.

>  2. With more light-weight implementations available, unit-testing of
> applications built-in on top of Javaspaces becomes a breeze. If anyone
> claims that unittesting with Jini is easy, please send me the abstract
> testcase I can use, because I am literally stuck.

no argument from me there.

>  3. Since JINI already have nailed the "it's too complex" coffin shut
> in the minds of the world's Java developers, I think it is important

"compared to what?"
No, really. It's easy to claim that "it's too complex" when one has not
done one bit of background research or even wants to distinguish between
inherent complexity and accidental complicatedness. Jini suffers from
both, and that realization puts a different light on the situation.

> that we not only say "Listen! It ain't that hard!", but actually
> provide a brand new toolkit (not app!) where the average developer
> after 10 minutes goes "Cheeze, this is so cool..." and clearly sees

"But I can do the same with JMS"
"But it's just like memcached"
"But I don't want to learn yet another API"
"But it's not J2EE"

These are actual quotes.

> that "Hey, I can use this with little or no impact now...", instead of
> the "Do it the Jini way or no way at all.". Javaspaces provides,
> IMVHO, an important stepping stone towards this goal. We can present

Yes it does, no doubt. It also requires an open mind instead of the
idiotic claim "waaahhh but I want memcached or ehCache and circlejerk my
own concept-free 5-minute-reinvention on top!!", which will inevitably follow.

> the Space programming model, showcase when/why it is useful, and inch
> the full-blown Outrigger into the developers mind without him/her
> actively taking the "Jini decision".

Sure. You can do that with GigaSpaces today: add JSpaces.jar and the Jini
jars to the classpath, use the in-VM factory bean from spring-modules or
GS' own OpenSpaces, and off you go in 5 minutes, inside eclipse and no
explicit Jini anywhere. I know because that's exactly what I did when I
started. And just to reiterate your point: yes, I also almost fell off my
chair as I started to understand the configuration process.

My point is that yes, so far the isolated development shows in the
usability, there are many things that can be done to make the technology
more approachable, but also that process needs to go both ways.

One key point would be documentation - not only "getting Started" but also
conceptual material for people have have more than 5 minutes attention
span. The articles on http://www.bbtech.com/ are excellent and provide a
fantastic overview of blackboard theory, applications and even explain why
the principles are difficult to demonstrate in "hello world" type
small-ish examples. Another would be GigaSapces' excellent Wiki (I am NOT
adovcating that we now go and wget -r the whole thing :-)

Other excellent points about the origins and history of Jini can be found
in the following JavaPosse podcasts, which for some reason are also not
very well-known:


They explain a lot of the obscure and undocumented history. However, they
also don't find their way into one's head on their own.

In other words: yes, fixing the project structure and the obscure (though
somehow charming) service names would go a long way towards embedded
operation and ease of use for beginners. And you started - great. Relax
and commit more, please. :)


View raw message