Discussions

News: 5 JRebel features you couldn't do in the JVM

Bookmark and Share Get thread feed

  1. 5 JRebel features you couldn't do in the JVM (9 messages)

    One common comment we hear when talking about JRebel is that class updates should be implemented in the standard JVM (see feature comparison and behind-the-scenes notes to find out more about JRebel and HotSwap). However even if Oracle or IBM would announce tomorrow that they implemented the support for full schema change HotSwap in the next version of the JVM, JRebel would still be a worthwhile investment. Why? There are 5 major features that are impossible to support in the JVM:
    1. Adding new classes
    2. Changes to resources
    3. Changes to web resources
    4. Caches
    5. Managed Components (EJBs, Spring beans,...)
    We solved them like this: http://www.zeroturnaround.com/blog/5-jrebel-features-you-couldnt-do-in-the-jvm/
    Reply to this

    Threaded Messages (9)

  2. Cool...[ Go to top ]

    I have to admit, out of all the stuff posted for product blurbs and JSR whatever, JRebel is one of the cooler products I've seen to date. I could never understand why SUN or someone just didn't buy this up or put this in the JVM. Awesome.
    Reply to this Reply to original

  3. Re: Cool...[ Go to top ]

    +1 i just discovered jrebel days ago thanks to TSS; and i just did some trivial tests therefore i cannot express a full opinion about the real behaviour of jrebel; however i would say that it should be a basic tool in every developer pocket, like an IDE, like maven/ant/make/..., cvs/svn/..., and so on. i have often been thinking to abandon jboss because of the incredible amount of time lost for redeploy and server restarts (the hot deploy simply does not work, apart from trivial cases). This tool simply changes the estimate develop time for every non trivial job.
    Reply to this Reply to original

  4. JRebel[ Go to top ]

    This is a very good product and definitely worth the money. Tom
    Reply to this Reply to original

  5. Re: 5 JRebel features you couldn't do in the JVM[ Go to top ]

    I like this product a lot and its an absolute must have for every serious enterprise developer. The reason that Sun maybe didn't do this, is that the product is simply not perfect. It works for *a lot* of cases, but in small number of cases it doesn't work, or introduces some strange behavior. Maybe Sun would rather went with a perfect solution and failing being able to create that preferred no solution at all. (okay, they have the very limited hot swap). Also, just perfect class re-loading doesn't give you the power that JRebel offers. To do that you need highly specific knowledge of various libraries and platforms out there. I think Sun didn't feel much about including say Apache commons BeanUtils 1.7 and 1.8 reflection based code with the JDK. On the other hand, they could have published the same kind of plug-in interface that JRebel offers and let the actual plug-in development be a job of either the library writers themselves or any other third party. Nothing of that ever happened though, but at least JRebel is here :) My only hope is that zeroturnaround doesn't get too big ideas of doing other projects, but will remain focussed on getting JRebel better and better. They very quickly got 80% of functionality up. The next 10% took them way more time, and they now seem to be working on the next 5%. Can they keep up their focus for that final 5% and beyond. (beyond since support for new JDKs, AS' en third party libs makes it a moving target)
    Reply to this Reply to original

  6. Re: 5 JRebel features you couldn't do in the JVM[ Go to top ]

    Can they keep up their focus for that final 5% and beyond. (beyond since support for new JDKs, AS' en third party libs makes it a moving target)
    The cost-effect relation is getting larger and larger. We'll continue working on more stuff, but we'll also rework the plugin interface to allow much easier contributions from developers. Hopefully with the help from the community we can nail that last 4 percent and bring it to 99 :)
    Reply to this Reply to original

  7. Re: 5 JRebel features you couldn't do in the JVM[ Go to top ]

    Can they keep up their focus for that final 5% and beyond. (beyond since support for new JDKs, AS' en third party libs makes it a moving target)

    The cost-effect relation is getting larger and larger. We'll continue working on more stuff, but we'll also rework the plugin interface to allow much easier contributions from developers. Hopefully with the help from the community we can nail that last 4 percent and bring it to 99 :)
    I could see your business being acquired in the future as this product is very good at solving a problem many projects have. Tom
    Reply to this Reply to original

  8. Re: 5 JRebel features you couldn't do in the JVM[ Go to top ]

    I could see your business being acquired in the future as this product is very good at solving a problem many projects have.
    Reply to this Reply to original

  9. jrebel[ Go to top ]

    Im glad you solved these features

    gift ideas for illustrators

    Reply to this Reply to original

  10. limitations[ Go to top ]

    too bad it has some limitations

    stork club print media

    Reply to this Reply to original