Well, lets me honest though, many applications don't require all that Jini does. Bob building a desktop application which he never envisions going distributed or parallel outside of threading and he is going to think Spring, OSGi, NetBeans module system versus something like Jini. So, many applications don't need what Jini provides, versus a Spring which works from command line applications to full blown JEE. So, we're always going to have an up hill battle. I don't specifically know how to address that, but showing how to make intranet web service and other types of service discovery possible using Jini, database server location, etc automatic application configuration, hive bots, distributed RFID readers maybe using Java and cheap low end linux machines (something factories and groups with many small resources on location can use), etc. Then we can have more and more users.
Then, yes, we certainly need to have quicker starter development times. I think one very good route will be to have good Eclipse and NetBeans tooling. Look at annotations to get the simply aspects going quickly. Work out what all the comlexities are. We can work out complexities by coming up with a target list of application types, building examples for those, and then gleaning where things can be simpler. I'm all for changes and making things simpler. I just want to know what those changes will mean for how things will work after they are made...branches and forks. Too, I wouldn't mind starting a side project if someone want so to begin studying those application types and building examples. Once we get those together I can write an article for Developer.com on using River with NetBeans (maybe once we get the namespace changes?). Anyways, we'll need some publicity as well. Does anyone else have a site they are able to write articles? I can add to the NetBeans DZone (http://netbeans.dzone.com/). Maybe some others can do the Eclipse ones. 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 ----- Original Message ---- > From: Calum Shaw-Mackay <[EMAIL PROTECTED]> > To: [email protected] > Sent: Thursday, December 11, 2008 4:36:35 AM > Subject: Re: Split JavaSpaces and JINI > > To my mind - if you can't get something up and running within 10 > minutes, no amount of 'but it's cool' will save you. Jini doesn't have > the groundswell that other projects have for instance Spring that will > keep a developer looking at it and the docs for a couple of hours > before they get something useful happening... > > We have to get the 'download'-'edit'-'build'-'aha this is great, why > haven't I used this before' cycle down to as quick as possible.... it > took me a week of wrangling to go from Jini 1.2 to 2.0 - quite simply > it's not a good sign.... > > Yes Jini makes the hard network things easier - but working _with_ > Jini should be made easier, and quicker in the first instance..... yes > we have all the security aspects and they're very good.... but you > can't drop new people into that quagmire straight away.... to be > honest, I think it's scaring people off > > 2008/12/11 Jools : > > > > > > 2008/12/11 Niclas Hedhman > >> > >> > >> > >> 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. > > > > When Jini, and JavaSpaces where first conceived many years ago now things > > were in a very different state to what we have now. > > For a start the language has been refined, the JVM is now very stable and is > > very efficient compared to those early days. > > We have lots of nice new features, and some excellent tools to make our > > programming days so much easier. > > > > But here in the river incubator we say 'bah!' to all these new tools, and > > state that what we have is good enough. Well actually no. > > We are not leading the curve, we are some way behind now. > > > > The last few projects I have worked on, the developers wont entertain > > 'download a zip, unpack, shuffle the jars, curse, read the docs' type > > approach. > > They just want to add the dependency to their pom, and off they go. > > > > I asked a friend who has been involved in this technology for a longer long > > time, just when was the last time you used norm, or mercury ? > > Exactly. I think I fired them up for a test, maybe 7 or 8 years ago. So why > > do I seem them clogging up my release download ? > > > > Where I'm basically heading here, is.. lets get radical. nicals, if you want > > to change stuff. Do it. Prove it works. Get people using it and off we go. > > It's how apache got where it is today. It's where the name came from, people > > supplying patches to make it better. > > > > There are lots of cool toolkits for developing services using this > > technology, river is the bottom layer. The enabler. > > Lets focus on making it easier for these toolkits to grow by listening to > > the needs of these developers, not dictating the state of the world. > > > > However, I have to admit. I'm not really debating anymore, I'm doing. If it > > means a split away from river, then so be it. And to be honest, it's already > > happened. > > So many times I see "I've made a local change to allow..... blah blah blah", > > so why wasn't it easy to get that change into the code base in the first > > place ? > > > > So I guess it comes to this. Is river just a place where Sun has parked > > jini, so legacy codebases can get access to the old code, or is it a place > > where we can start to build the tools for the next generation of distributed > > systems ? > > > > --Jools > > > > > > > > > >
