Niclas Hedhman wrote: > On Wed, Dec 10, 2008 at 5:23 PM, Dan Creswell <[EMAIL PROTECTED]> 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: http://javaposse.com/index.php?post_id=131159 http://javaposse.com/index.php?post_id=133510 http://javaposse.com/index.php?post_id=135906 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. :) Holger
