Merge GWT support upstream

[GoogleCodeExporter]

Hi, I'm the maintainer of PlayN and PlayN's GWT-compatible JBox2D 
port/fork/whatever.

It turns out that there are really very few changes needed to make JBox2D 
GWT-compatible straight out of the box, and it would be great if I could get 
those changes merged upstream instead of maintaing a slightly tweaked fork. 
Then anyone who wanted to use JBox2D in a GWT app could just do it (PlayN or no 
PlayN).

I've attached two patches. One makes some minimal changes to JBox2D which would 
allow me to maintain some additional code (outside JBox2D) that would allow 
anyone to use JBox2D with GWT by simply depending on the JBox2D Maven artifact 
and my JBox2D-GWT Maven artifact. The second patch integrates the (small amount 
of) code that makes up the JBox2D-GWT Maven artifact so that someone could just 
use JBox2D with GWT directly without having to know about my extra cruft.

These diffs are against r647 which is the latest revision as of the submission 
of this issue.

The first patch (gwt-compat.patch) does two things:

1. It omits @Override on the clone() methods because GWT unfortunately does not 
define Object clone. This has no impact on JBox2D or any code that uses JBox2D.

2. Switches the three stack classes from using reflection to using a protected 
factory method to populate themselves. So instead of, for example:

  new OrderedStack<Vec2>(Vec2.class, argSize, argContSize)

you now do:

  new OrderedStack<Vec2>(argSize, argContSize) {
    protected Vec2 newInstance() { return new Vec2(); }
  };

This is slightly more verbose to the caller, but GWT does not support 
reflection and thus requires such an approach. I don't know if third-party code 
is likely to use these stack implementations. If so, this impacts that code and 
I can look into other ways to work around this GWT limitation.

The patch also eliminates the use of typed arrays internally in the stack 
classes (which were created by reflection). I assume this was done in the name 
of performance, but it is almost certainly shooting itself in the foot. Because 
the stack classes use generics, every time an object is retrieved from the 
array, the Java compiler will insert a cast, so there's no benefit to having 
the underlying array be, for example, a Vec2[] rather than an Object[], and to 
make matters worse, when you insert an object into a Vec2[] the JVM has to do a 
runtime check to ensure that the object in question is actually a Vec2, whereas 
when you insert into an Object[] it need not do that check. So using Vec2[] 
rather than Object[] is almost certainly slower.

The second patch (gwt-extras.patch) does a few different things:

1. It adds a GWT module file (org/jbox2d/JBox2D.gwt.xml). This is a metadata 
file needed by GWT.

2. It adds some "super source" which is a mechanism GWT uses to provide 
specialized code that's only used in the JavaScript version of the app. This is 
in src/main/java/org/jbox2d/gwtemul and contains three files:

src/main/java/org/jbox2d/gwtemul/java/lang/StrictMath.java
src/main/java/org/jbox2d/gwtemul/org/jbox2d/common/PlatformMathUtils.java
src/main/java/org/jbox2d/gwtemul/org/jbox2d/common/Timer.java

StrictMath is not available in JavaScript, so this emulates that with normal 
math. Timer uses System.nanoTime, which is not available in JavaScript, so the 
super-source version just uses JavaScript's Date.now method. PlatformMathUtils 
works around one use of floatToIntBits and intToFloatBits in MathUtils, neither 
of which are supported in JavaScript.

MathUtils extends PlatformMathUtils and PlatformMathUtils contains just the 
fastPow method, so that GWT can override it. I could override MathUtils, but 
I'd have to copy everything in MathUtils into the super source version, which 
means that bug fixes have to happen in two places which is no good. Hopefully 
this small bit of code-weirding is not too unpalatable.

That's pretty much it. Let me know if you need any more details or would rather 
I changed things in different ways. I'm happy to keep the GWT-specific stuff up 
to date and make sure things continue to compile and work in GWT land and 
submit future patches if/when needed.

Thanks!

Original issue reported on code.google.com by m...@samskivert.com on 26 Mar 2013 at 7:59

Attachments:

• gwt-compat.patch
• gwt-extras.patch

[GoogleCodeExporter]

Re: PlatformMathUtils, callers will never need to know that MathUtils.fastPow 
is actually coming from PlatformMathUtils, so the public API is essentially 
unchanged. We might even be able to make PlatformMathUtils a non-public class 
so that it doesn't show up in Javadocs, etc.

Original comment by m...@samskivert.com on 26 Mar 2013 at 8:03

[GoogleCodeExporter]

This looks great, I especially like the removal of reflection, that wasn't the 
best choice.  I added you as a committer, so you're welcome to commit these 
yourself if you want the cl's in your name.  Otherwise I can :)

Original comment by toucansa...@gmail.com on 26 Mar 2013 at 8:31

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Awesome! Thanks. I'll commit them presently.

Original comment by m...@samskivert.com on 26 Mar 2013 at 8:35

[GoogleCodeExporter]

Committed!

Original comment by m...@samskivert.com on 26 Mar 2013 at 8:58

• Changed state: Fixed

[GoogleCodeExporter]

At some point in my copious spare time, I'll try to whip up a simple jbox2d GWT 
sample project that just draws some bodies via HTML5 canvas to demonstrate how 
to use jbox2d in a GWT-app directly.

Original comment by m...@samskivert.com on 26 Mar 2013 at 8:59

[GoogleCodeExporter]

That reminds me that I need to finish separating the testbed base code from 
platform specific stuff.  Then a html testbed would be much more feasible.

Original comment by danielmu...@gmail.com on 26 Mar 2013 at 9:40

[GoogleCodeExporter]

@mdb I would be very interested in that simple jbox2d GWT project. Did you get 
a chance to work on it? It's not clear to me how to hook jbox2d to an HTML5 
canvas in GWT.

Original comment by dleves...@primalogik.com on 6 Dec 2013 at 5:57

[GoogleCodeExporter]

Alas not. And I doubt I'm going to get time to do it.

Original comment by m...@samskivert.com on 6 Dec 2013 at 6:05