• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • DSO:L1
  • hhuynh
  • Reporter: kenney
  • May 22, 2007
  • 0
  • Watchers: 0
  • June 21, 2007
  • June 20, 2007


The methd StandardDSOClientConfigHelper.addCustomAdapter has changed it’s method signature from void (in 2.3.0) to boolean (in trunk).

I compiled a new module against trunk and ran it against 2.3.0 which gave me

{noformat} Caused by: java.lang.NoSuchMethodError: com.tc.object.config.StandardDSOClientConfigHelper.addCustomAdapter(Ljava/lang/String;Lcom/tc/object/bytecode/ClassAdapterFactory;)Z at com.neonics.container.terracotta.ContainerActivator.addLoaderAdapters(ContainerActivator.java:37) {noformat}

This may be a well-known incompatibility but it is a problem for backwards compatibility for new modules. Just thought I’d mention this.


Fiona OShea 2007-05-22

If this is an intentional change, please make sure to doc it.

Geert Bevin 2007-06-20

Just wondering, what are the chances of someone compiling a module against a recent version and running it on an older version? A related note here for me is that there’s no clear notion of a “public Terracotta API”, nor which parts are internal to the product itself. Imho javadocs are sorely missing in this case. It’s to be expected that the signature of methods and classes changes over time as the product evolves. There’s no way that binary backwards compatibility can be guaranteed for all possible methods and classes, unless there’s a clear contract available that needs to be obeyed and checked.

Geert Bevin 2007-06-20

Seems this API change is not used anywhere, it merely is reflected to the inner logic of the method. Reverted return type to void and adapted the javadoc for the method.