Discussions

News: Objenesis 1.0: Create objects bypassing constructors

  1. The Objenesis Team proudly presents Objenesis 1.0 Objenesis is a framework that allows the creation of objects without calling constructors. Needing to instantiate an object without calling the constructor is a fairly specialized task, however there are certain cases when this is useful: * Serialization, Remoting and Persistence - Objects need to be instantiated and restored to a specific state, without invoking code. * Proxies, AOP Libraries and Mock Objects - Classes can be subclassed without needing to worry about the super() constructor. * Container Frameworks - Objects can be dynamically instantatiated in non-standard ways. The Java Serialization mechanism, one of the core cases where there is need to create objects without calling constructors, resorts to internal tricks to achieve this functionality. Many different projects have exploited that fact in clever ways, but since the "magic" is an internal JVM feature, most solutions lacked portability. With Objenesis, we have endeavoured to concentrate the many different approaches into a single, portable solution, keeping the developer from having to deal with the many different JVM implementations. Objenesis is released under the MIT license, and comes in two flavours: * Standard, which creates objects without calling constructors. * Serialized, which creates Serializable objects according to the Java Serialization specification: calling the no-arg constructor of the first non-serializable superclass. You can find out more at the project website: http://objenesis.googlecode.com/svn/docs/index.html

    Threaded Messages (15)

  2. Hi, Just downloaded and will come back once i get used to it and post my comment regarding the framework. Thanks. Prashant
  3. Can somebody tell me why or when this would be a good thing to do? It strikes me as a solution to a problem that shouldn't have occurred in the first place - a serious design flaw work around.
  4. Dear java friends ! It suppose it could be usefull to reduce the cost of creating tons of new objects in cirucumstances, where you have to act with many small objects. Imagine a webpage view framework where everything up to labels and links is stored and served as objects. In this case this framework seems to introduce some kind of prototype aspects. I wonder if it also reuses allready instantinated objects and cleans them automatically after usage. Any experiences regarding to this? A.B.
  5. The question remains .. Why ? Why do i need a framework to create instances of objects ? Why learn another framework ? (Dont we have enough already?) Why can't this be done simply after reading this ? http://java.sun.com/docs/books/tutorial/reflect/object/index.html I think this framework is simply an implementation of the Prototype pattern to object manuplation. Author comments/arguments welcome.. -Vinant Pandey
  6. Hello, I am one of the developers of Objenesis. The idea for the project came from different developers that found the need to completely bypass constructors, instead of using the reflection mechanism to simply choose a constructor. We perceive it as a very specialized task, and it is actually wise for most (simple) projects to avoid using it. I don't have a deep knowledge of the reasons why the other developers needed to bypass constructors, so I'm not able answer for them satisfactorily, but I can tell about my experience. In my case, this feature is needed for an experimental serialization mechanism. In order to properly emulate the Java deserialization behavior, I have to create objects using the information provided from the input stream, and *without* calling constructors. There are many reasons for that, from undesired "side-effects" that can be triggered by the constructor code, to the possibility of the inexistence of a no-arg constructor for a given class. (java.lang.Integer is an example of such a class, but you don't need to stretch your imagination very far to think of a class where the constructor's arguments don't map directly to the internal state of the object). You can see from http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6220682 that, although being a polemical issue, there are projects that would be interested in the capability of bypassing constructors. I hope this answer is helpful. - Leonardo Mesquita
  7. Hi, I could see a far reaching impact of such a framework. In recent past I was playing with alternate serialization mechanism over the wire and come across a very performant & light weight protocol - Hessian. But unfortunately our business objects did not pass through, as we don't have default constructors and the constructor contains various value checks. Now since this practice was very core to our architecture we could not get rid of this overnight. Hessian internally, has to create the object on the other side of wire by calling one of the available constructor. I could see a very good possibility of using such a mechanism in Hessian/Burlap Unmarshaller and make it a true alternative to java serialization. Thanks, Shiv
  8. O.K., the example you give is a work around of one or both of two problems, 1) Java serialization is inadequate and 2) existing classes do not have the write constructors available to implement an alternative serialization. So, what guidelines do you suggest so that your circumvention of the classes' constructors does not undermine the intent of the classes' designs? In other words, the constructors are part of a class's contract. Circumventing them violates the contract, which may or may not be harmful. How do you insure that this circumvention is not harmful (i.e. has side effects)?
  9. The quick answer is: you don't. Suppose the following example: a given Serializable class keeps track of the number of created instances by keeping a static counter that is incremented in the constructor code (for whatever reason): public class TestClass implements Serializable { static int creationCounter; public TestClass() { creationCounter++; } } If an instance of this class is sent through the network, using Java default serialization mechanism, on the receiving side you get an instance that is not accounted for, because the constructor is not called. It is a polemical point, I won't deny that. The best guideline I can think of is: know what you're doing.
  10. If an instance of this class is sent through the network, using Java default serialization mechanism, on the receiving side you get an instance that is not accounted for, because the constructor is not called.
    Using your example I would have implemented Externalizable (which I often do especially if my class has Maps) and then I could update the counter from there. With this framework, what would my solution be?
  11. Maybe I don't understand the question. The idea of the framework is to provide a base for other infrastructure code, for instance, to make an "alternative" serialization mechanism. So you shouldn't resort directly to Objenesis to solve this kind of issue, it's up to the infrastructure code above. But anyway, you could also solve this (in Java default mechanism) by adding a "writeObject" method. One way or the other, the point is that you still have to worry about how to manage these situations. Objenesis doesn't change that, it wasn't meant for that. It means that, if you implement infrastructure above Objenesis, you'd better provide a "writeObject/Externalizable"-like approach for issues similar to the one above.
  12. Maybe I don't understand the question. The idea of the framework is to provide a base for other infrastructure code, for instance, to make an "alternative" serialization mechanism. So you shouldn't resort directly to Objenesis to solve this kind of issue, it's up to the infrastructure code above.
    O.K. we are getting close. I'm just trying to understand how this framework can be useful outside of providing a means to work around an earlier mistake or omission. You seem to be suggesting something along the lines of using it for alternative implementations of things Java already does but maybe not well enough and that it should be used as part of your infrastructure and is not intended for casual use by application programmers. Is that it?
  13. You seem to be suggesting something along the lines of using it for alternative implementations of things Java already does but maybe not well enough and that it should be used as part of your infrastructure and is not intended for casual use by application programmers. Is that it?
    Yes, exactly. It's not only on the lines of "Java doesn't do that well enough", but also of experimental aproaches (e.g., you could play with an alternative approach for serialization initialization that doesn't follow the "superclass no-arg constructor" rule). There's also some use in the world of mock objects for testing, but I don't know much about it.
  14. In time: I usually think of Objenesis as an "extension" to reflection. Through reflection you can access private members of a class, which is surely a breach of contract. It is something you should "stay away" from, but people often find some use for it ;-)
  15. i dont get it[ Go to top ]

    i still dont see how this is useful. if you somehow manage to contrive a situation where an object should be instantiated without a constructor then u most likely arent following the principles of object oriented programming and thus shouldnt be using java in the first place. any class which uses a proprietary serialization method should also include a constructor to rebuilt an instance of that class from the serialized form. or an alternative would be to use a dedicated helper class for serializing instances of the class in question. the helper class would use reflection for rebuilding an object from a serialized form. Of course ud then have to change two classes if u make changes to the structure of the class that is being serialized/deserialized...but at least this prevents u from having to break OO principles and class/interface contracts by using such a shady framework.
  16. Know what you do![ Go to top ]

    It's as Leonardo said, you have to know what you do. E.g. since JDK 1.5 you can also set final fields with reflection. Again, you have to know what you do.
    if you somehow manage to contrive a situation where an object should be instantiated without a constructor then u most likely arent following the principles of object oriented programming and thus shouldnt be using java in the first place.
    Then stop using Java yourself, since Java is doing it already! ;-)
    any class which uses a proprietary serialization method should also include a constructor to rebuilt an instance of that class from the serialized form.
    Any alternate serialization implementation should be able to do the same as the JDK.
    or an alternative would be to use a dedicated helper class for serializing instances of the class in question. the helper class would use reflection for rebuilding an object from a serialized form. Of course ud then have to change two classes if u make changes to the structure of the class that is being serialized/deserialized...but at least this prevents u from having to break OO principles and class/interface contracts by using such a shady framework.
    And this is where Java is cheating. It creates the objects without calling their ctors and *then* they are calling the different serialzation methods to rebuild the object. Objenesis simply exposes this functionality with a vendor independent API (yes, by calling the same com.sun.* classes internally ... at least for the Sun JDK). So it is a specialized API for rare cases like alternate serialization implementations, mock objects or byte code manipulation frameworks. Nevertheless all these implementations do it currently already somehow on their own! They did the same research over and over again without a real chance to support a big number of different vendors. Concentrating all this efforts into *one* framework, it will help a lot. At least for those packages.