Modifying files from external library in Java

Question

I have a Spring Framework project which uses Maven for resolving dependencies. The project has a dependency to another Spring project (Spring Social Facebook), which is used for Facebook login. Suddenly, I started to get a lot of errors because the Facebook login functionality broke due to changes in the Facebook API. The solution is extremely simple but requires a minor change within the external library's files - changing a variable from the type integer to long.

Now I know the solution, but I don't have control over this library. I would like to fix this problem myself until the library is updated with the fix, rather than waiting around for days with a broken system.

My question is: is there any easy way in which I can make a change to the source code of this library until a fix is available in the library itself? What is the recommended way of doing this? Two things currently come to mind: forking the library, make the change, and create a private Maven repository and replace the dependency with one that uses the private repository. If I can, I'd like to avoid that. The other way I can think of, would be to fork the library, make the change, compile the updated library into a jar file and replace the Maven dependency to use the jar file.

Is there a better way? What would you recommend in a (temporary) scenario like this? Thanks!

Answer 1

From working experience, in more than one company I have seen the following approach:

• Fix the issue in the source code
• Package it again with the same Maven coordinates
• Add a classifier, which was usually companyname-patch(ed)
• Put it in the enterprise Maven repository (ie Artifactory or Nexus)

As such, you would move from

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.7</version>
</dependency>

To

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.7</version>
  <classifier>company-patch</classifier>
</dependency>

This would help you to keep more traceability:

• The classifier makes it clear to internal developers and also to contractors that this is a company patch
• You know exactly to which library and which version the patch was applied (hence, partially self-documenting)

Furthermore, it is actually a legal and good usage of the Maven classifier feature.

Reusing the same Maven coordinates may affect portability (I have a different behavior on my local machine, why?) and maintainability (let's update this library, ops.. it was the patched one, I didn't know), while creating new Maven coordinates may create misunderstanding (what's this library?) and errors (I will replace by this official one, ops.. It doesn't work anymore).

Answer 2

The latest Spring Facebook integration lib was released in August :

<dependency>
  <groupId>org.springframework.social</groupId>
  <artifactId>spring-social-facebook</artifactId>
  <version>2.0.2.RELEASE</version>
</dependency>

Since August there were only some minor changes introduced in their API, and it is highly unlikely that this would have broken their API compatibility with thousands of existing applications.

There are literally thousands of applications connected to Facebook, so Facebook would not (cannot really) allow itself to introduce breaking changes in their API. They have an elaborate versioning system with fallbacks and backwards compatibility etc. in order to protect existing integrations.

I understand that you believe you have found a possible fix for the library. What I suggest doing instead is looking into the code which leads to that specific scenario. It is much more likely that some subtle change in the way your code uses the lib leads to this "bug", rather than Facebook making such a mistake.