File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Executing different version of same source code

 
Manoj Menon
Greenhorn
Posts: 5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Folks,

We developed a translation tool, functionality of tool is when we given the input file to our tool depends on the map rule it will generate the output file, but eventually we modified the source codes to meet the requirements and performance optimization. So we are using different version of source codes for different version of map files. Still in production we are using the old source code. As of now we cannot use the updated source code in production.
So incorporating the update source code changes in production We decided use a controller class do decide which version of jar files will be executed depends on a map file version no.
Please guide me how I can implement this, please provide me your valuable suggestion or give me any use full link to help me to solve this problem.

Early response will be appreciated.

thanks& Regads
Manoj
 
Ulf Dittmer
Rancher
Pie
Posts: 42966
73
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to JavaRanch.

Instead of packaging the two code bases as two jar files, I would structure it so that there is only code base, which decides at runtime which of the two algorithms it is going to use. The decision could be based on an init parameter, user input, configuration file, or something similar.
 
Ådne Brunborg
Ranch Hand
Posts: 208
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I got this correctly, the situation is that

1) you have an old, functioning code running in production
2) you have a new, updated code which at some point in the future will replace the old code

I don't see why you need to do anything at all - it is not required that the two versions should be running in production at the same time, as far as I can see.

Maybe I'm missing something. My understanding is that you want two different versions of the same class (call it com.mycompany.TranslationTool) to run in the same application at the same time. Why not change version of the jar file when it is ready to use the new version?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Take a look at the Strategy design pattern. That's exactly the kind of scenario polymorphism was invented for!
 
Manoj Menon
Greenhorn
Posts: 5
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

thnaks for the prompt reply.

�dne,
we can't use the new version of jar file in production coz the input file for this trasilation tool, we used to call it as map file (tranilation rules) is older version that will run only older version source code, but the new map file will run only in updated code. we don't have the control to modify the map file that is already in production. so we need to run the both jar file in production. but this jar file contains different verion of same source code.

hope you understand the scenario

thanks
Manoj
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
None of those ideas address "different version of the SAME source", which I'm reading to mean the same package and class name. There is great potential for confusion and other problems but you might be able to deploy both version1.jar and version2.jar. Don't put either in the classpath for the JVM but work with class loaders that have one jar or the other in their extended classpaths. That makes me shudder just talking about it.
 
Ulf Dittmer
Rancher
Pie
Posts: 42966
73
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
**Shudder** indeed. But since it's software developed in-house, the source is available. So it would be easy to change the package names on one of the versions, and then follow the previous suggestions.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Part of the normal development practice from this time forward is including the release number somewhere in the package hierarchy? Yikes again?
 
Ulas Ergin
Ranch Hand
Posts: 77
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
you may use a custom classloader,you may have 2 classloaders one loading the old version and other loading the new.Then you may choose which classloader to use the class hierarchy

hope this helps
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's probably possible to solve this problem using classloaders or something. I'd fear that as a road to maintenance hell, though. It would probably be much easier to restructure the code to have it select the appropriate Strategy object or something at runtime.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic