This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
We need to upgrade a non-web java application which is running in JDK1.1.x to JDK1.4
This application uses some of the in-house built utility jar files for common tasks.
We are planning to change the application code according to the new features available from 1.2/1.3/1.4, but not sure how to upgrade the utility jars we are using (those jar files also built using jdk1.1.*). We don't have source code of those jars.
Please let me know the best approach to upgrade those jars, and also if there is any migration guide available to upgrade from 1.1 to 1.4 that would be real great.
Hi Vidyasagar my solution may not be the most elegant one nor is it the best one but it does work. Since you do have the JAR file you can surely unzip it and extract the class files. now once you have the class files its not very difficult to generate the source code( softwares for doing that are avaiable on the net) , so now you have the source code for your original JAR files which you can change and then make another JAR with the same name and structure but with the modified source code... hope this will solve your problem
The significant problems we face cannot be solved by the same level of thinking which created them – Einstein SCJP 1.5, SCWCD, SCBCD in the making
Java doesn't remove classes, methods or fields. Instead, it marks them as deprecated if they should no longer be used. They still can be used however, so nothing should be broken if you upgrade.
There are exceptions however. Any classes in Sun's private packages (starting with com.sun, sun or sunw) should never be used in any code not belonging to the JDK / JRE itself, because these sometimes can be removed. If the library is written by stupid people that have decided to use these classes, then it may get broken after all.
This is why you should always test everything in an isolated environment. This will ensure that you won't run into any unexpected problems should the libraries break. [ December 12, 2007: Message edited by: Rob Prime ]
You can introduce new language features if at some point you're touching the code anyway for other reasons (say, because you're adding new features). Until then, why change something that works for no pressing reason?
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com