The more I read Jan's tutorial, the more I realize I should take back what I said. It's really not half bad. The earlier chapters might be a bit heavy for beginners but I'm quite impressed with how extensive the remainder of it is. It covers a very broad spectrum of topics and the more I read the more interesting it gets :) I'm up to chapter 6 out of 28 so I guess I'll give a more complete review when I'm done reading it all.

Sorry I was very unimpressed by IncaX. I was expecting something more polished/professional looking. In all honesty I only tried it for 3 mins, was unimpressed and uninstalled it.

(I hope my post is not a duplicate but my first entry apparently vanished) The perception of Jini being a solution without a problem is frequent - but it's a false perception. For instance, looking at the presentations at the 10th Jini Community Meeting (www.jini.org) people could find a lot of people using it with success, mostly in the finance field. Sometimes I've got the impression that people using Jini is too shy outside the Jini community. My personal experience is with a system for delivering real time telemetry data to Formula One racing car teams. One third of the teams have been using Jini on this purpose since 2005, including the last year winner. Jini and Rio were the perfect solution to the problem - I don't think any other thing could do. Last but not least, I agree that Jini-out-of-the-box is not a good starter. Perhaps people don't know that there are some frameworks built upon it (as the cited Rio) which support a container/component paradigm and many other things and definitely make it easier to use it.

There is this much voiced problem of perception about jini in the first hand. However those who still struggle with this idea, I believe, are not worthy of using jini anyway. if they can not overcome this now simple perception how can they utilize a tool creatively. Probably jini should be promoted by software architects. I think Jini could be called a language about architecting systems, a tool to create tools, a tool to create architectures. Second problem comes with the documentation for a newbie. It is not easy to distinguish where the spec ends and implementation starts for those new comers. That was the case at least for me. There's some overhead to start seeing what one can do with jini. Probably for this problem a good body of use cases with clear examples can pave the way. Even some code templates can give a head start. So that newbies can "fill in the blanks" and immediately see some results.

It's not for hardware? Really? It was communicated like that! Well, this is the most frequently received reply when one mentions Jini. Jini is great for SOA and demanding/flexible solutions. Jini was SOA long before it was a buzz-word Sun should make it clear once and for all, Jini's intial idea might have been for hardware products, but Jini has never reached that goal, it did way better! We've seen proof of that!

With so many different development libraries and tools on the web, you really have to grab people right out of the gate if they're completely new to the technology you're promoting, and it has to be a good experience. When someone downloads something to try out, they want something that is quick and easy to install, and an comes with an example application or two they can try right away. It has to just work. If a user's first experience ends up being, "That was really hard to get running" or "I couldn't even get the examples to work", you lose a developer, and worse, anyone they talk to about it. How many times have you not looked into a particular technology because a co-worker whose opinion you trust said something like that? You might look into it, but if it starts to look like your experience will be the same astheirs, you'll probably drop it. There are many examples of this on the web. Has Jini ever fallen victim to this? Unfortunately, I think it probably has. I think that's a real shame, because Jini is great technology. Is it fun or easy to put an installation package like that together? No, but it's needed, and not just as a side-project that's in conjuction with Jini. It has to be there in that initial download. Just having a great framework is only part of it. If it's a pain to install or doesn't have a cool application to play with after it's installed, not many people will use it. If you're able to hook developers with an easy install and some cool applications, it'll start to spread by word of mouth. Remember that trusted friend or co-worker? They probably told you about the last cool thing you should go take a look at. Just something to think about.

We developed a fairly large distributed app with Jini 1.0 several years ago, and dealing with Jini was difficult. I recently went in to upgrade the app, and decided to bring it up to Jini 2.1 and take advantage of the new JavaSpace API. I was hopeful that some progress had been made on the usability front. To my dismay, it was even harder and more complicated to use. I realize that in that timeframe, Jini was made secure, and security is difficult. I realize Jini is doing a lot of hard things under the covers, and conceptually, Jini is not that hard from a developer point of view. It's just when you're working with it, you run into a lot of complexity and frustrations, so I'd put that as the #1 issue. Easy interop with other languages would be #2. After those are solved, someone can write a killer app. Then when people want to join in and use Jini, they won't quit in frustration. Ruby on Rails is taking off now because of ease of use.

Jini needs a community endorsed container (something like the the seven project - but hosted by apache). A Container won't solve everyones problem - but it should make life easier for the masses. Jini needs to work out of the box in conjunction with a JEE container like glassfish. That is, it should be possible to write jini services and clients hosted under glassfish without running in to classloader madness. Jini also needs to support easy deployment via https/http through firewalls., This should happen out of the box - with minimal configuration requried.

Others have commented that Jini looks like a solution looking for a problem. I observe that with all the talk about SOA, it seems like the mainstream is busy applying the solution, or least sorta the solution, to "the enterprise". Maybe Jini's task is to sit on the sideline and show theworld a model of how it could be done. A shining example of pureness for others out there in the SOA trenches to get inspiration from. It seems to have happened to other great technologies (Lisp, Smalltalk come to mind) as well ;-)

Having used Jini for a good period of time I think there are three main things that Jini must have in order to survive and gain wide-spread acceptance.

• Concise docs. There are a lot of docs floating around and a few links here and there to them. But a structured course in Jini doesn't exist. There is no way for a beginner to quickly learn the vitals, a intermediate to quickly dig deeper, an experienced developer to quickly find references (I couldn't even find the JavaDoc for 2.1 last week). Most open source projects have a good way to deliver information and Jini should just copy that.
• On the wire Jini uses Java serialization. This technology is old, cumbersome and error prone in many ways. New technologies such as SDO and others have filled the gaps for many systems who don't ever want to see serialVersionUID errors ever again. I'd like to see Jini team up with SDO/JSON/XML and all the glorious binding frameworks out there to help make Jini on the wire more robust and attempt to tackle the issues with versioning that always come up.
• Integration with frameworks has to be put into core Jini. Jini out of the box most work with frameworks like Spring (or some distributed DI system). This integration will make it simpler for existing projects to expand by simply changing the plumbing from Spring to Jini-Spring.

One of the important things about Jini is that it is a tool which you can use to create a solution for a particular class of problems. The contention is that Jini can be used to solve a large set of problems related to distributed computing. To use Jini, you have to understand the problems of distributed computing (be familar with Peter Deutche's falacies) and then recognize the features of the Jini platform which can help you solve those problems. It's not magic, just science.

It is just a big pain to deploy, and it needs better abstractions on top of it (like servlets to web apps). And a lot more information, tutorials, ....

I think Jini needs to have more information for a developer who doesn't know what it is and how it can help to solve problems. I personally still don't know in which kind of problems it would be helpful to use Jini. This information should be clear and short, to attract the attention of developers. When they need more detailed information, they can download the binaries with all the documentation.

I would appreciate a list of business cases where the use of Jini would suit best. As an architect I always need to know which technology is being used ideally to solve a specific problem. Some sort of whitepaper giving some insight would be good. Does there exist such a whitepaper? The whitepaper should be for technically experienced people. No marketing blah, blah - please.

Maybe it needs a better name. I have read at least about 5 times what jini is but i always forget. It is too similar to jni.

…that being: a clear explanation of what Jini is and why we, as developers should care. Is Jini a solution in search of a problem? Is Jini the coolest thing in the world and the guy with the killer app just hasn't heard of it yet? Eager readers want to know!

They've bee trying (and claiming to have succeeded) for years in making Jini the next best thing since sliced bread. It's not worked yet and I see no reason it should succeed in the future.

Before many users will install Jini, they need to have a reason and the installation needs to be easy. Neither alone is sufficient. This is essentially the same conversation being had about the JRE. The bundling strategy helps, but really isn't enough unless you have a monopoly.