If you try to export two objects with the same binary exporter, you will get a NPE.
This is due to the fact that the private class variable "contentKeys" is not cleared after an export is completed, where all the other map fields are cleared up.
there is a way go around this bug is simply use multiple instances of binary exporter to export multiple objects. however, since binary exporter provides a getInstance() singleton call, i think its best to resolve this issue.
thanks
That's probably why it is not a singleton, but rather getInstance() creates a new instance?
Perhaps getInstance() should really have been called getNewInstance() to provide a clue to its functionality.
(neakor, maybe if we just updated the JavaDoc for that method ppl wouldn't get confused :))
Edit: there is this comment:
//TODO: Provide better cleanup and reuse of this class.
In the binaryExporter.
Perhaps neakors issue is actually something that should be fixed rather than just providing a newInstance method (which a user could just instantiate a new BinaryExporter() anyways...)
i didn't check the code yet, but why should some variables be reset but others not?
The content keys (which is an ArrayList) is shared amongst 2 methods and is not reset when the hashmaps are, furthermore it seems like it is used as a caching mechanism…
basixs said:
The content keys (which is an ArrayList) is shared amongst 2 methods and is not reset when the hashmaps are, furthermore it seems like it is used as a caching mechanism...
what do u mean by 2 methods? save with file and save with stream? they r the same. save with file uses save with stream. if it was a caching scheme, y doesnt it work when u try to save the same object twice?
as renanse suggested, its not intended to be a singleton. so i guess the real problem is that the getInstance() method should be removed as it clearly suggests that the binary exporter class is a singleton.
Well, I just meant it wasn't written as a singleton, not that it shouldn't be (or at least reusable in some way). :) It is misleading though.
renanse said:
Well, I just meant it wasn't written as a singleton, not that it shouldn't be (or at least reusable in some way). :) It is misleading though.
sry about the misunderstanding. but i think its better of NOT being a singleton. theres no real reason y it should be singleton giving its current implementation.