Re: Enums: Properties vs. Methods
Robert Klemme wrote:
Lew wrote:
You actually don't know what the footprint will be once Hotspot takes
over. With your "toy" example, those booleans might all optimize away
and both cases take the same memory at runtime.
Just so I understand it properly: are you saying that with hotspot the
compiler might remove members of the instances? I am not sure how that
More the other way around: if it sees an opportunity to enregister
members it will remove the instance from the members.
would work since then hotspot would need to create several different
versions of the property getter methods (one per instance). I believe
this is not what hotspot can do.
Yes. So? that's what HotSpot does, except it's not one per instance,
it's N >= 1 per instance, potentially. HotSpot optimizes for
individual hot spots in the code, hence the name.
Considering that there are always only so many instances it seems the
properties approach wins. It seems, custom methods in enum instances
Yes, it wins, but that has nothing to do with memory or performance in
the JVM.
For the toy example given I would expect no difference, since the
final variables ocmpile to constants anyway.
Your "methods" example is confusing and the purpose behind the logic
deeply obscured by the idioms. That alone is enough to kill it. Your
"properties" example was clear and concise and easy to follow.
No-brainer.
Well, roughly speaking the idea was this:https://gist.github.com/892503#f=
ile_valve.java
Side channel should not be necessary to make the point.
Here there are boolean properties which derive from the enum, i.e.
whether there is traffic allowed or not and whether the traffic can flow
unlimited.
Now code which uses this enum need not create switches based on concrete
enum instances but can use boolean properties in control flow (e.g.
print a warning if no traffic at all is allowed). One might later want
THe use of values in a 'switch' doesn't seem relevant to the decision
between your approaches at all.
to add another enum value BROKEN(false, false) which is used to describe
the state of a broken medium. If this is done the code that uses those
properties to make decisions does not need to be extended.
Enums are not the most amenable to that kind of refactoring
regardless. But the so-called "properties" approach sure is easier
for that situation than the so-called "methods" approach, and for the
same reason I like it in the first place.
As for JVM effects, I would expect the two approaches to be
indistinguishable. Constant variables are compiled into constants in
the code, so they get treated identically with constants (being, after
all, constants in truth) at run time.
--
Lew