----- Original Message ---- > From: William Surowiec <[email protected]> > To: [email protected] > Sent: Sunday, December 14, 2008 1:43:07 PM > Subject: Re: Split JavaSpaces and JINI > > I have been a sad and silent reader of several threads regarding the future > of River/Jini/JavaSpaces. I do not wish to add to the heat of the > conversation and, unfortunately, I am not confident I can add to the > illumination provided. >
Illumination is just the light. What wave length are we operating on is the important part. We have to get to the specifics and everyone involved needs to understand the specifications, what is provided, why and what is solved by the different pieces, etc. One could perhaps the Jini specifications for being so clear in some ways, but that is good from a developer working on Jini versus a developer using perspective; though it really does benefit one, regardless of how they are working with or on Jini, to read those specifications and understand them well. I think the list of things we can start fixing and addressing is a good place to start. Folks just have to dig in and get dirty before they can see where to apply them and why they make sense. > I am currently reading Practical API Design: Confessions of a Java™ > Framework Architect by > Jaroslav Tulach. (It is a decent read on a difficult topic, I heartily > recommend it.) > Indeed. > I can understand the desire to maintain backwards compatibility. But I side > with the group pointing out adoption has been lower than one might expect > for such an interesting and useful resource. I do not attribute the reson to > any of the negative adjectives offered as a description of programmers. I am > sure it is true for some but not as many as it would take to explain the low > adoption. I believe - without being able to prove it - the reason is more > likely the api we have does not address the needs (time to learn is one) of > the adoptees this technology warrants. (Tulach makes a point regarding > java's mail api being optimized, but not for users just interested in > reading and sending mail.) > Sure, first one has to identify those needs and know what it is they want before they know where they are going however, and those needs are broad in the case of Jini. Terminology and design and discussion of those things only gets one so far. The specification of Jini addresses a fine domain which can be used and applied broadly as evidence by Newton (Infiflow), Rio, GigaSpaces, Harvestor, and others. Those tools are probably what most are looking for, but it depends on their specific needs as all those are a little different, and use Jini for very similar yet different system components. Me, I think the core can take many of the things they are doing and make things better for an acceptable and usable (usability and toolset) lowest common denominator. That would be one which fit into a simpler stand alone application, a simpler network application or web service framework, or smaller devices etc and even be scaled up with extra work, as those systems do, into something similar to those tools to be used in different situations more easily. The kicker, just like NB RCP, Jaroslav's first born, there is only a certain level of a lowest common denominator one can target before they are into many domains trying to solve an abundance of issues which are not necessarily the core problem domain of the subset, and subprojects are fine, but the core can't be one or the other, but has to serve many. Now, taking some of the more popular domains such as web applications, EJB, RCPs, and standalone usages isn't so bad as long as those things are usable for a broad range of things, and are sub-projects, extensions really, of the core which folks in those domains can more easily use, but I think the worst thing Jini can do is be key holed into specific technologies in the Java stack. It currently is not. Right now, if one reads the Jini specifications, they are pretty clear and well written, and the problem domains which can be complimented with the technology start to jump out at you, and with some effort those things can start to be addressed now by using the API. Much like reading about different Java packages without having great documentation from the user/consumer perspective and not really a full set of documentation and tutorials which *just work* without issue. Basically those specifications don't detali packaging solutions or how and where to get information for systems that use that, and that is really good as a code base can be just about anything as long as classes can some how be derived from it; they could be smart cards one inserts into a system with other secure information on them. So, part, I would say most, of the issue is getting off the ground and running. There are gaps here and there with when and how to use the technology. For instance, there isn't a very straight forward solution for just taking the Jini toolkit, setting up a project, running services, putting together a distributed system, and testing all that out. In most cases there is plenty of boiler plate code or a set of different services which must be used together in a little unclear manner. Folks are unclear which classes to instantiate and what to set to get started. Too they are unclear for this or that situation or domain how to handle all these things together let alone how to package things for delivery. To me that is the biggest problem and not the domains that Jini can be used or the API design itself. You take NB or Eclipse RCP. There is plenty of cohesion and decoupling in the different APIs and plugins etc. You can take them and build a lot. Now, some things are lacking in documentation in this or that area, and the decoupling, though good from a complexity reference point as to what you can do, becomes mentally complex. Once you have the pieces down from a documentation stand point they become simpler and simpler as the decoupling gives you freedom you need to do this or that and not be too constrained and makes better and better sense once you get into it. Point is, without a community, a good set of FAQs, and some good documentation and tutorials, from the outside in Eclipse and NetBeans are horribly complex and non-starters to start using. The clarity gained from those community offerings can not be overstated. Spring is another fine example of such things; from a simple standalone container no, but with all its features yes. JEE the same. So, there are some, lets say broad, domain things which can be bettered in the APIs, and from a community standpoint Jini can be improved. However, from the ground up, Jini isn't bad or horrible, and the sources are not bad either, and starting from scratch would be silly. It handles a lot and works with a lot of things and does a lot of things, and none of it key holes you into this or that path. > I believe - again no proof - well meaning individuals have been trying to > raise this issue. I wish they had a better hearing in this forum. > I think there is a good way for folks to be heard with the few of us here; there really are so many of us on the list it seems. The issue is that folks have to dig in and understand what it is Jini solves now, why and how, and where the pain points are before they start trying to toss out the baby with the bath water. I think everyone is in agreeance to try to solve the pain points and make things better however. Wade ================== Wade Chandler, CCE Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member http://www.certified-computer-examiner.com http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam http://www.netbeans.org
