Niclas Hedhman wrote: > On Thu, Dec 11, 2008 at 12:13 AM, Gregg Wonderly <ge...@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 work. 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, Dan.
