All geek questions in one place

Java Class Name Compatibility

We have a Java client that uses corba to call several third-party systems. These are different systems that implement the same set of interfaces. We were provided with libraries (jar files) for using these interfaces. For example, one object from these libraries

this.that.GeneralException

Now we need to connect to another external system, but they changed the name by introducing several more levels of packages, for example:

 org.example.this.that.GeneralException

I assumed that the classes above would be recognized as completely different. So I made a copy of the old client, switched to the new library and changed the links to match the new name game. Having no test environment for the new system, I connected this client to one of the old systems. And, apparently, it worked very well.

Is this something related to corba or what I'm missing here?

EDIT

Just received a note from one of the third-party developers. Actually, this is in no way associated with corba. Instead, they try to maintain backward compatibility for their system. Therefore, they compared the new naming scheme with the old one and now offer an interface under both names simultaneously.

+4
source share
2 answers

Actually, this has nothing to do with corba. Instead, they try to maintain backward compatibility for their system. Therefore, they compared the new naming scheme with the old one and now offer an interface under both names simultaneously.

0
source

Stamps and skeletons for CORBA are generated through IDL, in general. Part of the IDL definition defines the package structure in the case of generated Java stubs. By changing the package structure of your client interface classes, you basically completed the contract that ORB would expect between the client and server. The only problems you encountered are where the ends of the client side refer to methods that were not on the server.

+3
source

Source: https://habr.com/ru/post/1387025/

More articles:


All Articles