• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Anyway to embed a version string in a class?

 
Todd Johnson
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Where I work we deploy our software to thousands and thousands of servers. Prior to using java we wrote in C and a few other languages. We could embed a "version string" into the code that the "what" utility in UNIX could pull out of the executable. This was essential for our help desk to ensure that the correct versions were in place on a given server.

I wasn't able to figure out a good way to do this in java. I went so far as to write a utility that would load a specified class or all classes in a JAR file and look for a static String member named "VERSION" in the class and output it's value. Then in each class we'd just add a public static final String VERSION = "GRP905.09 06/10/2009". Anytime anyone modified a class they'd update that member with the new release number and date.

This worked really well until I realized that class initialization takes place when my utility loads the class and access the static member. Some of our more complex classes have some complex class initialization with a lot of classpath dependencies. So this didn't work as well as I wanted it to.

Is there a better way of doing this?
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Generally versioning is done at the jar file level. There's a convention for including version information in a jar file's MANIFEST.MF file, and an API for reading it. Then if you use jar signing, you can be sure that a jar hasn't been altered or tampered with. You can get the versions for all the jars you're using, and that should tell you all you need to know about the app that's running.
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You could set one or more of the various version fields in your jar's manifest file and then change your utility to read those instead using the Manifest class.

Damn. Shouldn't have spent time finding that link, otherwise I'd have beaten Ernest
 
Todd Johnson
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the input!

I was aware that I could version a JAR file. My hope was to be able to version the individual classes. We are a very very large shop. We have about 10+ million lines of code just in the group I work in. The entire IT department probably has 20 - 50 times that. Our builds are complex and our source control is complex. There is always the potential for the wrong version of a class being pulled into the correct version of a JAR file.

 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMHO, a jar file should be considered the same as an executable file.
If you need to change the functionality of an executable, you modify the source code, update the version number and create a new executable - you don't edit the machine code of the existing executable.
It's the same with jar files. If the functionality of one of the classes in a jar file changes, you modify the source code, rebuild the classes and create a new jar file with a new version number.

Having said that, if you do intend to modify released jar files, you could add per-entry settings in the manifest file which specified a version number for each package or class within the jar and then just add/update those when you add new classes. See the Per-Entry Attributes section in the link I gave in my previous post.
 
Todd Johnson
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Thanks Joanne. It's not that we're replacing individual classes within an existing JAR file. It's that we have a lot of JAR files, a lot of classes, and a lot of versions of those classes. We have hundreds of developers working on these project. Some of these developers are internal some are external contractors. Sometimes accidents happen and someone puts (whether manually or through an automatic build) the wrong version of a class into a JAR file. We need to be able to recognize when this condition happens.

I absolutely agree that a JAR should be considered like an executable. When we were doing development in C, every .c file had it's own version and then they were all linked into a single executable. When we checked the version on an executable we would see a version for each .c file (.o file actually) that was linked into that executable. That is exactly what I want to do in the java world.

I can see were in a smaller shop with a handful of developers that versioning at the JAR level might be sufficient. When we get called from our help desk to debug something we need to be able to go back to the source code that exactly corresponds to the class that is running on that machine.

 
Martijn Verburg
author
Bartender
Posts: 3275
5
Eclipse IDE Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sounds like you might want to read "Maven - The definitive guide"....
 
Todd Johnson
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Martijn Verburg wrote:Sounds like you might want to read "Maven - The definitive guide"....


Unless I'm mistaken that will not solve the problem of versioning individual classes. I can guarentee you with the size, scope and scale of what we do, no matter what build process, controls or methodologies are put into place errors will occur in the build process or source control. That's just the nature of thousands of classes changing every week (and using the bug ridden IBM ClearCase source control doesn't help either).
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
While I disagree with your premise, it's trivial to use an annotation to put version information into individual classes and pull it out programmatically.

Unless you create the class information programmatically you'll still have the chance for user error. You could instrument the class post-compilation with a version number, but if the developer doesn't follow the build process that includes the byte-code manipulation it could still be wrong.
 
Martijn Verburg
author
Bartender
Posts: 3275
5
Eclipse IDE Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Todd Johnson wrote:
Martijn Verburg wrote:Sounds like you might want to read "Maven - The definitive guide"....


Unless I'm mistaken that will not solve the problem of versioning individual classes. I can guarentee you with the size, scope and scale of what we do, no matter what build process, controls or methodologies are put into place errors will occur in the build process or source control. That's just the nature of thousands of classes changing every week (and using the bug ridden IBM ClearCase source control doesn't help either).


I agree/disagree , too me if you change a class then you change the artifact you are building, Maven helps a massive amount towards managing this. Of course Maven does ask you to go down a particular path which may be too painful to switch too given your existing code base.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic