Christopher Meyer

About Christopher Meyer

Chris works as a researcher and is eagerly looking for bugs in SSL/TLS, the Java platform and various applications. In addition, he is primarily interested in secure coding and exploiting coding mistakes.

How to deal with {conservative, intractable, annoying} APIs

Have you ever been fighting with an, at least for your current purpose, inflexible API? I picked up one of the trickier scenarios – calling super( … ) with parameters.

Sometimes there will be APIs defining constructors that force to be called with instances of Objects. So far so good, but what if the handled parameter is stored private inside the class you are calling and doesn’t provide a getter method? Here is an example how to solve the bother…

In my case it was an extension of the java.net.Socket class. Socket can be seen as a nice wrapper to a concrete implementation class, for example SocketImpl which contains the “lower” level (not low level!) code. However Socket provides a nice constructor to set the underlying implementation class:

protected Socket(SocketImpl impl) throws SocketException {
   this.impl = impl;
   if (impl != null) {
    checkOldImpl();
    this.impl.setSocket(this);
   }
}

So this gives an easy way to use the predefined routines of java.net.Socket with my underlying implementation without changing too much on existing code that former relied implicit on SocketImpl. The bad thing about this is that there is no way to get the handled SocketImpl instance from the wrapper (this.impl is package private, as well as the getter is package private). So if you do something like this:

public MyPrettyNewSocket extends Socket {
   public MyPrettyNewSocket() throws SocketException {
     super(new MyPrettyNewSocketImpl();
   }
}

you have no chance to interact with the instance of MyPrettyNewSocketImpl directly. All calls will be done by the Socket super class.

That really bothered me since all I would like to do is to add two new methods to MyPrettyNewSocket without touching the ones provided by Socket. The logic behind these methods is implemented in, yes your guess is right, MyPrettyNewSocketImpl.

So at least one is stuck at this point since the implementation class can’t be instantiated before super(new MyPrettyNewSocketImpl() is called (super( … ) or this( … ) have to be the first calls of a constructor). Even the dirty parameter assignment known from method calls inside (e.g. super(someInternalVariable = new MyPrettyNewSocketImpl())) is not allowed for constructors. In order to circumvent this problem you have to do some dirty tricks: call the super constructor not directly, but in a chained way. And here is how you can deal with such issues:

public class MyPrettyNewSocket extends Socket {
   MyPrettyNewSocketImpl mpnSocketImpl;
  
   public MyPrettyNewSocket() throws SocketException {
      this(new MyPrettyNewSocketImpl());
   } 

   private MyPrettyNewSocket(MyPrettyNewSocketImpl myImpl) throws SocketException {
      super(myImpl);
      mpnSocketImpl = myImpl;
    }
}

As we can see the trick is to call at first another internal private constructor of my own class extending Socket with an instance of the custom SocketImpl extending class. Normally the passed instance would get lost in the depths of Socket, but after all the construction magic we still have access and get the chance to continue working with it.

Reference: How to deal with {conservative, intractable, annoying} APIs from our JCG partner Christopher Meyer at the Java security and related topics blog.

Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

Leave a Reply


nine × 6 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books