Despite a class being already loaded by a classloader, the CRM should ensure new instances of a class will use the functionality of the latest version of a class. The CRM should ensure that when a classloader loads a class for the first time, it loads the latest version.While not technically class loading, the CRM should also support the reloading of non-class resources like images or html files.They may be bundled in a jar, war, or ear. These classes may be on a local disk or in a remote location. The CRM must be aware of the where the new versions of classes are located.If there is enough interest, I’ll integrate the JRebel style class reloading into Feenix and open source it.Ĭreating a class reloading mechanism (CRM) must solve several problems: Knowing the details may lead to an alternative open source product.
The JRebel supporters have published some articles discussing how they have solved various class reloading problems, but as they are a commercial product they naturally do not discuss implementation in detail. JRebel is a commercial product and is likely to be prohibitively expensive to most developers who pay for tools out of their own pocket. It has very few shortcomings and appears to be extremely well supported. JRebel appears to be the most functional and praised class reloading product in the marketplace. Unfortunately, this dramatically diminishes the utility of these products.Įnter JRebel. They also cannot alter the behavior of existing objects. You also cannot change the inheritance hierarchy. This means you cannot change the number of fields or methods or their signatures. For instance, the JVM will not allow you to change the class schema. Specifically, the JVM limits the types of changes allowed to a loaded class. Due to limitations of the JVM, most of these attempts fall short. Others, like Feenix, take advantage of Java’s built-in instrumentation API. Probably the most well known is Java’s built-in hotswap, which IDE’s like Eclipse take advantage of in debug mode. There are several products that provide a mechanism to modify class functionality in a running JVM, but they are not all created equal.
Which basically means it doesn't really add value on top of standard HotSwap of the JVM. I didn’t understand why my product failed until Anton Arhipov, a JRebel author, provided some insightful criticism:įeenix can do as much as the Java Instrumentation API allows it to do. For now, I keep it there as a painful reminder of my failure, which should inspire me to build a better one. The product still exists on my web site, but I doubt anyone actually uses it.
Some time ago when I was exploring instrumentation, I wrote a product called Feenix, which I thought would help people overcome the same class reloading as JRebel, but that didn’t happen. This figure does not have to be just the cost of doing business. The actual cost to a project can be equated to the number of developers * salary/per hour * number of hours spent building and redeploying. For a developer who tests frequently, the time spent building and redeploying can consume a significant part of a work day. The larger the application, the longer the build/redeploy cycle tends to be.
#JREBEL STATIC METHODS CODE#
Since the adoption of application servers to insulate business logic from generic plumbing logic, developers have been suffering through the time consuming process of building and redeploying before testing server side code changes. I’d like to explain how I think it works and provide a basic prototype (with source code). How this product works is a mystery to most. It is a useful product has earned its reputation by helping to expedite Java development for many organizations. JRebel is indisputably the industry leading class reloading software. The first article, an overview of byte code engineering, can be found here. Welcome to the second installment the Discotek.ca series on byte code engineering.
0 kommentar(er)
