river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman" <nic...@hedhman.org>
Subject Re: Split JavaSpaces and JINI
Date Thu, 11 Dec 2008 02:58:27 GMT
On Thu, Dec 11, 2008 at 12:13 AM, Gregg Wonderly <gergg@cox.net> wrote:

> Help me understand please!
> import net.jini.core.transaction.Transaction;

^^^^ HERE ^^^^

JavaSpaces depends on Transaction. Perhaps you think it is rudimentary
simple to implement a Transaction system that are semantically
accurate with the Jini Transaction Specification at in-JVM level.

> import net.jini.core.lease.Lease;

^^^^ HERE ^^^^

Leases are a good thing. But again, without a light-weight
implementation, it makes my day miserable.

> import net.jini.core.event.RemoteEventListener;

^^^^ HERE ^^^^

This is probably controversial; Jini's use of local smart proxies is
brilliant, so why is not this fact used much more in the
specifications. Why are network protocol details shining through
everywhere? The notify() method should (of course? obviously not) take
a SpaceListener at the local interface level, and use the
RemoteEventListener hidden on remote interface.

Sorry to say Gregg (and others), I am getting really frustrated with
the "There is nothing wrong!" attitude from 'old timers', when clearly
the most clever technology have been unable to conquer every Java
developer's mind and toolkit, and having had 8-10 years to do so.
I am NOT your regular newbie; I adopted Jini 1.0/1.1 in a critical
application in 2001, where we ran both clients, servers and 'device
drivers' both locally and across the Internet with full blown Jini
infrastructure. At that time, it was 'somewhat painful' to get things
operational. When I now return (as a complete 2.x newbie), I notice
that things are still hard, perhaps even harder. Meanwhile (6 years!),
I have gone from a heavy and slow development process, to do things
much, much more light-weight and test driven. And when I now try to
integrate Jini into an open source framework I am working on, it gives
me more pain than I could imagine, mostly due to how hard it is to get
tests working. Sorry, but the whole Jini "setup mentality" is just

Calum; Stuff like Glyph --> Excellent, things in the right direction,
but it doesn't solve the underlying problems;

 *  "It is HARD to use Jini and/or Spaces in other projects". Maven
artifacts are becoming the preferred choice by many. How do we meet
that? How can I Jini enable (for instance with Glyph) and still test
that it works in a Jini environment, and not only relying on Calum
saying "Don't worry, it will!".

 * "Jini HAS FAILED to capture the developers' minds.", and I don't
care how much people here will jump up and down claiming that that is
not true.

 *  "Jini is an 'all-or-nothing' commitment.", which requires
decisions higher up in the organization, instead of developers. Such
strategic decisions are made at the golf course or over a $1000
dinner. We must provide in-JVM entry points and ride well inside
Tomcat and other containers, without requiring changes to neither the
JVM nor the container. Such feature should be advertised up-front and
not something one needs to go digging for whether it is at all

Well, I will stop arguing about what I think is wrong, and just go out
and make the changes I think is necessary. And funny enough, it is not
that much that needs to be changed. If I am not welcome to do so that
here at River, then fine, I bring the codebase elsewhere.


View raw message