3

i am currently writing a java game with a peer-to-peer "network protocol". This means i send object over the network to the other game.

As the development goes on i add and remove stuff. I change the game and it becomes eventually incompatible with older versions.

Now i want to store the current version number in the protocol object i send over the network and every time i make i change i could update the version and thus detect in code if the two game instances are compatible.

My question is: What is the standard class to save a version number in java?

I search for something which provides me major, minor and patch level versions, is comparable etc.

Its pretty hard to google such a class..

Shylux
  • 1,163
  • 2
  • 16
  • 31
  • 1
    Not totally sure but you can use a `public static final int version` field. – Luiggi Mendoza Nov 02 '13 at 14:05
  • implement `java.io.Serializable` and create the field generatedGUID. when you change the class, the guid should change – Philipp Sander Nov 02 '13 at 14:06
  • When you say you send objects over a network protocol, do you mean: 1. That you use something like a `ObjectOutputStream` to send data over a network connection? 2. You are creating your own objects to send across the network? If that is the case, you are creating your own standard of application-layer network communication, in which, you define the standard. When people check for version numbers, transmission of an single integer is good enough, no special objects are required. If your game begs for a specific Object to take this role, create your own. – initramfs Nov 02 '13 at 14:10
  • Yea it's exactly like you described it. A simple integer to store the version would work, no doubt. But its Java and its a school project. I want to make it with a nice version object. This is some really basic stuff and easy to implement so i'm pretty sure there has to be something like that in the core. – Shylux Nov 02 '13 at 14:18
  • Well, in my opinion, to explicitly have to transmit a whole object that represents the version is a sign of bad program design. Version numbers should be **build-in** either to the message packet or during initial connection handshake. But, aside from all that, with serialization (essentially what java is doing for you when objects are made ready to transmit/store), java automatically gives each class a "version" stored as the field `serialVersionUID`. Can you not simply change the UID with each incompatible version of the game and detect a `ClassCastException` when reading objects? – initramfs Nov 02 '13 at 14:27
  • Another approach will be to make a basic skeleton superclass for all your custom objects to inherit which contains a integer field with a version number and appropriate methods to get this version number. Because of the "unique" design of your program, there won't really be some standard "version object" for you to find as people generally don't program that way... – initramfs Nov 02 '13 at 14:30

2 Answers2

0

The versioning mechanism depends on serialisation mechanism you are using. If you are using standard java serialisation then the serialVersionUID property indicates the version of the class. Your options for specifying major, minor & patch levels fairly limited as the serialVersionUID is a long

Community
  • 1
  • 1
Pieter
  • 2,745
  • 14
  • 17
  • Oh that's what he meant with this generatedGUID field. Maybe i will go with that, but i'm still looking for that standard version object. – Shylux Nov 02 '13 at 14:22
  • I am pretty sure that there is no such thing as _a standard class to save a version number in java_.I'm still not quite sure what you are trying to achieve. Are you trying to implement some sort of handshake mechanism that determines whether 2 clients can communicate with each other? Or are you looking for a way to version each _data object_ you send over the network and then see if the other client can interpret it? – Pieter Nov 02 '13 at 17:04
0

AFAIK, it's a standard practice to explicitly include a protocol version number in your messages. I'd recommend to use string for that field as numeric ones are often too restrictive (besides, use of string seems to be the de facto standard nowadays).

This is usually better than having versions on objects, as versions on objects don't necessarily correspond with whether the protocol is compatible.

If you are using Java serialization for your message serialization, things may get a bit more complicated as Java serialization has its own versioning scheme. You can work with that, but it might be easier to use an independent serialization protocol (like JSON, XML, protobuf etc.)

Enno Shioji
  • 26,542
  • 13
  • 70
  • 109