aspose file tools*
The moose likes Java in General and the fly likes Anyway to embed a version string in a class? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Anyway to embed a version string in a class?" Watch "Anyway to embed a version string in a class?" New topic
Author

Anyway to embed a version string in a class?

Todd Johnson
Ranch Hand

Joined: Sep 03, 2005
Posts: 61

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

Joined: Jul 08, 2003
Posts: 24187
    
  34

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.


[Jess in Action][AskingGoodQuestions]
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3739
    
  16
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


Joanne
Todd Johnson
Ranch Hand

Joined: Sep 03, 2005
Posts: 61
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

Joined: Aug 05, 2005
Posts: 3739
    
  16
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

Joined: Sep 03, 2005
Posts: 61

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

Joined: Jun 24, 2003
Posts: 3274
    
    5

Sounds like you might want to read "Maven - The definitive guide"....


Cheers, Martijn - Blog,
Twitter, PCGen, Ikasan, My The Well-Grounded Java Developer book!,
My start-up.
Todd Johnson
Ranch Hand

Joined: Sep 03, 2005
Posts: 61
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

Joined: Sep 29, 2008
Posts: 12617

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

Joined: Jun 24, 2003
Posts: 3274
    
    5

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Anyway to embed a version string in a class?