Sun is going to hand JINI over to Apache

Discussions

News: Sun is going to hand JINI over to Apache

  1. Sun is going to hand JINI over to Apache (32 messages)

    According to an email sent to the javaspaces user's list, JINI will be handed over to Apache, reflecting Sun's perception of a need to update and revitalize the technology. In addition, the web site for JINI will be updated to be more open and accessible for people not familiar with the space, starting with the elimination of the perception of a "gated community" due to the old licensing (the SCSL).

    The changes are designed to kickstart the use of Javaspaces, in part to leverage Sun's new Grid computing service, and in part to possibly revive technology that isn't exactly new, but that has never really had the mass appeal it could have.

    Are you using grid computing at all? What do you know about it, or want to know about it?

    Threaded Messages (32)

  2. To be clear, it's going to be proposed as a new project in the Apache Incubator, and subject to acceptance by the PMC of the Apache Incubator. While I don't foresee any problems at this point, I do believe that this distinction is important.

    This is an exciting change, and I among others look forward to continue helping the JINI community make this transition.

    geir
  3. For one ASF has a rule that there is no "parking" of code there. Like if there are no (Sun?) developers that will code, it should not get in.

    .V
  4. For one ASF has a rule that there is no "parking" of code there. Like if there are no (Sun?) developers that will code, it should not get in..V

    That is correct - finally, we agree on something! :)

    This is one function of the Apache Incubator - to ensure that a diverse and active community forms around the code. If it doesn't, it won't graduate, and will simply be "retired".

    However, I'm certain that won't happen with this.

    geir
  5. For one ASF has a rule that there is no "parking" of code there. Like if there are no (Sun?) developers that will code, it should not get in..V
    That is correct - finally, we agree on something! :)This is one function of the Apache Incubator - to ensure that a diverse and active community forms around the code. If it doesn't, it won't graduate, and will simply be "retired".However, I'm certain that won't happen with this.geir

    I surely hope not - I've been working with Sun for a period of time on this and we have a nice long list of potential committers to choose from. We think initially it'll be some guys from the core engineering team and myself but it's still up for debate.
  6. Hi Geir,
       You can finally throw away all that EJB crap and use some serious containers, not to mention service discovery. :-)

    Seriously though, I hope it goes through, there are some amazing implementations we've implemented in the banking world using this technology. Options Exchange drivers, pre-trade and post-trade matching engines, OMSs, it's great stuff.

    It will provide a great compliment to many of the existing technologies, including J2EE.

    -John-
  7. Jini is v. interesting[ Go to top ]

    Yes, Jini fits in well with Apache because it is nicely distributed.

    However, like anything else stuck in the incubator, it doesnt become a full project unless it passes some criteria, including "has an active dev and user community". Code is not enough, Apache wants people using this stuff and developing it ---it is not a dumping ground for failed technology. Which, to be ruthless, Jini is (currently), at least compared to its vision.

    I know people that use JavaSpaces for dispatch of things; tuple-spaces are interesting ways of sharing work. Even so, XML-based spaces are nice because they are more platform neutral; I could dispatch work to be processed by a C++ or Python client just as easily as some more Java stuff.
  8. JINI is prime time ready[ Go to top ]

    I've used JINI v1.2 up until 2 years ago.

    It solved easily and quickly the very hard task of resiliency and robustness unlike any other existing technology.

    I designed and wrote a Session Manager to bridge between Radius servers and Siteminder for vodafone italy. Mobile traffic generated 100+ requests per second to my component.

    By being plain Java, I could manage to have endpoints through Orbix and a socket server on the other end (no useless J2EE contract). Plus the fancy GUI to show the customer, but that would simply be service client.
    Manage pools exactly as we needed, so we had to write our own.
    Manage timeouts and all sorts of errors in the system (the 20 Radius servers would each fail once in a while).
    Manage TX as we needed, through Multi-Master Slave-By-Subscription writes.

    But the real beauty was minimizing the involvment of system engineers. No need to have highly skilled ones. No need to document pages and pages of manuals for robustness operations and configuration.

    And we proved that to scale, all the customer had to do, would be to start up more instances of either masters or slave services.

    I am now back in the J2EE world, websphere and weblogic have big GUIs that make you think the technology is superior.
    It is ok, because the projects aren't that important or demanding.
  9. Hi Geir,   You can finally throw away all that EJB crap and use some serious containers, not to mention service discovery. :-)Seriously though, I hope it goes through, there are some amazing implementations we've implemented in the banking world using this technology. Options Exchange drivers, pre-trade and post-trade matching engines, OMSs, it's great stuff.It will provide a great compliment to many of the existing technologies, including J2EE.-John-

    Don't you mean gerongo ? While your at it, get rid of the spring elephant eh John ? Plug plug ..
  10. Don't you mean gerongo ? While your at it, get rid of the spring elephant eh John ? Plug plug ..

    I'm not quite sure I understand your question, if it is a question. I've not used "Greongo" (presuming you mean Geronimo), JPMC where I recently worked used its own lightweight J2EE stack (called Tigger internally) run by Steve Neiman, one of their lead architects.

    As for Spring, yes I'm a fan of Spring, it has it's issues but it's a lot more flexible than raw J2EE. Spring has been already been integrated with Jini and JavaSpaces by the way.

    -John-
  11. I've read a little about JINI. It's sort of interesting.
    I've worked on Grid Computing project using Open Source Globus Toolkit (GT3). At the time that I was working on GT3, it was still developing & was difficult to do certain tasks.
    Reading about Jini it looked more promising & I hope that it'll take off & not be dormant.
  12. Excellent[ Go to top ]

    This is one of the best technologies out and Sun has hidden it behind its obsession with J2EE for years. Jini solves a multitude of problems and issues that were never really satisfied with "classic" J2EE. Some of the brighter companies combined the two technologies but it was the west coast Sun guys that really kept this from the lime-light it deserved.

    I hope, finally, we might get to see some serious exposure on this simple but powerful technology.

    I shall be talking about this along with other other grid/caching technologies in the TSSJS-E in June.

    -John-
  13. I think it is a bit late for giving the Code to apache Foundation .
    btw , It is a big move from Sun to give its Grid computing code base as Apache licensed .
  14. The sun grid codebase[ Go to top ]

    The sun utility computing codebase is not jini based. It is a mixture of N1GE and a hodge podge of other stuff. All bery basic and uninteresting.

    There was an early effort to create a Jini based solution for Sun Grid, but the management changed while we were developing it. The new management decided to do something quick and dirty and wait until the J2EE and N1 product teams caught up. And so they cancelled our Jini based efforts.

    There are some other pilot projects with Jini and grid computing but the SunGrid team is not really using them.
  15. Hope they do the same with JMF[ Go to top ]

    Hope they do the same with JMF (Java Media Framework). I dont even know if it is still alive.
  16. JMF? Pretty dead[ Go to top ]

    Hasn't been really maintained in the past 7 or so years ...

    Of course, the major problem with something like JMF is that you need to implement codecs, and software patents are a killer argument in that area. See Sun's pulling of MP3 support out of JMF.

    cheers,
    dalibor topic
  17. It is a good move[ Go to top ]

    Jini is a proven technology and I hope this furthers the adoption of this technology

    -Venkat
  18. Nice![ Go to top ]

    Nice to see jini getting into incubation, it's neat technology. Will this include the test suites and so on?

    cheers,
    dalibor topic
  19. This is good news! Jini is a very well designed technology, everythings oriented around services...as in SOA. ;-)

    I for one am grateful that this is happening.
  20. US Navy will be happy[ Go to top ]

    Does that mean ASF is now supporting US Navy directly? Because the last time I heard about JINI in production was someone talking about wired stuff for sub marines. "It's just great to have some new devices, say weapon systems, plugged in that can be controlled automatically ..." or "Just assume there is a partial failure, say you got hit, and you can move controls from one side to another..."

    Jokes aside - hopefully this helps JINI gaining some momentum since it's an impressive technology that lacks proper public awareness.
  21. Why did this never take off?[ Go to top ]

    What I never understood is why such a brilliant technology as JINI never really took off, but remained in its niche instead. The concept on its own is overwhelming, so I guess the implementations must be lacking?

    On the other hand - and in relation to Apache - I had the same question concerning the Avalon Project some years ago. :-\ I guess it just must be a marketing issue: J2EE simply seems to be more rewarding to vendors.

    Lars
  22. Why did this never take off?[ Go to top ]

    What I never understood is why such a brilliant technology as JINI never really took off, but remained in its niche instead. The concept on its own is overwhelming, so I guess the implementations must be lacking?On the other hand - and in relation to Apache - I had the same question concerning the Avalon Project some years ago. :- I guess it just must be a marketing issue: J2EE simply seems to be more rewarding to vendors.Lars
    I'm thinking it is mostly because most people can't think beyond "type in web page, save to database".
  23. Why did this never take off?[ Go to top ]

    What I never understood is why such a brilliant technology as JINI never really took off, but remained in its niche instead. The concept on its own is overwhelming, so I guess the implementations must be lacking?On the other hand - and in relation to Apache - I had the same question concerning the Avalon Project some years ago. :- I guess it just must be a marketing issue: J2EE simply seems to be more rewarding to vendors.Lars
    I'm thinking it is mostly because most people can't think beyond "type in web page, save to database".
    The change from current app development paradigm to distributed app paradigm is a big shift, comparable to the change from procedural to OO. Developers will have to think in new ways, use new algorithms and deal with new problems, just take a look at http://www.dancres.org/blitz/pattern_lib/index.html to have a notion how drastic this change is. I think this is the greater barrier to Jini adoption.
    OTOH, with the advent of multicore CPUs, maybe it is just a matter of time before we all have to deal with such paradigm shift in our daily job, unless some new technology which shields developers from parallel processing issues comes up.
  24. Why did this never take off?[ Go to top ]

    What I never understood is why such a brilliant technology as JINI never really took off, but remained in its niche instead. The concept on its own is overwhelming, so I guess the implementations must be lacking?On the other hand - and in relation to Apache - I had the same question concerning the Avalon Project some years ago. :- I guess it just must be a marketing issue: J2EE simply seems to be more rewarding to vendors.Lars
    I'm thinking it is mostly because most people can't think beyond "type in web page, save to database".

    I think it is more of most applications are "type in web page, save to database". IMO, JINI really only solved niche problems. IIRC, JINI was innovative in solving distributing computing (grid) problems, but really didn't address the inVM problems that persistence, web presentation, JTA, and JCA do. Please correct me if I'm wrong.

    Bill
  25. Why did this never take off?[ Go to top ]

    ... but really didn't address the inVM problems that persistence, web presentation, JTA, and JCA do.
    Those don't sound like "type in web page, save to database" to me. I am not saying every app would be using Jini. Or a whole lot more. It is a mindset, and few seem to have it.
  26. Why did this never take off?[ Go to top ]

    What I never understood is why such a brilliant technology as JINI never really took off, but remained in its niche instead. The concept on its own is overwhelming, so I guess the implementations must be lacking?On the other hand - and in relation to Apache - I had the same question concerning the Avalon Project some years ago. :- I guess it just must be a marketing issue: J2EE simply seems to be more rewarding to vendors.Lars
    I'm thinking it is mostly because most people can't think beyond "type in web page, save to database".
    I think it is more of most applications are "type in web page, save to database". IMO, JINI really only solved niche problems. IIRC, JINI was innovative in solving distributing computing (grid) problems, but really didn't address the inVM problems that persistence, web presentation, JTA, and JCA do. Please correct me if I'm wrong.Bill

    I'm not really sure why Jini would solve those issues for you. There are other things around to do that, surely you'd want to mix them together? I don't think it makes sense for Jini to become the next all-compassing platform - that's a mistake that's been made far too many times.
  27. Why did this never take off?[ Go to top ]

    I'm not really sure why Jini would solve those issues for you. There are other things around to do that, surely you'd want to mix them together? I don't think it makes sense for Jini to become the next all-compassing platform - that's a mistake that's been made far too many times.

    Dan, if only there were more pragmatists like you!

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  28. Why did this never take off?[ Go to top ]

    I'm not really sure why Jini would solve those issues for you. There are other things around to do that, surely you'd want to mix them together? I don't think it makes sense for Jini to become the next all-compassing platform - that's a mistake that's been made far too many times.

    And I wasn't saying Jini was a replacement for those things. It is just that we can't get developers (systems & business analysts, managers, ...) let alone users to provide REAL business requirements.

    "So what do you need?"
    "We need a web app to save forms in a database".
    "But how are you going to use this? What is it for? .... "
    "We need web page so we can type stuff in an save it to the database."

    What they need is to allow users to provide information (from limited places) that is almost immediately analyzed with previously collected information. Oh, and it needs to be persisted too.
  29. Why did this never take off?[ Go to top ]

    What I never understood is why such a brilliant technology as JINI never really took off, but remained in its niche instead. The concept on its own is overwhelming, so I guess the implementations must be lacking?On the other hand - and in relation to Apache - I had the same question concerning the Avalon Project some years ago. :- I guess it just must be a marketing issue: J2EE simply seems to be more rewarding to vendors.Lars
    I'm thinking it is mostly because most people can't think beyond "type in web page, save to database".

    D'Oh. Guilty.
  30. Why did this never take off?[ Go to top ]

    What I never understood is why such a brilliant technology as JINI never really took off, but remained in its niche instead. The concept on its own is overwhelming, so I guess the implementations must be lacking?On the other hand - and in relation to Apache - I had the same question concerning the Avalon Project some years ago. :- I guess it just must be a marketing issue: J2EE simply seems to be more rewarding to vendors.Lars

    Hmmm, well the implementation is pretty good and there's a quality team backing it out of Sun plus some independents such as myself providing plugin replacements (Blitz JavaSpaces, GigaSpaces, Perrin - a Reggie replacement).

    I think there are a number of issues:

    (1) If you look at Jini with a J2EE hat on, you're gonna have a hard time with the concepts

    (2) Yeah the J2EE vendors

    (3) Lack of Design patterns, educational material etc
  31. Where's Dan Creswell?[ Go to top ]

    I'm amazed Dan Creswell hasn't come in on this, if you're there Dan, what do you think about this, will you be working with the Apache guys now?

    For those who don't know Dan, he wrote the Blitz, an open source implimentation of Jini/JavaSpaces.

    -John-
  32. Where's Dan Creswell?[ Go to top ]

    I'm amazed Dan Creswell hasn't come in on this, if you're there Dan, what do you think about this, will you be working with the Apache guys now?For those who don't know Dan, he wrote the Blitz, an open source implimentation of Jini/JavaSpaces.-John-

    Hi John, thanks for the email pointer - errr, didn't notice this discussion in my RSS reader.

    Okay, so some notes:

    Blitz is just a JavaSpaces replacement - doesn't do any Jini replacement though it does have a nice installer to generate configs etc and make getting started with Jini easier.

    Involvement - looks like I'm going to be a committer from the get go. I have in fact been in touch with Jim Hurley and the rest of the guys at Sun for some time on this whole effort. We've been figuring out what to do with websites, where to move things to, what we needed to say, who we needed to talk to etc. I've also done some phone calls with Geir who's been pitching in on this discussion (thanks Geir!).

    What it means - I think it'll help address some long term issues we've had like speed of codebase development. I think it'll foster more contributions in the form of documentation etc (Jini.org has always been "owned" by Sun and it's SCSL overtones have not helped either). I think we'll also get a better direction, J2EE is blatantly where Sun are focused and that causes confusion, especially when they refer to Jini as being strategic.
  33. According to an email sent to the javaspaces user's list, JINI will be handed over to Apache, reflecting Sun's perception of a need to update and revitalize the technology. In addition, the web site for JINI will be updated to be more open and accessible for people not familiar with the space, starting with the elimination of the perception of a "gated community" due to the old licensing (the SCSL).The changes are designed to kickstart the use of Javaspaces, in part to leverage Sun's new Grid computing service, and in part to possibly revive technology that isn't exactly new, but that has never really had the mass appeal it could have.Are you using grid computing at all? What do you know about it, or want to know about it?

    Hmmm, so the message was actually posted on Jini-Users, JavaSpaces-Users and the community lists. It's not about just about kickstarting JavaSpaces.

    Admittedly, JavaSpaces is one of the more utilized components of the Jini framework but there's a lot of other good stuff in there as well.