Hi Alexandr, > Usually you are right that if there is a public javadoc and developers > relies on it, changing the API could break their programs. > > This case looks slightly different. The javadoc for > JTextField.getPreferredSize() contradicts to the parent > JComponent.getPreferredSize() documentation: If the preferredSize has been > set to a non-null value just returns it.
Take for example IdentityHashMap. It implements the Map interface but it does not fulfil the Map's general contract. IdentityHashMap documents this violation of the Map contract. And as far as I know nobody tries now to fix IdentityHashMap. JTextField overrides getPreferredSize() and implements it differently and documents the new behaviour of JTextField.getPreferredSize. Therefore I personally don't see here a problem or some contradiction. > > The JTextField behavior looks like a bug and misleads developers that rely > on it as on an ordinary JComponent component and expect that a custom > preferred size should be returned. And what those developers do with the following components: JEditorPane, if it's parent is a JViewport and it's #getScrollableTracksViewportWidth/Height()-methods return false. JTextArea created with columns and rows. MetalScrollButton (it is a part of the public API therefore people may use it). BasicArrowButton (it is a part of the public API therefore people may use it). MotifScrollBarButton (it is a part of the public API therefore people may use it). JToolBar.Separator. All of them override getPreferredSize() and may return a different value than the one set by setPreferredSize(). BasicArrowButton, for example, always return new Dimension(16,16). The most strange behaviour has JToolBar.Separator. If you set the preferred size on a JToolBar.Separator by setPreferredSize(), then it returns the value you set. But as soon as you call setSeparatorSize() on a JToolBar.Separator, it starts to return the value you set by setSeparatorSize() and ignores whatever you set by setPreferredSize() before. The fact is: Swing is very old. And the fact is that the code you try to change is also very old and people relied in the past on the current behaviour of JTextField.getPreferredSize(). Not-one of Oracle/Sun developers cared about it for years. And now you are going to change it? OK, but then be prepared to see bug reports as soon as JDK 9 is released. Best regards, Andrej Golovnin > > However, this really looks like a corner case between a real bug and > already used public API. > It would be better to have more opinions about it. > > Thanks, > Alexandr. >> >> >> Best regards, >> Andrej Golovnin > >
