What does this 'appendage' do in an object declaration

I'm trying to port /rewrite some old minecraft plugins to a new server core api, so I'm trying to reverse engineer a couple simple, abandoned codes to understand and modify.

I have a class which will represent a 'teleporter unit'.  Inside of this class is a HashSet defined of 'non-hindering blocks' (material types that can be 'erased' in its surroundings.
The declaration makes no sense to me, I have never seen this 'appendage' on an object declaration to figure out what it might be trying to do:

  private static HashSet<Material> nonHinderingBlocks = new HashSet<Material>()
  {
    private static final long serialVersionUID = 12345L;
  };

Open in new window


It is CLEARLY shown to be an extension of the = new HashSet(<Material>) line.
What does a braced-structure inside the = new HashSet<>()   {}  ; structure end up doing?
What would this variable do -- I can find no calls/referencing of "serialVersionUID" within anywhere else in the program, so is it something that integrates into the system at compile time to make a special HashSet thing?  Or is it just a scrap of confusing, unimplimented code that is ignored for meaninglessness in its context?
LVL 6
GPrentice00Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

mccarlIT Business Systems Analyst / Software DeveloperCommented:
So it seems that you have the basic idea... it is defining a new, anonymous class that extends from HashSet. And then it is creating one instance of this new anonymous class and assigning it to your nonHinderingBlocks variable. So in every way it is a normal HashSet. The only thing is it is defining/overriding the serialVersionUID with this specific value (12345), but this I am thinking you are basically ok with.

So what is "serialVersionUID"? It is used when Java is asked to Serialize this object to a binary stream (potentially to store as a file or in a database, etc). Because an object that has been serialized to disk (or DB or whatever) may be loaded back in at a later time, and the code may have changed by that time, this id is meant to identify a particular version of the class. Java will check the version of the object that has been serialized against the version of the class file that you are attempting to load the object back in as and it fails if the version has changed.

As for why they are explicitly setting the version ID, is anyone's guess. The only reason I can think of would be to circumvent the above description of version checking, so that if the Java supplied HashSet class changed (or at least if the version id changes), because the version ID is overridden to be 12345, then Java will still attempt to load the object. But this is potentially dangerous, because if HashSet had changed then it is quite possible that the code would break in some unusual ways.

Hopefully that makes some sense. If you'd like to read further, just look into Java Serialization and you should get a good idea, or if you have further question, shoot them back here.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
GPrentice00Author Commented:
Okay, that kinda makes a bit of sense, its either like a fancy way of making a new classs instead of extension, or stuffing a value into something that isnt part of a constructor...
That code would be 'seeding' the hash function serializer (data dump) with a constant so that on the off chance that changes later in the program result in a change of the hash function default seed, the data would be ..restorable?

Maybe doesn't make sense - its not like this is encrypted data to decrypt later.  The hash map in this case should only persist while the program is in memory, whatever data is saved out at shutdown is reimported at startup from a raw text file, so they could map via a different function, different memory locations and whatnot and shouldn't be a problem.

I will bear it in mind but it looks, and appears from other readings, that there is no real need for it to be set in this case, but keep an eye open for how the recoded system behaves and insert it back if needed.
mccarlIT Business Systems Analyst / Software DeveloperCommented:
That code would be 'seeding' the hash function serializer (data dump) with a constant
No not really, it isn't anything to do with the hashing function, or seeding anything. It is just an opaque number and theoretically, if anything changes with the actual code of the class, the number should change to something else (ie. the actual value is immaterial, it is just that the value has changed to a different value)

on the off chance that changes later in the program result in a change of the hash function default seed, the data would be ..restorable?
No, actually for this to have any real noticable effect, we are talking about the actual JVM code would need to be different for the HashSet class. And I have had a look through "grepcode" view of OpenJDK at least, and in there version of HashSet, the version ID hasn't changed since Java 6 anyway.


The hash map in this case should only persist while the program is in memory, whatever data is saved out at shutdown is reimported at startup from a raw text file
Yeah, so I probably should have highlighted in my first post, that the bit of code that we are talking about has in all likelyhood NO USE at all. There are obviously an infinite number of different ways that you could persist data between shutdown and startup (if you indeed need to do so at all) and Java provides one way (what I was talking about above, Java Serialization, and this is where the version ID gets used). That doesn't mean that you have to use that, and yeah as you mention, you can always just save the data yourself to a text file and read it back in on startup, that's another way.

I will bear it in mind but it looks, and appears from other readings, that there is no real need for it to be set in this case, but keep an eye open for how the recoded system behaves and insert it back if needed.
I agree, I would doubt that Java Serialization is being used anyway, and so the above code is useless.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.