AUS, from alphaWorks: Eliminate Fragile APIs in Java Apps


News: AUS, from alphaWorks: Eliminate Fragile APIs in Java Apps

  1. AUS (API Usage Scanner) is a J2EE tool that helps developers detect fragile APIs in Java applications to avoid binary compatibility and toleration problems. AUS, a pure Java utility, identifies references to APIs of one product by another product to create a set of detailed reports showing where references to the APIs are found and how those APIs are used.

    From the AUS home page:
    The API Usage Scanner (AUS) tool can help quickly locate these internal API usages so that compatibility problems can be avoided or remedied. AUS is a pure Java utility that scans Java bytecode for references to targeted APIs. In other words, AUS can be used to scan one product to detect the use of another product's internal APIs. Once these usages are identified, the situation can be remedied by replacing those internal APIs with published ones. If a suitable published API is not available, the product team can alert the API developers of the existence of fragile interfaces between the two products and request an agreement to hold that API stable until a suitable replacement can be provided. Several IBM flagship software products have already done this with great success.
    What do you think?

    Threaded Messages (4)

  2. could be useful[ Go to top ]

    At my previous company we were making a framework - big one. From time to time we wanted to know which part of the API we were supplying was most used by clients, in order to spend our time optimizing and debugging code that was used the most. This kind of information was a pain to collect and it rarely proved to be accurate. If this tool can provide such information, it would be more then useful.

    Emil Kirschner
  3. Wish I had this a year or so ago[ Go to top ]

    I realy needed a tool like this a while back. I had just started a job and was asked to modify the code base to avoid using a certain method in an API. Unfortunately for me, the codebase was apparently the result of one of those 'a million monkeys with typewriters' experiements. The usage of the AbstractFactory pattern was great and greatly misguided. It took me quite a while chasing references to realize I was in an API loop.

    Not having used this tool I can't say that it would have worked for me unless it can follow reflection through classnames stored in a database.
  4. Hammurapi[ Go to top ]

    The tool looks promising and I see a lot of benefit for my day-2-day work (as soon as I get solve the Exceptions thrown in the sample).

    Interested parties may have a look on Hammurapi's Tech Stack analyzer (
    Hammurapi generates a metamodel, and visitor-pattern based inspectors examine the model (not the parser tree).
    The new version adds an rule engine approach. Learn more here:

    An additional incentive is the open-source license.

  5. This reminds me of dependencies in Maven :-)