3

I need to deep-copy Java objects for one of my projects; and I was wondering if it's okay to use Serialization for this.

The objects are fairly small (< 1kb each), total #objects per copy would be < 500, and the copy routine will be invoked a few times a day. In this case, will it be okay to use Serialization for this in production, or is that still a really bad idea given the performance of Serialization?

If it's still a bad idea, I can think of using copy constructor/static copy method per such class to improve performance. Are there any other ways for it?

shrini1000
  • 7,038
  • 12
  • 59
  • 99
  • 4
    For something that will be invoked a few times a day performance is practically irrelevant, unless you are postulating that serialization of your object graph is going to take more than eight hours. – user207421 May 14 '12 at 09:39
  • +1. Measure the time of this fast written code before pondering other solutions. Yes it's slow. But probably not slow enough for you to notice it. And you'll easily replace it later, if needed. – Denys Séguret May 14 '12 at 09:41
  • @EJP, thx. I've never done this for production before, so was trying to find out if anybody has done it before, and any performance issues faced in it. – shrini1000 May 14 '12 at 09:49
  • 1
    "Yes it's slow". Compared to what? It is content-free, meaningless statements like this that have created this dilemma for the OP. It isn't so slow that it hasn't been deployed in millions of applications over the last 15 years. – user207421 May 14 '12 at 09:57
  • As EJP said, performance should not be concern if your routine is supposed to be invoked only a few times. You can go with serializing your objects or else if your objects are bigger and you don't need the entire data that is contained then you probably can extract and serialize only the required set of data instead of the entire set of objects. Later you can employ a factory to reconstruct the set of objects from the extracted data whenever required. – Drona May 14 '12 at 10:02

1 Answers1

2

Maybe. Performance will not be an issue - dependencies will be.

The usual problem with serialization is that an innocent reference to some core class in your application can give you a copy of 90% of all the life instances because they suddenly become reachable. So you must be really careful with transient and the references which you use.

Worse, if you need serialization for deep copy and real state saving, you might end up with incompatible goals:

  • Deep copy needs to be fast
  • Deep copy can handle open resources (database connections)
  • State saving needs to handle API evolution (the state is stored on disk, it could be restored with a new version of the code).
  • State saving can benefit from using a readable form (so a human could fix mistakes)

Therefore, it's often better to use copy constructors than using a "clever hack" even though it might safe you some/a lot of time right now.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • why would deep copy and real state saving be incompatible? – Thalatta Oct 20 '17 at 05:12
  • 1
    @Thalatta As I understand it, "deep copy" creates a working copy in memory that you can use right away. "state saving" means to persist the state of some objects to disk to be restored at a later date. That means deep copy can handle references like database connections while state saving can't. Deep copy needs to be fast, state saving must make sure the state can be restored even when the objects change (code evolution). – Aaron Digulla Nov 06 '17 at 13:07