This is a maintenance release of dyn4j that includes some major bug fixes. See the change detail in the release notes.
The Sandbox app was not updated in this release.
This release of dyn4j includes some major bug fixes for the SweepLine class and other related convex decomposition classes. It also includes some enhancements to the World.detect methods. See the change detail in the release notes.
A new release of the Sandbox was published for this release for a small bug fix.
The JogAmp community held a Ji Gong freedom talk that reminded people to exercise the 4 freedoms granted by the free software licenses in front of the free java developer room audience. The talk also proposed and showcased technical enhancements for High Availability JVM Technology on All Platforms.
Slides from the Ji Gong talk can be obtained at: https://jogamp.org/doc/fosdem2014/
During the same week JogAmp released version 2.1.4 of its high performance java opengl audio & media processing librarys.
This release includes some new highlights:
* Android OpenCL test apk's. This enable you to compile and test an OpenCL JOCL application on desktop and then deploy on Android without using any OpenCL SDK for the phone, the JOCL binding will locate and bind the OpenCL drivers at runtime.
* Enable use of custom mouse pointers and window icons using the NEWT window and input toolkit.
* Multi window support on the Raspberry Pi including mouse-pointer use directly from console!
Complete list of bugs resolved for this 2.1.4 release can be found at:
The #JogAmp #JiGong project will package @OpenJDK + #IcedTea-web to enable good deployment on mobile phone platforms.xerxes // Aug 6, 2013 8:56:07 AM
— Jolla (@JollaHQ) August 6, 2013
JogAmp Ji Gong project announcement
Sven Gothel Aug 04, 2013; 9:45am "
Bug 790 <https://jogamp.org/bugzilla/show_bug.cgi?id=790>
Bug 698 <https://jogamp.org/bugzilla/show_bug.cgi?id=698>
Current Ji Gong Dependency
including the OpenJDK API subset, etc:
1st Milestone - Core JRT for all platforms ..
We are looking for sponsors!
strategy of Oracle of not giving express permission to use OpenJDK
in compliance w/ the 4 freedoms of software (FSF definition).
On the contrary, Oracle gives a patent grant for using OpenJDK for desktop only,
implying mobile use may be prohibited.
This implication is highly likely non-sense, especially in the light of
the latest Oracle vs Google case where Oracle was not able to
substantiate a patent infringement by Google's Dalvik VM.
As Xerxes put it: The horse is bound to a chair and is not running ..
Ji Gong <https://en.wikipedia.org/wiki/Ji_Gong>
"Unlike a traditional Buddhist monk, Daoji did not like following traditional monastic codes. Daoji had a penchant for openly eating meat and drinking wine; his robes were often tattered and dirty from travelling from place to place, and stumbling while intoxicated. However, Daoji was kind hearted and was always ready to lend a helping hand to ordinary people. He would often treat the sick and fight against injustice. The monks, bewildered and fed up with his behavior, expelled Daoji from the monastery. From then on, Daoji roamed the streets and helped people whenever he could."
Hence Daoji does people good while not necessarily conforming to certain arbitrary rules,
while maintaining sanity and being kind hearted.
The character is quite popular in the Asian culture.
This project shall match the kind direction of it's name giving character,
while also serving w/ JogAmp's goals of being a technology enabler.
Ji Gong shall enable the VM technology across platform and devices.
However, until the goals below and this spirit of a free solution is being picked
up, we may continue pushing it forward from here.
Note: Bug 698 sadly wasn't being replied to by neither Oracle nor the OpenJDK team.
Of course, no surprise here, since for Oracle it might be a conflict of interest
due to their 'goals' to market their ARM hotspot proprietary solution
and the OpenJDK team consist mainly of Oracle and RedHat members.
The latter focuses on server solutions and is highly cooperating w/ Oracle.
- Availability of the GPLv2 based OpenJDK runtime environment (JRT/JVM)
- Desktop (Linux, Windows, OSX, ..)
- Mobile (Android, other phones and tablet OS [maybe even iOS])
- VM CPU support:
- Intel/AMD 32bit and 64bit
- ARM based CPUs [Hotspot client/server n/a at time of writing. May need to use JamVM or AvianVM, ..]
- Optional AWT/Swing/etc - maybe added at a later time
- Web Plugin based on IcedTea-Web (JWeb)
- Capable to run w/o AWT using a pluggable windowing subsystem implementation
- Optional AWT/Swing/etc - maybe added at a later time
" Quoted from:
JogAmp forum: Project: Ji Gong http://forum.jogamp.org/Project-Ji-Gong-td4029738.html
JogAmp JOGL, JOCL & JOAL provide cross platform Java™ language bindings to the OpenGL®, OpenCL™, OpenAL and OpenMAX APIs. JogAmp is a convenient enabler to give Desktop and Mobile applications access to hardware DSP & GPU units using a modular cross platform API.
This JogAmp JOGL version 2.0.2 release marks the end of the first major JogAmp release cycle that started with the v2.0-rc1 around two and a half years ago, "End of RCs ..". JogAmp JOGL is a modern successor to the no longer maintained JOGL 1.1.1a. The 2.0.2 release added support for OpenGL versions up to 4.3, and OpenGL ES versions 1, 2, and 3.
The JogAmp team hosted one, awesome, party at the JogAmp BOF @ Siggraph 2013!
This years SIGGRAPH JogAmp BOF was dedicated to all the many amazing projects using JogAmp. We did try our best to demo as many projects as possible that we where able to fit into our session. One dude (MIT researcher) put it well, it was like "drinking from a fire-hose"; enjoy the demo flood!
Kudos to Qun who recorded the show! Here is a convenient time line to the many sections and topics covered during the talk:
- LEGACY -
- GAMES -
- UI -
- Art / Science -
- JogAmp -
- Finale -
Slides from the BOF is available at the jogamp.org site: http://jogamp.org/doc/siggraph2013
JogAmp is the home of high performance Java™ libraries for 3D Graphics, Multimedia and Processing.
JOGL, JOCL and JOAL provide cross platform Java™ language bindings to the OpenGL®, OpenCL™, OpenAL and OpenMAX APIs.
Running on Android, Linux, Window, OSX, and Solaris across devices using Java.
This 2.0.2-rc12 release include the largest security review in the 10-year history of JOGL
- Security Fixes
- Dynamic Linker Usage / Impl.
- ProcAddressTable field visibility
- Perform SecurityManager checks where required
- Validation of property access
- JAR Manifest tags:
- Use latest Java7 toolchain
- Generating Java 1.6 bytecode
- HTML API doc
Security fixes are marked in red on the above bug tracking page.
JogAmp send out thanks to the FuzzMyApp security researchers for healthy communication that triggered the security review work.
If you find an issue with the release, please report it to our bug database under the appropriate component. Development discussion takes place inside the JogAmp forum & mailing-list and the #jogamp IRC channel on irc.freenode.net.
Meet us @
While being asked about JavaFX and whatever other Oracle, Google or
whatever technology, all I can say: I don’t really care – as long it’s free
and complies w/ the 4 freedoms of software.
Lately Oracle even made the proposal JEP 178: Statically-Linked JNI Libraries,
allowing Java applications using JNI within a statically deployed runtime. Read: May work on Apple’s iOS.
IMHO the real issue of being able to deploy ‘Java Tech’ on any platform including mobile/embedded devices is not whether Oracle allows static JNI linkage,
but to allow deploying a custom JRE in the first place.
It is Oracle herself who restricts her patent grant to non embedded devices, hence ‘Java Tech’ does not comply w/ the 4 freedoms of software, see:
IMHO the most advancement Oracle could make to ‘Java Tech’ would be
a general patent and license grant, so you actually would be able to
legally use and deploy your Java’ish builds anywhere and be free
without the hassles and fears of a multimillion dollar battle.
Let it be a build based on OpenJDK, Apache Harmony, DalvikVM .. or whatever
Just my 2 cents ..
[Java is a registered trademark of Oracle, Incl.]
OpenGL ES 2 drivers
Excellent post by cnx-software listing all the reverse engineering effort put into bringing opensource ARM GPU drivers to GNU/Linux.
The post links and embeds libv's excellent FOSDEM 2013 reverse engineering ARM GPU driver talk.
The lima and freedreno reverse engineered drivers are both now known to be able to run Quake 3. The lima driver is now actually faster than the closed source ARM Mali driver!
http://libv.livejournal.com/24092.html - Hey ARM!
We are not going away, we are here to stay. We cannot be silenced or stopped anymore, and we are becoming harder and harder to ignore.
It is only a matter of time before we produce an open source graphics driver stack which rivals your binary in performance. And that time is measured in weeks and months now. The requests from your own customers, for support for this open source stack, will only grow louder and louder.
So please, stop fighting us. Embrace us. Work with us. Your customers and shareholders will love you for it.
OpenGL ES 3 drivers
Intel have taking the lead and released all their OpenGL ES 3 driver code into Mesa
http://cgit.freedesktop.org/mesa/mesa/log/?h=gles3 - this is how you should work, kudos to Intel.
OpenCL ARM GPU drivers
Android have for a long time refused vendors to ship ARM OpenCL drivers on Google approved Android devices.
http://code.google.com/p/android/issues/detail?id=36361 - Android lead Declined Support for OpenCL
Over night everything changed:
Google ships secret #ARM #MALI T-604 #OpenCL driver in Nexus 10 to accelerate Renderscript.
The OpenCL SDK for ARM Mali is now available! http://bit.ly/YOS1YA #opencl #gpu @ARMMultimedia
OpenCL drivers for Samsung Exynos 5 board landed here: http://streamcomputing.eu/knowledge/sdks/samsung-exynos-5-board/
Also the Zii labs ZMS line supports CL http://codedivine.org/2013/02/01/renderscript-from-the-perspective-of-an-openclcudac-amp-programmer/
Amazon android line is rumored to support CL as well...
So with all these new news surfacing it looks like ARM devices running the new T-604 MALI GPU will have OpenCL drivers especially the Google Nexus 10 tablet that is reported to include the drivers in the stock install!
So this means we now have a good way to hardware accelerate FFT on ARM using OpenCL!
I want to use #OpenCL on #ARM to do fast live music #FFT analysis for better jazz music on the go
JogAmp have implemented OpenCL bindings on GNU/LInux and packaged .apk for Android feel free to jump in and help with testing on real devices!
The current priority list for JogAmp OpenCL and OpenGL ES 3 integration is found inside the forum: http://forum.jogamp.org/JInput-Delivery-tp4028209p4028210.html
Because the ARM JVM still cant differensiate ABI in its system properties #JogAmp #Gluegen now implement an ELF header parserxerxes // Feb 8, 2013 10:55:28 PM
This post is about an solution to an old chest nut that still plague ARM Java users on both servers, desktop and mobile. The problem it the impossibility to query the JVM system properties to find out the ABI armel/armhf in use, on ARM systems and possible other ARCH ABI variants as well such as x32, because no information about the ABI is exposed using said system properties. http://download.java.net/jdk8/docs/api/java/lang/System.html#getProperties%28%29 It is mandatory for developers to know the ABI in use at runtime in order to load matching JNI libraries.
About one year ago in 2012 the question got raised inside the #OpenJDK IRC channel http://icedtea.classpath.org/wiki/New_os.arch_namespace_Architecture but nothing really happened.
Later in 2012 the same question got raised inside the Raspberry Pi community during the move to the new Rasbian armhf system, http://www.raspberrypi.org/phpBB3/viewtopic.php?p=201105 but nothing really happened except adding more or less creative workarounds to all ARM Java applications and libraries.
The Raspberry Pi community eventually added a Java specific forum and now Oracle engaged in the community and asked for questions: So the question got raised again.
In the end of 2012 Oracle launched their first armhf JVM for the Raspberry Pi but the os.arch namespace was still not fixed, after reporting a workaround for the new JDK 8 EA http://www.raspberrypi.org/phpBB3/viewtopic.php?p=238135#p238135 Oracle took notice.
In the beginning of Jan 2013 Oracle Bob Vandette started an discussion on how to introduce an extended properties namespace that would cover the ABI differences to let applications discover the ABI at runtime.
During the FOSDEM 2013 JogAmp re-raised the question in front of the Oracle audience at 19m23s into the JogAmp talk and the response was "We just discussed that last week". So our reply is "So we can not wait for that". This issue is still causing hairpulling for ARM Java server/desktop/mobile deployments where for example the JVM tries to load armel JNI on the new armhf ARM Linux systems because the system properties set by the new armhf JVM is identical to an armel JVM, loading a library of the wrong ABI do not work.
Q: So what can we do about it?
A: Include an #freejava ELF header parser of course!
#JogAmp #gluegen now implements and use the following ELF header parser: http://jogamp.org/git/?p=gluegen.git;a=commit;h=371e1dbff6f5f255ab27ed0ab32368abb06eed82 … in order to find out the ABI at runtime without relying on if proper #JVM os.arch & ABI properties are set or not.
Kudos to Sven Gothel for implementing the new ELF header parser using the Gluegen StructAccessor.
Kudos to Andrew Haley, aph, who hatched the idea inside the #OpenJDK IRC channel to scan /proc/self/exe using an elf header parser from within the Java process itself and look for the Tag_ABI_VFP_args ELF header flag, this is what the implemented gluegen solution is based on.