• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Any alternate for import?

 
Ranch Hand
Posts: 212
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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?
 
Vishwas Hegde
Ranch Hand
Posts: 212
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Rancher
Posts: 5008
38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic