"One thing I think has hurt Jini a bit in the Java community is that it doesn't offer a high-level programming model per se. Jini is more a set of principles accompanied by several specific technologies, each with their own API's. You use certain utilities to handle discovery and lookup, or specific methods to use Jini transactions or events. But it has nothing quite the same as a J2EE API. It offers terrific mechanisms, but doesn't impose a specific over-arching development policy. Developers can't immediately read a book or a spec, see a specific enterprise or corporate IT ROI problem, and learn at an API level where Jini fits within their applications and architectures," says Sean Neville in this Artima.com interview:
It sounds weird, but the wide applicability of Jini has indeed hurt it a bit. Even after all these years I still find it hard to explain to newbies how Jini could fit into their ICT-worldview. There is not one place (like federating small devices), but many, which makes it hard for those new to Jini to get a clear picture of what it can be used for. On the other hand, it might be an advantage since that way Jini won't be pushed into a small corner and will be tried for many problems. There is probably not one killer-app for Jini, which might be for the better.