wood burning stoves 2.0*
The moose likes Java in General and the fly likes Any alternate for import? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Any alternate for import?" Watch "Any alternate for import?" New topic
Author

Any alternate for import?

Vishwas Hegde
Ranch Hand

Joined: Oct 02, 2003
Posts: 212
Hello Guys,

I was just stuck in the middle... We were doing some enhancement and we are writing some code in the package, which is using some 3rd Party APIs.

Those 3rd Party APIs have changed and our new version has to be compatible with it.

The existing code has couple of import statments, which is being used in this class. We need to add some more to that, but obviously since its 3rd Party, we cannot use that in our build, hence our code doesnt compile.

So my question is how do I load those classes (which are there in import as well with a diff package structure, but should use my newly loaded classes )

import has pack1.pack2.pack3.javaclass and I want to load box1.box3.box10.javaclass

Putting those in Class.forName(".........") in a static block wouldnt serve the purpose...

Is it possible, like for compile time pack1.pack2.pack3.javaclass gets used and at runtime box1.box3.box10.javaclass gets applied.

My only other choice is.... has to get approval from a series of mgmt chain for adding 3rd party in the build....

Any pointer??


Thanks
Vishwas
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


The existing code has couple of import statments, which is being used in this class. We need to add some more to that, but obviously since its 3rd Party, we cannot use that in our build, hence our code doesnt compile.

So what you are saying is you have a build dependency on fooV1.jar, and you want to change this to be fooV2.jar, but you don't want to actually change the build path? Any alternative, even if it were possible, is not going to be anywhere near as simple as just going through your change management process surely?


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Vishwas Hegde
Ranch Hand

Joined: Oct 02, 2003
Posts: 212
Thanks for the reply.

Infact the 3rd party jar vendors have modified their packaging structure.
(pack1.pack2.pack3.javaclass to box1.box3.box10.javaclass in their latest releases...)

So we need to change it accordingly.

Previously, (long long ago ) developers used to use some wrapping tool, but due to various reasons, thats not allowed anymore.

So was looking some workaround so that I can make it work.
Norm Radder
Ranch Hand

Joined: Aug 10, 2005
Posts: 685
The import statement tells the compiler WHERE to find class definitions.Its added to the end of the classpath. If the 3rd party has moved where the classes are defined to be a on different path in their jar files, then you'll have to rewrite all the code changing/adding new import statements to point to the new location.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Any alternate for import?
 
Similar Threads
Compiling java files in different packages with single javac command
package problem
package trouble
Compilation of java files using javac -d option
Trouble with packages.