GNU Classpath

Finally a new release of PRICE!Get it here: https://sourceforge.net/projects/price/files/1.3.0/ This version improve Mac support quite a bit, Apple made several changes since 10.6 which caused malfunctions and weird symptoms (and which fix occasional ... [More] stuff on 10.4 too). Both PowerPC and x86 work fine!Many bug fixes, memory issues, bug in filters fixed.Curves can now be manipulated with handles Edge/tracing ignores the alpha channelPreview supports scalingSupport by on-load conversion of alpha-first imagesGreyscale and Inversion support 16bit images, highly experimental! The current approach looks unpractical to extend to all filters since the code-path needs to be doubled though.Custom Edge Tracer, PRICE on GNUstepCurves Editing, PRICE on MacOS [Less]

The schedule for the Free Java Devroom just appeared online: https://fosdem.org/2015/schedule/track/java/ I’m looking forward to enjoy this Fosdem, not only the Free Java DevRoom itself has lots of great content, but as it is usually the case the ... [More] same can be said about most other DevRooms. It will be a very difficult choice to decide where to go and what to see :) [Less]

New Year's Eve Edition: GWorkspace 0.9.3 released!GNUstep's workspace got plenty of attention, fixes and improvements, here a summary:viewer preferences and status are now stored reliably (you may need to delete your old defaults)file operation ... [More] now work concurrently as they shouldfile operations can be paused/resumed more easily and reliably - many memory leaks related to file operations fixed! Less bloating during usage - fixes for clang/libobjc2 runtime - improved host-name setting (previously, on some machines localhost was used) - Recycler may unmount volumes now - Fixes and performance increases with browser drawing - improvements in File operations errors (permissions, etc) - fixes when renaming files without permissions - further 64bit and portability fixes NOTE: you may need to delete your current defaults (type "defaults delete GWorkspace") for the new viewer status saving to work correctly [Less]

You can find the original announcement here It was a very a difficult choice this time and it took a bit to understand the best schedule and try to get the most tracks. This is the list of approved talks, in no particular order. Thanks to anyone ... [More] who participated, unfortunately we were not able to select every one, and the choice this year was insanely difficult! I hope the speaker who we could not select will still join us to enjoy what we are preparing for this year Free Java DevRoom celebrations! Packed Objects, Object Layout & Value Types – a Survey Shenandoah – Project overview Sustaining the zero assembler port in OpenJDK: An inside perspective of CPU specific issues Open Heart Surgery: HotSpot Debugging at the OS Level Life in the trenches The State of OpenJDK Java 9: Make Way for Modules! Beyond Java 9 What Three Big Development Trends Mean for Java The ARM microJIT What Lies Beneath?: Lessons learned hacking the OpenJDK interpreter/compilers JCP State of the Union & Progress Report Diagnosing Performance Issues Using Thermostat Caciocavallo, or how we ported OpenJDK from embedded to cloud and still liked it Java restart with WebFX The Wisdom Of Crowd Testing OpenJDK InvokeBinder: Fluent Programming for Method Handles OpenJDK Adoption Group Q&A Fortress IcedTea-Web goes offline and beyond MappedByteBuffer Operations SpeedUp of 150x Cache2k, Java caching turbo charged Building an open Internet of Things with Java and Eclipse IoT JFree – The Long and Winding Road (Ahead) Jitsi Videobridge in Cryptoland: the adventures of a Java WebRTC video router on the road to supporting 1000s of video streams [Less]

As I wrote previously, Project Jigsaw is coming into JDK 9 in several large steps. JEP 200 defines the modular structure of the JDK, JEP 201 reorganizes the JDK source code into modular form, and JEP 220 restructures the JDK and JRE run-time images ... [More] to support modules. The actual module system will be defined in JSR 376, which is just getting under way, and implemented by a corresponding JEP, yet to be submitted. We implemented the source-code reorganization (JEP 201) last August. This step, by design, had no impact on developers or end users. Most of the changes for modular run-time images (JEP 220) were integrated late last week and are now available in JDK 9 early-access build 41. This step, in contrast to the source-code reorganization, will have significant impact on developers and end users. All of the details are in the JEP, but here are the highlights: JRE and JDK images now have identical structures. Previously a JDK image embedded the JRE in a jre subdirectory; now a JDK image is simply a run-time image that happens to contain the full set of development tools and other items historically found in the JDK. User-editable configuration files previously located in the lib directory are now in the new conf directory. The files that remain in the lib directory are private implementation details of the run-time system, and should never be opened or modified. The endorsed-standards override mechanism has been removed. Applications that rely upon this mechanism, either by setting the system property java.endorsed.dirs or by placing jar files into the lib/endorsed directory of a JRE, will not work. We expect to provide similar functionality later in JDK 9 in the form of upgradeable modules. The extension mechanism has been removed. Applications that rely upon this mechanism, either by setting the system property java.ext.dirs or by placing jar files into the lib/ext directory of a JRE, will not work. In most cases, jar files that were previously installed as extensions can simply be placed at the front of the class path. The internal files rt.jar, tools.jar, and dt.jar have been removed. The content of these files is now stored in a more efficient format in implementation-private files in the lib directory. Class and resource files previously in tools.jar and dt.jar are now always visible via the bootstrap or application class loaders in a JDK image. A new, built-in NIO file-system provider can be used to access the class and resource files stored in a run-time image. Tools that previously read rt.jar and other internal jar files directly should be updated to use this file system. We’re aware that these changes will break some applications, in particular IDEs and other development tools which rely upon the internal structure of the JDK. We think that the improvements to performance, security, and maintainability enabled by these changes are, however, more than worth it. We’ve already reached out to the maintainers of the major IDEs to make sure that they know about these changes, and we’re ready to assist as necessary. If you have trouble running an existing application on JDK 9 build 41 or later and you think it’s due to this restructuring, yet not caused by one of the changes listed above or in JEP 220, then please let us know on the jigsaw-dev mailing list (you’ll need to subscribe first, if you haven’t already), or else submit a bug report via bugs.java.com. Thanks! [Less]

As I wrote previously, Project Jigsaw is coming into JDK 9 in several large steps. JEP 200 defines the modular structure of the JDK, JEP 201 reorganizes the JDK source code into modular form, and JEP 220 restructures the JDK and JRE run-time images ... [More] to support modules. The actual module system will be defined in JSR 376, which is just getting under way, and implemented by a corresponding JEP, yet to be submitted. We implemented the source-code reorganization (JEP 201) last August. This step, by design, had no impact on developers or end users. Most of the changes for modular run-time images (JEP 220) were integrated late last week and are now available in JDK 9 early-access build 41. This step, in contrast to the source-code reorganization, will have significant impact on developers and end users. All of the details are in the JEP, but here are the highlights: JRE and JDK images now have identical structures. Previously a JDK image embedded the JRE in a jre subdirectory; now a JDK image is simply a run-time image that happens to contain the full set of development tools and other items historically found in the JDK. User-editable configuration files previously located in the lib directory are now in the new conf directory. The files that remain in the lib directory are private implementation details of the run-time system, and should never be opened or modified. The endorsed-standards override mechanism has been removed. Applications that rely upon this mechanism, either by setting the system property java.endorsed.dirs or by placing jar files into the lib/endorsed directory of a JRE, will not work. We expect to provide similar functionality later in JDK 9 in the form of upgradeable modules. The extension mechanism has been removed. Applications that rely upon this mechanism, either by setting the system property java.ext.dirs or by placing jar files into the lib/ext directory of a JRE, will not work. In most cases, jar files that were previously installed as extensions can simply be placed at the front of the class path. The internal files rt.jar, tools.jar, and dt.jar have been removed. The content of these files is now stored in a more efficient format in implementation-private files in the lib directory. Class and resource files previously in tools.jar and dt.jar are now always visible via the bootstrap or application class loaders in a JDK image. A new, built-in NIO file-system provider can be used to access the class and resource files stored in a run-time image. Tools that previously read rt.jar and other internal jar files directly should be updated to use this file system. We’re aware that these changes will break some applications, in particular IDEs and other development tools which rely upon the internal structure of the JDK. We think that the improvements to performance, security, and maintainability enabled by these changes are, however, more than worth it. We’ve already reached out to the maintainers of the major IDEs to make sure that they know about these changes, and we’re ready to assist as necessary. If you have trouble running an existing application on JDK 9 build 41 or later and you think it’s due to this restructuring, yet not caused by one of the changes listed above or in JEP 220, then please let us know on the jigsaw-dev mailing list (you’ll need to subscribe first, if you haven’t already), or else submit a bug report via bugs.java.com. Thanks! [Less]

The first release candidate is available. It can be downloaded here or from NuGet. What's New (relative to IKVM.NET 7.4): Merged OpenJDK 8 b132. Support for Java 8 features. Improvements to ... [More] sun.misc.Unsafe compatibility. Various bug fixes. Changes since previous development snapshot: Assemblies are strong named. Binaries available here: ikvmbin-8.0.5449.0.zip Sources: ikvmsrc-8.0.5449.0.zip, openjdk-8-b132-stripped.zip [Less]

With the fixes I did in the snapshot released on October 29, it is now possible to run Minecraft on IKVM.NET (on Windows). To be clear, I'm talking about the Minecraft client, not the server that has been running on IKVM.NET for a long time. ... [More] The Minecraft client uses native code for the 3D graphics and sound, so it doesn't run into IKVM limitations there. To get it to run download the most recent IKVM.NET snapshot (currently available here) and unzip it. Download minecraft.jar and run it like this: ikvm -jar minecraft.jar It takes a while to start up, so be patient. If you get an exception when trying to log in, you may have to visit https://authserver.mojang.com/ in Internet Explorer to add the root certificate to the Windows certificate store (just visiting the site causes IE to download it from Microsoft). After that you have to restart Minecraft. [Less]

Getting closer to a release. Changes: Optimized ForkJoinPool unsafe usage. Optimized java.lang.[Integer|Long].[compare|divide|remainder]Unsigned(). Bug fix. Default interface methods should not ... [More] conflict with their own base interfaces. Bug fix. Miranda method in base class should not interfere with default interface methods. Bug fix. Conflicting default interface methods should throw IncompatibleClassChangeError instead of AbstractMethodError. Bug fix. LockSupport.parkUntil() didn't convert milliseconds to nanoseconds. Implemented TwoStacksPlainDatagramSocketImpl.socketLocalAddress() and TwoStacksPlainDatagramSocketImpl.isAdapterIpv6Enabled(). Made sun.misc.Unsafe interlocked operations truly atomic (except for unaligned array access and int/long array access on different array types). Made sun.misc.Unsafe array access more compatible with JDK. It is now possible to get/set primitive values from arrays of a different (primitive) type. Fixed font file clean up issue on Windows 8. Bug fix. NetGraphicsDevice.getDefaultConfiguration() should take the screen into account. Thanks to Maria Papendieck for this fix. Bug fix. NetComponentPeer.getLocationOnScreen() should take insets into account. Thanks to Maria Papendieck for this fix. Binaries available here: ikvmbin-8.0.5436.zip [Less]

Alright, I repeat, I’m not a lawyer. But the recent move from Microsoft to release part of the .Net runtime under the very permissive MIT license still hides the usual issues. Unlike what Miguel De Icaza says on his blog, this patent promise does not ... [More] address the “historical concerns that the open source, Unix and free software communities have raised over the years“. MIT doesn’t protect you from patents by default, as Miguel noted, so Microsoft added a patent promise. Unfortunately, I don’t think this is satisfactory, let me quote the main point for you: Microsoft Corporation and its affiliates (“Microsoft”) promise not to assert any .NET Patents against you for making, using, selling, offering for sale, importing, or distributing Covered Code, as part of either a .NET Runtime or as part of any application designed to run on a .NET Runtime. Let me quote again: …as part of either a .NET Runtime or as part of any application designed to run on a .NET Runtime… So, here it is. Modify this source code, and you’ll get into the trap. This is very different than using the code of course. I would be very surprised if Microsoft would sue me for writing a .Net application, it would be silly and counter productive, so anyone can just assume that as well. But modifying and redeploying the original code of the runtime itself? If you are writing a program for the modified runtime, as long as it works without any issue on the original runtime you should be fine, but as an ISV, where does it put you in respect to the runtime code itself? I don’t think there will be any issues in the immediate future, Microsoft itself can’t afford to start suing anyone just because they try to bundle the .Net code, but I fear it will happen once adoption is high enough to justify it. After all, Microsoft main business model those days seems to be heavily based on patent trolling, they are doing tons of money over patent disputes, why should they give up this remunerative model? I suggest, if you didn’t do before, to read as an example this very interesting article from my dear friend Simon Phipps. So, just to be clear, I’m not trying to FUD over Microsoft here, it’s entirely possible that Microsoft is really changing. I do believe that this may open the option of adoption of the .Net runtime on non Microsoft platforms, as long as it remain the .Net runtime as Microsoft intended it be. It will be interesting to see what Linux distribution will do with this code, for example, but I hardly doubt it will ever be the first level choice, especially when so great and better alternatives exist that are truly open. For example, Microsoft refusal to join the Open Invention Network is an hint that the runtime is still largely hostile territory. This may radically change if they decide to join OIN though, so only time can tell us. My suggestion would be, if you’re into investing in .Net, to double check with your lawyer first and then put pressure on Microsoft to join OIN. Now, a word of disclaimer. I usually don’t really express many opinion that are deeply work related on this blog, but now it’s quite needed. The opinion expressed in this blog are mine, they are not based on any informed facts of my company line of business, they are solely my own point of view, they do not necessarily represent the point of view of my Employer in any form or mean and are to be taken as is. [Less]