I am doing a swing based application where I use JTable
. I used DefaultCellEditor
for one of the column which requires combo box selection. But DefaultCellEditor
has many methods which I don't require. So I wrote a custom CellEditor by extending AbstractCellEditor
where I have implemented only the required methods. My question is
(in general) if we have a class and if we don't require all the methods of that class is it fine to use it or is it good to write a custom class where we implement only those methods which we require? and
by using custom class will the performance (memory wise) of the application will be improved or it remains same as the class which has all the methods?
Any help will be appreciated.
Unless you have seriously good grounds for believing that nothing else in the application including the JDK itself uses DefaultCellEditor,
you are almost certainly wasting your time by making things actively worse.
You also need to consider that you might have saved maybe 100k of code in extreme cases, where typical JVMS use around a gigabyte to execute. So you may have saved 0.01% of code space. This is not a productive use of your time. The correct procedure is to test and measure where the time and space bottlenecks really are, after the fact. Programmers are notoriously poor at predicting these things.
The code (the actual bytecode) for this class is only loaded once, in the PermGen region of memory, regardless of how many objects of this type you instantiate.
I would not accept this code since you are duplicating functionality which is already available, and you're not adding functionality to AbstractCellEditor
, you're reimplementing code in DefaultCellEditor
which has already been (hopefully) tested by Oracle (or Sun).
As EJP said, it's not worth the time and potential to introduce bugs.
If you create a custom class which contains fewer member objects, then the memory footprint will be lower. The number of methods wouldn't impact the size of the objects, just the size of the class.
In general, I would not prematurely optimise unless you determine that you actually have a problem (i.e. if you have thousands of instances of the object and heap/garbage collector log analysis reveals that you're thrashing the memory and/or have frequent of collections of the old space), because additional code means:
CellEditor
is not buggy)AFAIK, a CellEditor
is instantiated as and when needed, so you wouldn't save much memory anyway.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With