Closed cmcewen-postmedia closed 7 years ago
An alternative would be to fork this project and make the library java 6 compatible. That might be less work, as it doesn't use many java 7 features. The changes should be trivial - things like replacing a multicatch block with multiple catch blocks.
I hadn't thought of that. Not a bad idea at all! It would probably involve more work to update each year (vs. just swapping jars in the bridge service), until the bus is retired...but I wouldn't have to touch any of the existing logic. I'll take a crack at that this week and see how difficult it is to do.
The generated stubs should be java 6 compatible, so adding support for new version shouldn't be too difficult either.
I'm supporting an older enterprise service bus that runs on Java 6. It currently has a fairly critical service which interacts with the Company Service of the DFP API. This will stop working at the end of November when v201611 is sunset. It's nearing it's end of life, so updating the bus to a newer version that supports Java 7 is not feasible. What I'm wondering is if it is possible for me to create a bridge web service that could use the new libraries on Java 7, and create Java 6 client jars using '-target' for the old service to interact with this bridge service? I've been looking for an example of this online, but haven't found any. If I can do this, it would save me having to move a considerable amount of business logic off of the bus entirely. (any other suggestions welcome!)