river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: Split JavaSpaces and JINI
Date Sat, 20 Dec 2008 10:21:39 GMT
Niclas Hedhman wrote:
> 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

Quite simply because it's essential to building decent applications on
top of the network if you want to account for it's oddness - like it
breaks, like it runs slow from time to time, like it has nothing
approaching the bandwidth of a CPU->memory bus.

This is at the core of Jini - if you want a local construct you probably
ought to avoid Jini that's not what it's for.

Now if you wish to make Jini do this, by all means do but I'd say it
should be a separate project because it's philosophically opposite to
what Jini is intended for.

> 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.

Sounds very ugly to me - can you explain more about how each type of
code really looks?

> Sorry to say Gregg (and others), I am getting really frustrated with
> the "There is nothing wrong!" attitude from 'old timers', when clearly

I'm getting frustrated with people accusing old timers of having a
"there is nothing wrong attitude".  I'm also fed up because these same
people seemingly haven't got any awareness of history (Note on
Distributed Computing?) or seemingly how building network applications
in software that don't require clusters (that fail anyway) to make them

I've made it clear elsewhere I agree with you on the setup stuff.  I
_don't_ agree with you on shifting Jini to a local model.  If you want
that why not use any one of the other enterprise technologies out there
that do this already?

> 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.

Why would I want to conquer the minds of a collection of developers that
don't want to build network applications in the style of Jini preferring
to make use or reliable databases, reliable networks and reliable
clusters (in case you're wondering, none of these are reliable - in a
small enterprise setup you might get away with it but it doesn't work
for large deployments and certainly not large websites unlike Jini which
does work).

> I am NOT your regular newbie; I adopted Jini 1.0/1.1 in a critical

Alas, some of what you're saying suggests otherwise - sorry if that's
hurtful but see my comments above re: remote vs local.  Perhaps you do
understand this stuff and we're just having a ommunication problem owing
to words used?

> 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
> wrong.

This is unrelated to the above discussion on philosophy though in the
vein of setup (which I've agreed is rough) this is true.
> 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!".

Again this is setup.

>  * "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.

Certainly I"m not saying otherwise but I do think there are good reasons
for this and addressing those issues mightn't be about technology so
much as the differences between two styles of architecture and design.

>  *  "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

Sure, provide local entry points but don't think for a second you won't
have to change the code when you go remote.

> 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
> possible.

That assumes that the containers in question actually have a permissive
environment.  Most don't - I know this as I've had to build a new
classloader model this week to work around JBoss's classloader mess that
doesn't allow multiple versions of code to co-habit at all well.  This
same kind of issue makes Jini integration hard.

> 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.

I agree with much of what you say but I have an issue with the in-JVM
stuff as  you've described so far because I think it's anti-network (and
Jini embraces the network).

> Cheers
> Niclas

Happy Christmas,


View raw message