Closed GoogleCodeExporter closed 9 years ago
Of course this is a change that will have to wait quite a few iterations since
1.5
isn't even supported yet.
Original comment by allain.lalonde
on 15 Dec 2009 at 8:37
Assigning to myself.
I wonder if we should jump straight to 1.6 for version 2.0. 1.6 is available
in Sun
and OpenJDK forms on all major platforms except PowerPC Mac OSX.
In the meantime I'll implement this and attach here or possibly create a JDK 1.6
branch off trunk.
Original comment by heue...@gmail.com
on 9 Apr 2010 at 9:26
Attaching draft implementation for review. See also issue 153.
Original comment by heue...@gmail.com
on 23 Jun 2010 at 8:13
Attachments:
I do agree with Chris
http://groups.google.com/group/piccolo2d-dev/msg/2944bdf8a13ebcfa
Could we do both - add the 1.6 features and still remain 1.5 compilable by
using reflection and adding a runtime rather than a compile time dependency?
Original comment by mr0...@mro.name
on 21 Jul 2010 at 10:48
I wonder how that might be possible . . . Path2D is a class added to the JDK in
1.6. Perhaps we could create a dependency on that class compiled from an
OpenJDK class library implementation?
Original comment by heue...@gmail.com
on 21 Jul 2010 at 3:25
> I wonder how that might be possible . . . Path2D is a class added to the JDK
in 1.6.
As mentioned in comment 4, this could be done by dynamically checking at
runtime whether Path2D is available, then instantiating it using reflection if
so.
Original comment by samrr...@gmail.com
on 21 Jul 2010 at 7:21
I don't see how that would work, since Path2D needs to be part of the public
API for the new PPath class.
PPath(Path2D path)
void setPath[Reference](Path2D path)
Path2D getPath[Reference]()
static PPath createPPath(Path2D path)
etc.
In any case, I've created a new branch in svn branches/ppath-refactoring so
that this work can happen there instead of trunk.
Original comment by heue...@gmail.com
on 23 Jul 2010 at 3:52
take a Shape input parameter, typecheck internally by RTTI against PPath and
throw an exception in case.
Not nice, as the type isn't formally part of the public API then, but should
work.
Even better: cut+paste the PPath interface and add a proxy to PPath if
available and throw an ex otherwise.
Original comment by mr0...@mro.name
on 24 Jul 2010 at 9:16
I think there is a nice pattern established by the 1.6 Path2D abstract class
and concrete Path2D.Float and Path2D.Double classes (similar to rest of JDK
1.2+ Java2D API) and I've used that in an abstract PPath class and concrete
PPath.Float and PPath.Double classes.
At this point, I'm not yet convinced that
void setPathTo(...)
void setPath[Reference](Path2D path)
Path2D getPath[Reference]()
methods are necessary.
Then I still have yet to determine whether property change events should be
thrown from PShape (where they would be "shape" property changes, and clients
would have to cast to Area or Path2D as appropriate) or from PArea (as "area"
property changes) and PPath (as "path" property changes) so that the cast would
not be required.
See r1033 or later on branches/ppath-refactoring.
I'm removing the Milestone-2.0 label since I'm not sure when this might land on
trunk, with resistance to moving to jdk 1.6+ for version 2.0.
Original comment by heue...@gmail.com
on 3 Aug 2010 at 8:52
Created a separate issue 190 to track jdk 1.6 changes to core.
In the meantime, I would like to create a separate module on trunk called jdk16
that will contain the code from the ppath-refactoring branch in a new package
org.piccolo2d.nodes.jdk16
Original comment by heue...@gmail.com
on 24 Aug 2010 at 2:22
$ svn commit -m "Issue 152, Issue 153 ; merging ppath-refactoring branch to
trunk, into new modules jdk16 and jdk16-examples" .
...
Transmitting file data ................
Committed revision 1054.
Please review.
Original comment by heue...@gmail.com
on 27 Aug 2010 at 4:06
Original comment by heue...@gmail.com
on 27 Aug 2010 at 4:06
No news is good news, marking as Fixed.
Original comment by heue...@gmail.com
on 22 Dec 2010 at 1:57
Original comment by heue...@gmail.com
on 26 Nov 2013 at 8:47
Original issue reported on code.google.com by
heue...@gmail.com
on 15 Dec 2009 at 8:29