I have dev build 3.1 2012-05-09, and it appears that the signature for the three-argument version of Canvas#addChild has changed from taking a boolean primitive to a java.lang.Boolean. This change doesn't appear to gain anything substantial, and it breaks backward compatibility with a core API on a minor release. Why was this changed from the primitive to the wrapper?
-
-
This was an accidental change involving making more of the API auto-generated so that docs cannot become stale.
Because of Java auto-boxing this change should not introduce compile-time incompatibility and GWT does not produce .jars that could have runtime incompatibility. So how did this change affect you? -
We have written some convenience components that subclass Canvas (e.g., for a common style of content panel that consists of some headers, a ListGrid, and buttons), and a couple of those overrode the long-form Canvas addChild to be able to pass up an ID (since there are only the two forms). The change in the signature broke @Override.Originally posted by IsomorphicComment
-
Aha. OK we can add it back in case this bites someone else too.Comment
-
I'm on today's nightly, and the API is still Boolean (and only Boolean). When is this expected to be reverted (or duplicated, which seems unnecessary)?Comment
-
Should be back next week. It will probably be duplicated.Comment
-
*That* bug was reverted completely... but now Canvas#addChild(Canvas) is missing entirely, which is likely to break even more code than the last change.
I know these are nightly dev builds, but are they being even compile-tested against anything outside their own source trees?Comment
-
I just double checked our latest build of SmartGWT both pro and enterprise eval and the Canvas object contains the expect addChild method. Can you please double check and provide additional details if you continue not to see the method.Comment
-
I've verified that Canvas#addChild(Canvas) has been removed in the 2012-05-23 nightly. It appears that you are expecting client code to fall back to Canvas#addChild(Widget) and performing the conditional in the Widget-based method. This sort of change (removing or modifying any method signature that could be the target of an @Override) is generally expected to happen only in a major-version release, not a minor-version. Pretty much anyone who's implemented a custom Layout will have their code blow up when this sort of thing happens, since the @Override check no longer matches.Comment
-
A note: If you're ever planning on removing any method signature that could be overridden, it's extremely helpful to mark it @Deprecated as soon as the decision is made.Comment
-
Fixed as of 2012-05-27.Comment
Comment