Last month I wrote a sketch called YinYang.
http://www.openprocessing.org/sketch/74982
It uses the Box2DWeb JavaScript API, but is able to run in Java mode too (not just JavaScript mode) due to the use of Rhino, which is a JavaScript interpreter written in Java. Perhaps this is why I tripped over a couple of cross-compatibility issues which may not have been seen before, and there are a couple of other issues I encountered which I'm going to list here too.
Everything I came across I was able to workaround in my sketch, and I also have patches to the Processing source code which address each of these issues. I discussed how to apply a patch from GitHub to an svn working directory here:
https://forum.processing.org/topic/processing-source-code-and-github#25080000001800081
Unless I get other advice, then in about a weeks time I'm going to feed these issues one at a time into the Processing issue tracking system in googlecode, but I thought it would be good to present the whole picture first and give folks the opportunity to comment if they wish to.
It's only fair to point out that my sketch isn't free of bugs either - I have issues with conservation of momentum, transfer of angular momentum, and velocity not absolute but is proportional to the speed of the platform the code is running on. I'm keeping it this way for the sake of simpilicty.
OK, so here's my list:
1. Detecting which mode you're running in
As far as I am aware, there isn't a direct way a Processing sketch can tell which mode it is running in. I'm greatful to Pomax for showing me this trick which exploits type coercion to figure it out...
boolean runningInJavaScript = ( ""+2.0==""+2 );
...although perhaps this is a useful hack rather than a desirable way of going about this? API changes are a delicate matter, so this patch is probably quite reckless ;-)
https://github.com/Antony74/Processing/commit/502865afd9b0fa0585811897a894b1aeafcae2a2
2. Doing JavaScript-specific stuff without causing a compile error in Java-mode
There are better ways of doing JavaScript-specific if you have a sketch in a web-page, but if you want a sketch to run from the Processing IDE then perhaps putting the JavaScript in a string and calling eval() is the only option? That still left me having to comment a definition of an eval() method in and out when I switched modes, so it was a relief when I was able to move this into my Processing core:
https://github.com/Antony74/Processing/commit/047772019342a879810718feda579c89634a60b8
3. Processing IDE silently fails to open "Box2dWeb-2.1.a.3.js"
This is a pity because Box 2D is a popular API (Angry Birds uses it, though obviously not the JavaScript version), and writing simple fun sketches that make use of a physics engine is exactly the sort of thing that is likely to appeal to Processing.js developers. I assume there's a good reason why Processing doesn't open files containing hypens or extra dots, although it worked perfectly fine or me when I tried it without this restriction, and the problem is easily worked around by renaming the file, but can we have some sort of helpful logging please?
https://github.com/Antony74/Processing/commit/7a0acabaf954ce2faa0648dd4a831ad3ddc96e3e
4. Changes to certain java source code files in the Processing core can cause very strange build errors
I wont go into detail because this has already been discussed here...
https://forum.processing.org/topic/building-processing-from-source-windows
...but it doesn't look anything like a problem caused by the source code changes, because it's run immediately, before the build gets anywhere near a compiler, and it is possible to improve upon the error message given.
https://github.com/Antony74/Processing/commit/ed73b5d683b6d173d954b6a1452bd7d3803b1686
http://www.openprocessing.org/sketch/74982
It uses the Box2DWeb JavaScript API, but is able to run in Java mode too (not just JavaScript mode) due to the use of Rhino, which is a JavaScript interpreter written in Java. Perhaps this is why I tripped over a couple of cross-compatibility issues which may not have been seen before, and there are a couple of other issues I encountered which I'm going to list here too.
Everything I came across I was able to workaround in my sketch, and I also have patches to the Processing source code which address each of these issues. I discussed how to apply a patch from GitHub to an svn working directory here:
https://forum.processing.org/topic/processing-source-code-and-github#25080000001800081
Unless I get other advice, then in about a weeks time I'm going to feed these issues one at a time into the Processing issue tracking system in googlecode, but I thought it would be good to present the whole picture first and give folks the opportunity to comment if they wish to.
It's only fair to point out that my sketch isn't free of bugs either - I have issues with conservation of momentum, transfer of angular momentum, and velocity not absolute but is proportional to the speed of the platform the code is running on. I'm keeping it this way for the sake of simpilicty.
OK, so here's my list:
1. Detecting which mode you're running in
As far as I am aware, there isn't a direct way a Processing sketch can tell which mode it is running in. I'm greatful to Pomax for showing me this trick which exploits type coercion to figure it out...
boolean runningInJavaScript = ( ""+2.0==""+2 );
...although perhaps this is a useful hack rather than a desirable way of going about this? API changes are a delicate matter, so this patch is probably quite reckless ;-)
https://github.com/Antony74/Processing/commit/502865afd9b0fa0585811897a894b1aeafcae2a2
2. Doing JavaScript-specific stuff without causing a compile error in Java-mode
There are better ways of doing JavaScript-specific if you have a sketch in a web-page, but if you want a sketch to run from the Processing IDE then perhaps putting the JavaScript in a string and calling eval() is the only option? That still left me having to comment a definition of an eval() method in and out when I switched modes, so it was a relief when I was able to move this into my Processing core:
https://github.com/Antony74/Processing/commit/047772019342a879810718feda579c89634a60b8
3. Processing IDE silently fails to open "Box2dWeb-2.1.a.3.js"
This is a pity because Box 2D is a popular API (Angry Birds uses it, though obviously not the JavaScript version), and writing simple fun sketches that make use of a physics engine is exactly the sort of thing that is likely to appeal to Processing.js developers. I assume there's a good reason why Processing doesn't open files containing hypens or extra dots, although it worked perfectly fine or me when I tried it without this restriction, and the problem is easily worked around by renaming the file, but can we have some sort of helpful logging please?
https://github.com/Antony74/Processing/commit/7a0acabaf954ce2faa0648dd4a831ad3ddc96e3e
4. Changes to certain java source code files in the Processing core can cause very strange build errors
I wont go into detail because this has already been discussed here...
https://forum.processing.org/topic/building-processing-from-source-windows
...but it doesn't look anything like a problem caused by the source code changes, because it's run immediately, before the build gets anywhere near a compiler, and it is possible to improve upon the error message given.
https://github.com/Antony74/Processing/commit/ed73b5d683b6d173d954b6a1452bd7d3803b1686
1