GWT incompatibility

[BenMcLean]

GWT incompatibility

[codetaylor]

So it looks like the problem is that Joise uses classes from java.lang and java.util that aren't implemented in the subset of Java that GWT supports. Is that right?

[codetaylor]

Specifically GWT does not implement the classes:

• java.util.concurrent.atomic.AtomicInteger
• java.lang.reflect.Method
• java.lang.ThreadLocal

... and does not provide these methods on the Class object:

• isInstance(Object)
• cast(Object)
• getMethod(String, Class)

Did I miss anything?

[codetaylor]

I'm not actually using reflection to increase the accessibility of the Module sub-classes, as all of the methods referenced are public anyway. It looks more like I was trying to encapsulate the act of reading mapped properties into the module in a concise fashion.

So that I could do something like this:

readScalar("high", "setHighSource", props, map);

... instead of something like this:

if (props.isModuleID("high")) {
  this.setHighSource(map.get(props.get("high")));
} else {
  this.setHighSource(props.getAsDouble("high"));
}

I will fix this tomorrow and remove all of the reflection. :)

[codetaylor]

Got a start on it: 17305cb

[codetaylor]

Remaining:

• Joise.java [ERROR] Line 111: The method forName(String) is undefined for the type Class
• Noise.java [ERROR] Line 67: No source code is available for type java.lang.ThreadLocal

[codetaylor]

Fixed Joise.java [ERROR] Line 111: 973882f

I borrowed some of the work you did for this one @BenMcLean , I hope that's ok. I credited you in a comment in the file.

[codetaylor]

Remaining:

• Noise.java [ERROR] Line 67: No source code is available for type java.lang.ThreadLocal
• Module.java [ERROR] Line 75: No source code is available for type java.util.concurrent.atomic.AtomicInteger (forgot this one earlier)

[codetaylor]

Fixed Module.java [ERROR] Line 75: 7b5368c

I simply changed the AtomicInteger to an int because I can't reliably make the claim that this library is thread safe without more extensive testing. See #8 .

Moving on to the remaining:

• Noise.java [ERROR] Line 67: No source code is available for type java.lang.ThreadLocal

[codetaylor]

This last one is more involved and I've unfortunately run out of time for this today. I'm going to leave some thoughts here so I can quickly pick up again tomorrow.

The Noise class is essentially static, containing no state with the exception of the ByteBuffers used to store temporary values for hashing. The reason that the buffers were made ThreadLocal is to ensure that if the Noise class's static methods are accessed from different threads, none of the values get mixed up, concurrently accessed, etc... I did make the claim that this library is not thread safe, however in #8 I recommend building an identical module chain in each thread. If that advice was followed, then removing the ThreadLocal will remove the possibility of that solution.

It looks like the only two classes that reference the Noise class, outside of the Noise class itself, are the ModuleBasisFunction class and the ModuleCellGen class. It may be possible to redesign the Noise class to contain state (ie. buffers) and provide the aforementioned module classes each with an instance of the Noise class.

Then, if identical module chains were created in two different threads, each thread would have its own instances of the Noise (with state) object.

I also feel that the change to the AtomicInteger in the Module class warrants further investigation.

[codetaylor]

You're welcome, @BenMcLean and thanks for the PR. I've got a handle on how I'm going to fix the ThreadLocal. It turns out that GWT doesn't support the ByteBuffer class either, or any of java.nio for that matter. So I'm going from the ground up on this one, starting with replacing the small subset of the ByteBuffer functionality that I was using, specifically creating the byte arrays for hashing. The upside to this is it may actually increase performance in addition to making it compile with GWT. This will take more time than I initially anticipated and I thank you for your patience. :)

Remaining:

• Create util class to fill byte arrays + tests
• Factor out static instances of noise interfaces
• Replace references to the static instances of noise interfaces
• Investigate repercussions of removing the AtomicInteger in the Module class

[codetaylor]

Remaining:

• Create util class to fill byte arrays + tests 5325f6b
• Factor out static instances of noise interfaces 336ee3e
• Replace references to the static instances of noise interfaces 336ee3e
• Investigate repercussions of removing the AtomicInteger in the Module class

[codetaylor]

Just one thing left now, but I don't have any more time today.

@BenMcLean I looked at several GWT friendly versions of ByteBuffer, ThreadLocal, and AtomicInteger. Instead of replacing the ByteBuffer class with an equally bloated emulation class, I decided to bypass the ByteBuffer entirely. The only reason that I was using a ByteBuffer was to convert ints, doubles and longs into byte arrays, which can be done without the use of a ByteBuffer, possibly increasing performance. The ThreadLocal and AtomicInteger replacements are designed to have all of the methods of the originals, but none of the multi-threaded functionality that I chose them for.

My goal with these changes is to eliminate usage of classes and methods not supported by GWT while not changing the existing behavior of the library. At the end of the day, my priority is that the library compiles and behaves as expected (read: as it has in the past) with Java. Unfortunately, using drop-in classes that reduce or alter functionality would compromise that priority.

As it stands now, the develop branch should compile with GWT, given that there aren't any new surprise errors. Give it a go and let me know how it works. :)

[BenMcLean]

I believe that is correct. In my fork, I've been working to reduce or replace references to these things in the code. But I'm starting to hit a wall when it comes to method reflection.

[BenMcLean]

Here is a relevant article

[BenMcLean]

What libGDX does is emulate reflection with this package.

[BenMcLean]

BTW, in addition to finding a way around using the things you listed, GWT will also require adding this XML file

[BenMcLean]

I'm not actually using reflection to increase the accessibility of the Module sub-classes,

OK, maybe that article wasn't so relevant after all. I thought it was saying ((Don't use reflection) to increase accessibility)) but I guess what it's really saying is (Don't (use reflection to increase accessibility))

I will fix this tomorrow and remove all of the reflection. :)

Oh wow, if you could fix this so that it works with GWT, I would appreciate that so much. :) I thought I could make the changes myself but I got a little lost working on it today.

[BenMcLean]

Wow! I'm excited. Thanks so much for working on this. :)

We seem to be really close to this being fixed. I hope these last two errors aren't a huge roadblock

[BenMcLean]

OK, thanks so much for working on this. I hope it get solved soon!

I sent in a pull request to add the XML.

[BenMcLean]

Maybe you could just add in classes other people have written which emulate the functionality of the missing classes. guava has AtomicInteger (not sure how thread safe it actually is) and gwt-nyartoolkit has ByteBuffer. Not sure what to do about ThreadLocal though.

There could be some way to instruct GWT to call on these classes but instruct everything else to use the standard ones. Not sure how though, since this goes into Java stuff I haven't gone that deep into.

[BenMcLean]

BUILD SUCCESSFUL

Thank you so much!

I'm using Joise in this planet generator thing I'm working on

[BenMcLean]

Oops, I guess this should actually be marked "Resolved" before "Closed"

[codetaylor]

I'm glad it works! I think it's OK to close this - I usually close the issue when it's resolved, one way or another. :)

[BenMcLean]

Just a thought: in order to still allow people to extend Joise with custom modules, maybe the functions that replace the reflection could include some kind of interface for adding additional checks for the custom modules.

[codetaylor]

You're absolutely right, see #13 .