JavaRebel 1.0 released, detects class changes for appservers

Home

News: JavaRebel 1.0 released, detects class changes for appservers

  1. ZeroTurnaround has announced the final release of JavaRebel 1.0. JavaRebel eliminates the need for application server redeployment by instantly reloading changes to Java classes. This release contains the following improvements as compared to the first public release:
    • Simpler installation. Now to install JavaRebel on Java 5 you need only to add "-noverify -javaagent:javarebel.jar" to the command line.
    • Better performance. This especially concerns startup times and background CPU usage. Some users have reported 2-3 times faster application server startup with this version than with previous versions.
    • Improved compatibility. All major containers and frameworks are supported now and other are likely to work as well.
    • Expanded support for Java 1.4. In addition to BEA Weblogic 8.x, Oracle OC4J 9.x, 10.x and Tomcat 4.x are supported.
    • Reflection support. Methods added to classes will be properly visible via the Reflection API under Java 5+.
    • Numerous bugfixes. This release should be considerably more stable and work out-of-the-box on all supported systems.
    Watch the demonstration screencast (~5 mins), read the feature list or download JavaRebel from ZeroTurnaround.com and give it a try. JavaRebel is commercial software with a free trial for 21 days and developer seat cost at 149$. ZeroTurnaround also produced a short animated ad for JavaRebel. In it, Duke (or a Duke-alike?) attempts to deploy a "Hello, World" application to an unnamed server - a good thing, because chances are a libel suit would be filed. His methods of passing the time are, well, possibly not-quite safe for work, and are quite funny in context.

    Threaded Messages (40)

  2. I really think this is cool. HotSwap is so spotty. Currently I am developing in RAD (Websfear), so I don't need this, but if I go back to Tomcat I will try it out. Will there ever be a cheaper version for lone developers?
  3. I personally don't find this stuff especially useful unless it can also pick up changes to annotations and force the relevant frameworks to re-read the annotations and rebuild their metamodels. Because if you're using a component model like EJB3, Spring, Hibernate, etc, your class simply won't work correctly after a schema/metadata change, unless the component container is also aware of the change. Are you guys working on addressing this problem? Do you address it already? If not (it's a difficult problem to get right), I would rather just take the approach we've taken in Seam and check for changes to the class files at the beginning of each request, and, if there were changes, trash the classloader and redeploy the components from scratch. Yeah, it could be slow for a really huge application, but that's at least some kind of encouragement to modularize the app.
  4. Picking up changes to annotations is not a problem but supporting the large number of frameworks is a lot of work. We are working on integrating JavaRebel with different frameworks to make them reread/reinit their configurations and cut down the redeploys even more.
  5. I personally don't find this stuff especially useful unless it can also pick up changes to annotations and force the relevant frameworks to re-read the annotations and rebuild their metamodels.

    Are you guys working on addressing this problem? Do you address it already?
    Gavin, we have full support for picking up annotation changes. It didn't make it into the 1.0 release, but 1.1 will have it. And we do plan to make frameworks rebuild there metamodels. Even if we force them to rebuild the whole relevant metamodel it will be faster than a full redeploy in many cases, but often we can also reload it for individual component.
  6. I personally don't find this stuff especially useful unless it can also pick up changes to annotations and force the relevant frameworks to re-read the annotations and rebuild their metamodels.

    Are you guys working on addressing this problem? Do you address it already?

    Gavin, we have full support for picking up annotation changes. It didn't make it into the 1.0 release, but 1.1 will have it. And we do plan to make frameworks rebuild there metamodels. Even if we force them to rebuild the whole relevant metamodel it will be faster than a full redeploy in many cases, but often we can also reload it for individual component.
    Unfortunately, a lot of frameworks simply don't expose APIs to allow incremental redeployment. JSF doesn't; Hibernate doesn't; JPA doesn't; EJB doesn't; Servlet spec doesn't. Arguably this is a failing of the frameworks, but it's a failing you're going to have to live with. So what we settled on, which is imperfect but practical, was two classloaders: Classloader A holds Seam components. When something changes in the Seam components or Seam configuration, we trash that classloader at the beginning of the request and restart Seam. This is actually very fast in practice, unless the application is huge. Classloader B holds Hibernate entities. Since restarting Hibernate accounts for 90% of the time involved in a full web application restart (at least in a Seam architecture), and since we have not yet found a way to implement incremental rebuild of the Hibernate mappings, there is no value to supporting hit redeployment here, so when something changes in the Hibernate entities, you restart the web application. Well, this is a long way from "true" incremental hot deployment. However, it turns out that with the nice IDE integration we have in JBoss Tools, you barely notice. It's a "practical" solution, though not a perfect one. What's really missing from our solution today is that EJB3 components should be on classloader A instead of classloader B, which they are not. We need to wait for JBoss 5 and then we can address this problem.
  7. it's a failing you're going to have to live with.
    If everybody would think like that we would all still live in in freakin caves, javarebel is at least trying to solve this PITA and seems to come a long way doing so. I dont understand the sceptism.
  8. Classloader A holds Seam components. When something changes in the Seam components or Seam configuration, we trash that classloader at the beginning of the request and restart Seam. This is actually very fast in practice, unless the application is huge.
    Gavin – this sounds similar to the approach taken by the ChangeAwareClassLoader in WebLogic. Presumably though state information is lost and has to recreated before serving the request?
  9. Classloader A holds Seam components. When something changes in the Seam components or Seam configuration, we trash that classloader at the beginning of the request and restart Seam. This is actually very fast in practice, unless the application is huge.


    Gavin – this sounds similar to the approach taken by the ChangeAwareClassLoader in WebLogic. Presumably though state information is lost and has to recreated before serving the request?
    Correct, that is the downside.
  10. Because if you're using a component model like EJB3, Spring, Hibernate, etc, your class simply won't work correctly after a schema/metadata change, unless the component container is also aware of the change.
    BTW if you are using a pure-Java component model, like e.g. Wicket, then you don't need any extra support to have full benefit of reloading.
  11. Because if you're using a component model like EJB3, Spring, Hibernate, etc, your class simply won't work correctly after a schema/metadata change, unless the component container is also aware of the change.

    BTW if you are using a pure-Java component model, like e.g. Wicket, then you don't need any extra support to have full benefit of reloading.
    I'm sorry, but this is just wrong. I'm not sure about the specific case of Wicket, but in general *any* framework holds some metamodel information about the components that are currently running in the framework. For example, it's impossible to create an ORM solution without a metamodel holding the mapping information. It's nothing to do with being "pure Java", it's to do with needing to hold state that does not change between requests in order to achieve acceptable performance. You don't want to have to rebuild your metamodel on each request (because that really *would* result in a very slow development cycle). And FYI, annotations are definitely "pure" Java.
  12. I'm sorry, but this is just wrong. I'm not sure about the specific case of Wicket, but in general *any* framework holds some metamodel information about the components that are currently running in the framework.
    It isn't a debatable statement, it's a fact. Pure OO frameworks like Wicket and Aranea (and Swing if we make the jump from the web) do not need to hold any metadata beyond the one carried by the component instance an thus reload everything automagically. I understand challenges that come in Hibernate, but they are not relevant to many other legitimate frameworks.
    And FYI, annotations are definitely "pure" Java.
    What I meant is pure OO Java, without mucking around with reflection and bytecode postprocessing.
  13. I'm sorry, but this is just wrong. I'm not sure about the specific case of Wicket, but in general *any* framework holds some metamodel information about the components that are currently running in the framework.
    It isn't a debatable statement, it's a fact. Pure OO frameworks like Wicket and Aranea (and Swing if we make the jump from the web) do not need to hold any metadata beyond the one carried by the component instance an thus reload everything automagically. I understand challenges that come in Hibernate, but they are not relevant to many other legitimate frameworks.
  14. There is no such thing as "pure OO". A language/idea is whatever you do with it. Ideas evolve just like languages. Maybe your perception should too. ;)
    I'm sorry, but this is just wrong. I'm not sure about the specific case of Wicket, but in general *any* framework holds some metamodel information about the components that are currently running in the framework.


    It isn't a debatable statement, it's a fact. Pure OO frameworks like Wicket and Aranea (and Swing if we make the jump from the web) do not need to hold any metadata beyond the one carried by the component instance an thus reload everything automagically. I understand challenges that come in Hibernate, but they are not relevant to many other legitimate frameworks.
  15. There is no such thing as "pure OO". A language/idea is whatever you do with it. Ideas evolve just like languages. Maybe your perception should too. ;)
    Call it what you want to. OO implies that the data about the object is in the object instance, metadata implies just the opposite. It is a concept rather than a language feature and t has some advantages and some limitations just like anything else. Frameworks often break OO encapsulation to improve developer experience, but it is not always necessary.
  16. No, OO "used" to imply data is in the object. Sure, you can go back to the GOF and other OO books and point to those examples - but to be fair - most of those examples are now aged. I'm assuming that the majority of authors intended to convey the general ideas and methods / reasoning for coming to good solutions. Perhaps if they all went back and updated their examples to include more modern concepts you would be convinced. I'll say it again, there really is no such thing as one true "pure OO" method. There are objects involved and you are programming...Embrace the modern age and have fun learning new things. Isn't that why we do this?
    There is no such thing as "pure OO". A language/idea is whatever you do with it. Ideas evolve just like languages. Maybe your perception should too. ;)

    Call it what you want to. OO implies that the data about the object is in the object instance, metadata implies just the opposite. It is a concept rather than a language feature and t has some advantages and some limitations just like anything else. Frameworks often break OO encapsulation to improve developer experience, but it is not always necessary.
  17. No, OO "used" to imply data is in the object. Sure, you can go back to the GOF and other OO books and point to those examples - but to be fair - most of those examples are now aged. Embrace the modern age and have fun learning new things. Isn't that why we do this?
    I'm very happy learning new things. I just don't mistake it with thinking that old things are now aged and irrelevant. There are still cases where object-orientation (as defined by GoF) and such is very important. And there are cases where other approaches are important.
  18. Understood... The only question I have is why are you developing java related libraries? Surely you must be doing the majority of your dev in c++ if you follow the GOF book so literally. ;)
    No, OO "used" to imply data is in the object. Sure, you can go back to the GOF and other OO books and point to those examples - but to be fair - most of those examples are now aged. Embrace the modern age and have fun learning new things. Isn't that why we do this?

    I'm very happy learning new things. I just don't mistake it with thinking that old things are now aged and irrelevant. There are still cases where object-orientation (as defined by GoF) and such is very important. And there are cases where other approaches are important.
  19. Understood... The only question I have is why are you developing java related libraries? Surely you must be doing the majority of your dev in c++ if you follow the GOF book so literally. ;)
    We are talking about ideas here, not real things. If an idea fits you use it, if it doesn't you don't. In fact I think OO approach is very good on the GUI side while functional approach is very good for the business side. In the business layer it is more natural to work with data and thus OO approach gets clumsy. And functional languages are really good at manipulating data. It will be very interesting to see if Scala gets anywhere in a few years.
  20. Understood... The only question I have is why are you developing java related libraries? Surely you must be doing the majority of your dev in c++ if you follow the GOF book so literally. ;)

    We are talking about ideas here, not real things.
    I'm sorry, now I'm confused. I thought we were discussing whether or not JavaRebel was a practical solution to the problem of rapid development in Java, using the technologies that most Java developers use today. If that wasn't the topic of the discussion, then I guess I'm not interested in discussing any further....
  21. I'm sorry, now I'm confused. I thought we were discussing whether or not JavaRebel was a practical solution to the problem of rapid development in Java, using the technologies that most Java developers use today.
    In that case you should try JavaRevel. It picks up a majority of changes made to the application. In our experience it eliminates about 4 out of every 5 redeploys, which is a significant time conservation. Although it would be nice to get it to let's say 9 out of 10, it will not improve the value as much as you think. And we do have special support for proxies, which makes it possible to add methods to the AOPd business layer.
  22. ... while functional approach is very good for the business side. In the business layer it is more natural to work with data and thus OO approach gets clumsy. And functional languages are really good at manipulating data. ...
    Wow. Well maybe the issue is the assumption of "pure OO". Page up and look at Gavins post about "encapsulation fanatics".
  23. ... while functional approach is very good for the business side. In the business layer it is more natural to work with data and thus OO approach gets clumsy. And functional languages are really good at manipulating data. ...
    Wow. Well maybe the issue is the assumption of "pure OO". Page up and look at Gavins post about "encapsulation fanatics".
    Java is not a pure OO language, but it sure as hell isn't functional. I don't get why the hell do you think I'm an encapsulation or purity fanatic? Pure concepts or approaches may help us understand a problem better or discuss it easier, but in real life we always have to mix idioms, make compromizes, etc. Java has very weak functional facilities (pattern matching, closures, abstract data types -- you name it), that what creates a LOT of boilerplate in the business layer. Having this facilities would help reduce it, especially in the world where everyone and their uncle uses XML.
  24. In fact I think OO approach is very good on the GUI side while functional approach is very good for the business side. In the business layer it is more natural to work with data and thus OO approach gets clumsy.
    That's my intuition as well. I find FP very elegant for a wide range of problems, but it doesn't click with me yet when it comes to developing user interfaces. But maybe when I get more comfortable with FP I might change my mind. It will be very interesting to see if Scala gets anywhere in a few years. Second that. Btw, I've heard quite a few people who were very enthusiastic about using JavaRebel with Scala (particularly with Scala's web framework Lift, see http://liftweb.net/). And like you said, JavaRebel works pretty good with Wicket. Of course, how well it works for your application depends on the other frameworks/ layers you use. The project I'm working on uses Hibernate, Spring amongst others, but our domain model (Hibernate) doesn't change that often and neither do our Spring definitions (we try to keep that lean, and use Wicket's @SpringBean annotations for DI). Picking up annotations is a great feature for JavaRebel regardless, so it's good to see that is coming as well.
  25. There is no such thing as "pure OO". A language/idea is whatever you do with it. Ideas evolve just like languages. Maybe your perception should too. ;)

    Call it what you want to. OO implies that the data about the object is in the object instance, metadata implies just the opposite.
    Quite wrong and absurd. The metamodel state needed by frameworks is information about the *class*, not information about any *instance*. And your blanket statement is anyway incorrect. The state associated with an instance is contained (1) in the instance itself, and (2) in other instances with which it is associated either directly or indirectly, and (3) even in other instances with which the association is implied.
    Frameworks often break OO encapsulation to improve developer experience, but it is not always necessary.
    Well, it is never *necessary*, but it is certainly the best approach to certain problems such as transaction/security demarcation, persistence, etc. Please read this: http://in.relation.to/Bloggers/OnReligionWhyImAnIgnorantCProgrammerAndDontKnowWhatAnObjectIs I'm in general extremely unimpressed by the "encapsulation fanatics". These are people who will argue that declarative transaction management, or transparent persistence, are Bad because they break encapsulation. Whereas in practice, these ideas result in a much *more* object-oriented design. These are people who seem to be seriously
  26. Frameworks often break OO encapsulation to improve developer experience, but it is not always necessary.


    Well, it is never *necessary*, but it is certainly the best approach to certain problems such as transaction/security demarcation, persistence, etc.
    Again, what are you arguing against? Not all frameworks need to do transaction/security demarcation, persistence, etc. Lookup definition of framework here: http://en.wikipedia.org/wiki/Framework.
  27. Frameworks often break OO encapsulation to improve developer experience, but it is not always necessary.


    Well, it is never *necessary*, but it is certainly the best approach to certain problems such as transaction/security demarcation, persistence, etc.

    Again, what are you arguing against? Not all frameworks need to do transaction/security demarcation, persistence, etc. Lookup definition of framework here: http://en.wikipedia.org/wiki/Framework.
    Not all frameworks do, but (very nearly) all *applications* do, which is what matters. Is anyone really building web applications which don't need declarative transactions and security, don't need declarative dependency management and don't need transparent persistence? Only a very tiny minority...
  28. I'm sorry, but this is just wrong. I'm not sure about the specific case of Wicket, but in general *any* framework holds some metamodel information about the components that are currently running in the framework.


    It isn't a debatable statement, it's a fact. Pure OO frameworks like Wicket and Aranea (and Swing if we make the jump from the web) do not need to hold any metadata beyond the one carried by the component instance an thus reload everything automagically. I understand challenges that come in Hibernate, but they are not relevant to many other legitimate frameworks.
    You have a funny notion of "pure OO" here. The fact is that any framework with adds behavior to components transparently (EJB, Spring, JPA, Hibernate, etc) will need a metamodel. The fact that they add behavior transparently does not make them non-object-oriented. (Quite the opposite, in fact.) Swing does not need additional metadata, precisely because it is *not* transparent to its components. And throwing around silly statements that imply that using Wicket will solve the problem of metadata reloading is verging on ignorant, since nobody can build an application using Wicket alone. Wicket is a view definition technology at the same conceptual level as a Facelets page. Nothing more. Sure, in Wicket, you can make changes to the *user interface* without requiring metadata reloading. But you can do exactly the same thing in JSP, or in JSF/Facelets. That's not where the problems arise. The problems arise once you make the jump to the business and persistence tiers where you are using something like EJB, Spring, JPA, Hibernate. (Yes, all Wicket users need some business component / persistence framework.) And then you're going to run into the problem.
  29. Wicket is a view definition technology at the same conceptual level as a Facelets page. Nothing more.
    Gavin, we are arguing about different things. In fact I was agreeing with you before, that frameworks do *need* metadata and that's OK, just not all of them and not always. And Wicket is not a view definition technology, it's a fully-fledged web framework that rivals the same JSF/Seam. And it does need a business layer transaction demarcation, I never argued against that as well. I just pointed out that it is a more productive web framework when used with JavaRebel. Since we are using a very similar one ourself I can vouch for that.
  30. And Wicket is not a view definition technology, it's a fully-fledged web framework that rivals the same JSF/Seam.
    This is not true, and if you ask the Wicket folks I'm sure they'll tell you the same as me. Which is exactly why we're trying to make time to work with them on Wicket/Seam integration. Seriously dude, if you think Wicket "rivals" Seam, you really need to learn what Seam is and what it does, Don't try to argue with me before you've done that.
  31. I would rather just take the approach we've taken in Seam and check for changes to the class files at the beginning of each request, and, if there were changes, trash the classloader and redeploy the components from scratch.
    but then state is gone, the problem often is not only that you have to restart the server but also that one has to logon to the app again and navigate to the part of what you'r working on, it would be nice if hibernate could reload configuration

  32. I would rather just take the approach we've taken in Seam and check for changes to the class files at the beginning of each request, and, if there were changes, trash the classloader and redeploy the components from scratch.


    but then state is gone, the problem often is not only that you have to restart the server but also that one has to logon to the app again and navigate to the part of what you'r working on, it would be nice if hibernate could reload configuration
    C'mon, it's *very* easy to have a switch that turns off authorization at development time, and mocks up a "test" user. No need to re-log-in, and no need to navigate to get to where you were working. At least, it's very easy to do this in frameworks that I use. The problem with having Hibernate reload its configuration is simply that recreating the Hibernate metamodel takes 90% of the time of restarting the whole webapp, in our experience. And it's not at all easy to just try to rebuild *part* of the metamodel (as useful as that would be), because all bits of the metamodel are interrelated. For example, changing to a composite key in one entity, can affect several indirectly related entities. The code in Hibernate for parsing mappings, deducing all the foreign key structures from related entities, and then flattening everything into the persister objects is a really complex 2-phase process. So, I would love to have incremental rebuilding of the Hibernate metamodel, but the challenges involved in implementing this have kinda scared me away.
  33. but the challenges involved in implementing this have kinda scared me away.
    I think that is because you want it all the way, kinda fanatic ;) just having the possibility to add plain fields and refs to the meta model without reloading the classes would be awsome in combination with javarebel, please consider. Maybe the picture will become clear in your mind eventually how to do it all the way if you just give it a go and release the easy stuff first.
  34. It's a great feature to have a feature for which I was always looking for. For Developers ---It will definitly save developers lot of time during development as it is not very unusual to make small changes in the code and see the implications of this. For Production Usage --- It depends upon the performance impact it will have if there is not much performance degradation then it is a great feature for that also as our clients always wanted to fix a critical issue without any downtime of the application. my 2 cents..
  35. And glassfish?[ Go to top ]

    On javarebel site there is no support for glassfish/Sun Application Server. Is it true?
  36. Re: And glassfish?[ Go to top ]

    On javarebel site there is no support for glassfish/Sun Application Server. Is it true?
    Just because it's not in the list doesn't mean it won't work. On Java 5+ you can try this approach (http://www.zeroturnaround.com/blog/javarebel-integration-and-custom-class-loaders/). We usually do not add containers to the supported list, unless we have someone to test them on real applications. If you are willing to help us join the ZeroTurnaround community group (http://groups.google.com/group/zeroturnaround-community).
  37. Weblogic 10.x and FastSwap[ Go to top ]

    I read on ZeroTurnaround website that Weblogic 10.x is supported. However, BEA has recently announced an interesting feature included in Weblogic 10.3 Tech Preview: FastSwap. According to David Cabelus's post (see http://tinyurl.com/2jqv7x), "FastSwap is a Class Redefinition technology that expands on the Class Redefinition technology in the JDK to enable you to make changes like add a method, change a method signature, delete a method, and then redefine the class in the running classloader, all without losing state". You can find more details about FastSwap here: http://tinyurl.com/2yawtb. IMO, this is a very good initiative from BEA. I'm just wondering how JavaRebel will compete with the FastSwap feature.
  38. Re: Weblogic 10.x and FastSwap[ Go to top ]

    I read on ZeroTurnaround website that Weblogic 10.x is supported. However, BEA has recently announced an interesting feature included in Weblogic 10.3 Tech Preview: FastSwap. I'm just wondering how JavaRebel will compete with the FastSwap feature.
    We know about FastSwap, but it's only offered on Weblogic 10.3 which is in Tech Preview, whereas JavaRebel runs on any containers. BEA just happened to know about JavaRebel about six months before its first release and just happened to announce FastSwap with the same features recently. Total coincidence.
  39. JBoss Javassist[ Go to top ]

    Can JavaRebel run in production or this is just a development tool? Also what are the benefits of JavaRebel beyond of what Javassist from JBoss can provide http://www.csg.is.titech.ac.jp/~chiba/javassist/ Thanks, Sergey
  40. Re: JBoss Javassist[ Go to top ]

    Can JavaRebel run in production or this is just a development tool? Also what are the benefits of JavaRebel beyond of what Javassist from JBoss can provide http://www.csg.is.titech.ac.jp/~chiba/javassist/

    Thanks,

    Sergey
    JavaRebel and Javassist do completely different things. It runs only in development and reloads changes made to classes.
  41. Re: JBoss Javassist[ Go to top ]

    Can JavaRebel run in production or this is just a development tool? Also what are the benefits of JavaRebel beyond of what Javassist from JBoss can provide http://www.csg.is.titech.ac.jp/~chiba/javassist/

    Thanks,

    Sergey


    JavaRebel and Javassist do completely different things. It runs only in development and reloads changes made to classes.
    Maybe mechanism is different, but the result is the same - updated code without a need to start and stop the server
    Javassist (Java Programming Assistant) makes Java bytecode manipulation simple. It is a class library for editing bytecodes in Java; it enables Java programs to define a new class at runtime and to modify a class file when the JVM loads it. Unlike other similar bytecode editors, Javassist provides two levels of API: source level and bytecode level. If the users use the source-level API, they can edit a class file without knowledge of the specifications of the Java bytecode. The whole API is designed with only the vocabulary of the Java language. You can even specify inserted bytecode in the form of source text; Javassist compiles it on the fly. On the other hand, the bytecode-level API allows the users to directly edit a class file as other editors.
    Also besides performance impact I do not see a reason why JavaRebel cannot run in production. Thanks, Sergey