search

samreid / piccolo2d

Automatically exported from code.google.com/p/piccolo2d
0 stars 0 forks source link

Binary incompatible change from 1.2.1 in PInputEvent #90

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Clirr reports a binary incompatible change to PInputEvent

$ clirr.sh -o piccolo2d-core-1.2.1.jar -n piccolo2d-core-1.3-SNAPSHOT.jar
ERROR: 7004: edu.umd.cs.piccolo.event.PInputEvent: In method 'public
PInputEvent(edu.umd.cs.piccolo.PInputManager, java.awt.event.InputEvent
)' the number of arguments has changed

See

http://clirr.sourceforge.net/
http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs

Original issue reported on code.google.com by heue...@gmail.com on 13 Jul 2009 at 2:35

GoogleCodeExporter commented 9 years ago 
Re-opened Issue 19.

Original comment by heue...@gmail.com on 13 Jul 2009 at 3:19

GoogleCodeExporter commented 9 years ago

Original comment by heue...@gmail.com on 13 Jul 2009 at 3:19

GoogleCodeExporter commented 9 years ago 
Almost seems like we're trying to force two different kinds of things into one. 
Seems 
like there could be two subclasses PPickPathInputEvent event and 
PCameraInputEvent 
since there are methods that assume you have a PPickpath, like getPickedNode 
and lots 
of "return (getPath() == null)? inputSource : getPath().get..." thoughts?

Original comment by allain.lalonde on 16 Jul 2009 at 5:47

GoogleCodeExporter commented 9 years ago 
Also, since the constructor to PInputEvent is primbary only invoked form 
PInputManager 
(processEvent and keyboardFocus events), I'm not sure breaking this particular 
binary 
compatibility will actually affect any clients.  You can't subclass PInputEvent 
and 
have Piccolo use your customization. I can't conceivably think of a reason for 
creating 
instances of PInputEvent other than maybe unit testing, though I'd love to hear 
one.

Original comment by allain.lalonde on 20 Jul 2009 at 9:45

GoogleCodeExporter commented 9 years ago 
I'm currently leaning towards rolling back r395, as the original motivation for 
the
change in Issue 19 is not very strong.

Original comment by heue...@gmail.com on 21 Jul 2009 at 4:45

GoogleCodeExporter commented 9 years ago 
I am rolling back r395 to fix Issue 90 and await further comment on Issue 19.

$ svn commit -m "Issue 19, Issue 90 ; rolling back changes made in r395"
    Sending        ...
    Transmitting file data ...
    Committed revision 592.

Original comment by heue...@gmail.com on 28 Jul 2009 at 2:29

GoogleCodeExporter commented 9 years ago

Original comment by mr0...@mro.name on 25 Oct 2009 at 6:43