Oracle Java[tm] 8u202 last supported version for JogAmp

Sven // May 14, 2019 10:28:50 AM

Oracle Binary Code License

Around January 2019, Oracle made its last Java[tm] release, namely 8u202, under their Oracle Binary Code License Agreement for the Java SE Platform Products and JavaFX, last updated 21 September 2017.

This binary license still allows personal and commercial users to use and distribute their binary freely, i.e. commercially use the JDK + JRE, bundle the application w/ the JRE and even distribute the JDK unchanged within an electronic magazine.

Oracle Technology Network License

Thereafter, starting April 16, 2019, Oracle made their Java[tm] builds available under the new Oracle Technology Network License Agreement for Oracle Java SE, last updated: April 10, 2019.

This new license doesn’t allow commercial use or even bundling of their new binary builds.

JogAmp’s Java[tm] Support

Therefor, the JogAmp project is not capable to support Oracle Java[tm] builds with the new license under our free software work. Only exception would be special sponsorship to support said new licensed Oracle Java[tm] builds.

JogAmp continues to support OpenJDK builds, like AdoptOpenJDK.

Version 3.3.0

William Bittle // Apr 15, 2018 7:58:19 PM

This release was focused on Java 9, OSGi, and Maven but also includes some behavior changes and performance improvements.

For those just using the library, the behavior changes to be aware of are:

  • The GJK algorithm has changed slighty.  It now exits after N number of iterations.  This has been changed to ensure that the algorithm doesn’t run forever in some rare instances.  If you need to go back to the original behavior you can set the maximum number of iterations to Integer.MAX_VALUE, but it’s not recommended.
  • The ContactListener.sensed method is deprecated now and is no longer being called.  Instead, you will get notifications of sensed contacts through the other methods (begin, persist, etc.). This was done so that sensed contacts have the same lifecycle as normal contacts.  There’s a flag on the Contact argument that flags the contact as a sensor contact.
  • Some of the ContactListener methods should return true or false, indicating whether the contact should be solved or not.  The behavior here has changed a bit.  Before 3.3.0 the processing of that contact would halt whenever false was returned and drop the contact.  The new behavior is that the contact proceeds as normal through the pipeline, but is just disabled from contact resolution.  The effect is the same, apart from the fact that all caching information and the contact’s state is retained.

Version 3.2.4

William Bittle // May 2, 2017 4:36:39 AM

This is a maintenance release to fix the issue where the a Joint removed from a World cannot be added back or to a different world due to an internal member not being cleared.

Version 3.2.3

William Bittle // Sep 4, 2016 8:41:14 PM

This release fixes issues with the getRadius(Vector2) method for the Slice, Capsule, Ellipse, and HalfEllipse shapes under local rotation and fixes the detect(AABB) method in the Sap broadphase.

Sadly, the getRadius(Vector2) method for the Ellipse classes boils down to a maximization/root finding problem.  Thankfully, the method should be called rarely so should have negligible performance impact.

Version 3.2.2

William Bittle // Jun 20, 2016 5:49:41 AM

This release is primarily for a new collision shape called Link. This shape extends the existing Segment shape and provides for smooth sliding across chains of Links.

There were some minor fixes and code clean up as well.

Version 3.2.1

William Bittle // Nov 24, 2015 3:38:22 AM

This is a maintenance release to fix a few critical bugs in the Polygon, Rectangle, and Segment classes for local rotations (see this post for details).

This release also contains some small enhancements (a few new methods) to some of the joints and a complete rewrite of all the joint class javadoc documentation.  The documentation should be much easier to read and should explain common use.

Version 3.2.0

William Bittle // Oct 1, 2015 6:00:06 AM

The primary goals for this release were performance enhancements and API clean up.  It took a lot longer than I had expected but I’m very happy with the results.  Highlights include improvements in the performance of collision detection and ray casting operations and a much cleaner public API and more thorough javadoc comments.Turbo Meme

The API has been changed a good bit and you’ll find some breaking changes.  Most, if not all, should be simple find/replace changes, the behavior should remain the same.  Those of note are:

  1. Body.setMass() was deprecated.  Use Body.setMass(MassType) instead.
  2. Mass.Type was renamed to MassType.
  3. MouseJoint was renamed to PinJoint.

All this got me thinking of the old days of the Turbo button which funny enough did the opposite of what you’d think…


Processing 3 is running for the first time on a Raspberry Pi using Eric Anholt’s Mesa3D VC4 driver

xerxes // Jul 10, 2015 12:32:28 PM

Processing 3 is running for the first time on a Raspberry Pi using Eric Anholt’s Mesa3D VC4 driver!

Video of the Processing 3 RGB cube demo running on the Raspberry Pi using Eric Anholt’s Mesa3D VC4 OpenGL 2 driver:

Thanks to the free software Mesa3d vc4 driver, the raspberry pi suddenly turned from a mobile opengl es 2 system into a “desktop” opengl 2 system.

Processing 3 is using JogAmp JOGL to tap into OpenGL hardware acceleration on the armv6 Raspberry Pi 1 and armv7 RaspberryPi 2 systems.

Hold on what is going on here, how can I setup the free software vc4 driver on my Raspberry Pi system?

This is a collaboration with Eric Anholt, anholt, and Gottfried Haider, gohai, to get Processing 3 running on the Raspberry Pi.

Eric Anholt has worked about a year to implement a full OpenGL 2 Mesa3D driver for use on the Raspberry Pi by using the Video Core 4, VC4, GPU.

Getting Eric Anholt’s Mesa3D VC4 driver running on a Raspberry Pi is easily done thanks to the work by gohai.
gohai started out roughly following Eric’s notes here:
And then put together a buildbot in Python, to produce system images for use on the Pi or Pi2.

Kernel, Mesa, XServer packages & dependencies are from git. System image produced using gohai’s buildbot

gohai publish daily builds using his bot at:

Myself I have contributed to fix corner-cases in JogAmp JOGL OpenGL initialization to get it all running.

What was the problem using the proprietary OpenGL ES vc4 driver on the Raspberry Pi system?

The OpenGL ES standard do not cover how the native window is initialized.
When you initialize opengl es then you must pass a platform specific EGLNativeWindowType, EGLNativePixmapType and EGLNativeDisplayType depending on the OS you use.

If you read the Khronos header for eglplatform.h you will notice that the EGLNativeWindowType is different for
Windows: typedef HWND EGLNativeWindowType;
Mac: typedef void *EGLNativeWindowType;
Android: typedef struct ANativeWindow* EGLNativeWindowType;
Unix X11: typedef Window EGLNativeWindowType;

Creating an on-screen EGL rendering surface requires you to to use the eglCreateWindowSurface function, which takes a EGLNativeWindowType parameter. On the Raspberry Pi, however this is implemented as a EGL_DISPMANX_WINDOW_T struct, which is defined in eglplatform.h as:

typedef struct {
int width; /* This is necessary because dispmanx elements are not queriable. */
int height;

As you can see RaspberryPi using the properitary binary drivers uses a Broadcom unique native window type that is incompatible with X11.
This is the reason why we cant use the Processing code as is to pass a Java AWT Unix X11 Window to initialize OpenGL ES, EGL will return an error that you have passed an incompatible structure to eglCreateWindowSurface.

When using Eric Anholt’s Mesa3D vc4 driver then EGL will expect a Unix X11 Window for its EGLNativeWindowType and this is why processing will work out of the box when Erics Mesa3D vc4 driver in use. Eric’s vc4 driver also implements OpenGL 2 that can be initialized using GLX. GLX allows you to run Processing with OpenGL acceleration across remote X11 network connections!

Xerxes Rånby

dyn4j Moved to GitHub

William Bittle // Mar 14, 2015 7:07:35 AM

Due to Google’s decision to drop Google Code, I’ve moved the project to GitHub.  In truth, I’ve been contemplating this for a while now, but have had reservations about lost version history.  I feel this will help others contribute bug fixes and allow them to create their own forks and branches easier than before.

I haven’t fully check the revision history, but it looks like everything came over as expected.  I had to manually move all the wiki pages, but I was planning to do this anyway as well.  You can find them under Documentation on

JogAmp Release 2.3.0

Sven // Mar 12, 2015 12:00:36 PM

Release 2.3.0 has been published:

The test applets.

Overview of notable fixed bugs:


introducing API CHANGES.
It CAN NOT be used as a binary/jar drop-in replacement.

API Changes
Extracted from our GlueGen and JOGL semantic versioning unit tests!

See Semantic Version Numbers