Note: This question refers to code written in Java or C#.

I am managing a couple of large projects where we have discovered issues (not necessarily bugs) with some 3rd party/SDK methods and have written our own extensions that should be used instead. We want developers to remember that using those methods is not recommended for this project.

If we had been using our own libraries we could easily remove that method or mark it obsolete/deprecated but we cannot do so for libraries that we didn't write.

As an example, we use a library that provides us with two overloads:

acme.calculate(int quantity_, double priceInUsDollars_);
acme.calculate(int quantity_, string currencyCode_, double priceInCurrency_);

We want developers to always use the first one and get price in US Dollars from our own standard FX rate systems. And it'd be nice to have the IDE (Eclipse/Visual Studio) warn the developers when they use the first one. A compiler warning will suffice too.

Right now, as it stands, we have to rely on the code reviewers to spot such errors and as you can see that is not a reliable approach.

One possible way I am prepared to go is to write my own check style check (http://checkstyle.sourceforge.net/writingchecks.html). But I was wondering if there was something simple that I could use. Does anyone know of ways to achieve an IDE/compiler warning of the sort I have described?

Non IDE/compiler solutions are most welcome.

  • 1
    Why can't you change the source to the third-party libraries? You have it, I assume? (If not, that's the real problem you need to focus on. Never do that.) – Mason Wheeler Jun 14 '12 at 14:09
  • 3
    @MasonWheeler Sadly, we actually cannot. It is a compiled binary (.dll, .jar) that we use. Plus, there are pitfalls to that approach as we can go off latest, miss out on support (which is very critical to us), etc.. – Apoorv Khurasia Jun 14 '12 at 14:11
  • 4
    @MasonWheeler: access to the source code of a third-party lib is something you often do not have the freedom to choose from. There are lots of closed-source libs at the market where no useful open-source alternative exist. – Doc Brown Jun 14 '12 at 14:14
  • Can you inherit the classes in their library, and add an override to the methods you don't want them to call that is marked as obsolete? – CaffGeek Jun 14 '12 at 14:16
  • @DocBrown: I didn't say open-source. I said source available. There are plenty of proprietary libraries that will give you the source (under a proprietary license) when you buy it. We have a policy at work to never use any 3rd party library with no source available, and we've never found a situation where we had to. – Mason Wheeler Jun 14 '12 at 17:52

Using a tool like NDepend / JavaDepend, you could write custom CQL queries to generate warnings for these very specific cases.

You said in the question you wanted the IDE/Compiler to warn the developers. I think because NDepend/JDepend integrate closely with the IDE this may solve your problem.

| improve this answer | |
  • 3
    That's a good call. And, you could easily rig up a scheme with NDepend (never used JavaDepend) where warnings/alerts were raised on violating checkins or even where the checkins were rejected, depending on the other tooling involved (source control, build). – Erik Dietrich Jun 14 '12 at 14:56
  • This sounds promising. I am going to try this tomorrow and let you know. Thanks Matt. – Apoorv Khurasia Jun 14 '12 at 14:59
  • It looks like they've changed their product name from JavaDepend to JArchitect, but the program still looks fairly interesting. – Dalin Seivewright Jun 14 '12 at 16:29

The "white list approach": write a wrapper library to the library with essentially the same interface signatures as the lib itself, but leave out the forbidden functions. The wrapper should delegate each method call to the corresponding library call. Then let your devs only use/link to that wrapper instead of the original lib. The wrapper may also be a good place for your library extensions.

Of coure, that may become impractical if the lib has a very big API with several hundred functions. Then you want to implement a "black list approach" like the "check style" solution you suggested.

| improve this answer | |
  • Yeah. It is a huge library. But even worse, we have lots of such libraries (across C#, Java projects). I am also thinking of a post compilation ant checks. – Apoorv Khurasia Jun 14 '12 at 14:07
  • 2
    This was my first thought too, but reading the OP's question a second time it seems he's looking for 'warnings' rather than a more restrictive architecture. I think this is a problem more of static analysis than writing more code... – MattDavey Jun 14 '12 at 14:56
  • @MattDavey That is true. – Apoorv Khurasia Jun 14 '12 at 15:05
  • There are wrapper-generator programs (e.g., sourceforge.net/projects/wrappergen) that do the tedious part for you. Then it's just some method-deletion or -annotation to do by hand. – Ross Patterson Jun 15 '12 at 1:51
  • @RossPatterson wrappers are not just a one time capital investment. They can become a maintainanace nightmare in some cases. – Apoorv Khurasia Jun 15 '12 at 8:06

One of the power with Java's Reflection is that you can change method properties at runtime. One of the use is make a private method public, to be able to use it anyway. It could very well work the other way around, with you making unwanted methods private, at runtime. Although it's won't be seen at compilation, it will be seen as soon as the project is tested.

This article shows how to modifiy methods properties at runtime. Here's the interesting part:

Class theClass = MyClass.class;
Class[] paramTypes = { Integer.TYPE, String.class };
Method method = theClass.getDeclaredMethod("myMethodName", paramTypes);
method.setAccessible(false); // this makes the metod private
System.out.println("Making method  myMethodName(int,String) private");
| improve this answer | |
  • 1
    Thanks. I am going to try MattDavey's solution first because it allows me to do static analysis. That said, if all static approaches fail, I will try your solution. – Apoorv Khurasia Jun 14 '12 at 15:11
  • 1
    That won't work I think. For compiled code, the last time that visibility rules get checked is at load time, when bytecodes are verified. Subsequent changes using the reflective APIs will only affect other reflective calls. – Stephen C Jun 22 '12 at 13:17

We want developers to remember that using those methods is not recommended for this project.

Since you already had to create replacement methods in some cases. I would create a wrapper class for the entire library and only use your wrapper class.

If the library is updated you would have to update your code anyways. The wrapper class is easy enough to update.

It avoids developers from using the wrong method although....I dare say that a developer should be able to remember which methods he isn't suppose to use.

| improve this answer | |
  • 3
    no, it's not reasonable to expect a developer to remember that he's just 'not supposed to use' perfectly logical methods in a library that he's using. One or two, perhaps, but as a general rule human beings simply can't remember that kind of thing reliably. Heck, highly trained and absolutely motivated pilots can't be trusted to remember all the details of getting the plane off the ground safely - that's why there are cockpit checklists! – Michael Kohne Jun 14 '12 at 16:35
  • That's exactly what I want. Use that function and the IDE generates a warning. – Apoorv Khurasia Jun 15 '12 at 8:08
  • @MichaelKohne - When I had a similar problem as the author I had no problem remembering what methods I should be using. The library in question was easily 100 different methods. – Ramhound Jun 21 '12 at 11:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.