Reputation: 82
I am working on a project using Salesforce SOAP API. I need to use the java classes from different SOAP API jars for different Salesforce instances in my project, but the classes name and their package names are totally the same.
For example:
jar of Salesforce instance A has com.sforce.soap.enterprise.sobject.SObject.Opportunity, it has a customized attribute called attrA;
jar of Salesforce instance B has com.sforce.soap.enterprise.sobject.SObject.Opportunity, it has a customized attribute called attrB;
Maven structure:
How can I use both attrA and attrB in my single project? In other words, how can different classes with the same package name and class name be identified seperately?
Do I have to split my project into two sub projects in order to use both jars?
Upvotes: 0
Views: 108
Reputation: 27607
You cannot do this in Java. The package names + class names must be unique for the project.
You likely need to refactor your project such that the different Salesforce JARs are in their own project and only expose the necessary interfaces to your main project. The only other option would be to write a custom class loader, but that is fairly complicated.
See the package documentation here:
Developers should take steps to avoid the possibility of two published packages having the same name by choosing unique package names for packages that are widely distributed. This allows packages to be easily and automatically installed and catalogued. This section specifies a suggested convention for generating such unique package names. Implementations of the Java platform are encouraged to provide automatic support for converting a set of packages from local and casual package names to the unique name format described here.
If unique package names are not used, then package name conflicts may arise far from the point of creation of either of the conflicting packages. This may create a situation that is difficult or impossible for the user or programmer to resolve. The class ClassLoader can be used to isolate packages with the same name from each other in those cases where the packages will have constrained interactions, but not in a way that is transparent to a naïve program.
Upvotes: 2