GNU Classpath

Grr 1.0, the RSS Reaseder, and its compantion framework RSSKit 0.4.0 were released on Friday.

I found and fixed a code generation bug, so a new release candidate. The bug has been around since the very early days, but a change in 2010 made it more likely to surface. It showed up while debugging the Derby problem reported by ... [More] Dash in the comments here. Changes (relative to rc 1): Updated version to 7.1.4532.2 Fixed a code analysis bug that under specific circumstances caused incorrect local variable types or null reference loads from local variables. When the final release is done, it will include the full release notes. Binaries available here: ikvmbin-7.1.4532.2.zip Sources: ikvmsrc-7.1.4532.2.zip, openjdk-7u4-stripped.zip [Less]

I bought the Pulse-Eight USB CEC adapter a few months back and so far it’s been a great addition to my XBMC setup. For a long time I wanted to control my TV from my Android phone, for a few reasons. First, I usually have it with me and charged up ... [More] , unlike my TV remote which might be misplaced or out of batteries. Second, I find it annoying that the infrared TV remote requires line-of-sight. And finally, a smart phone remote just seems like the right way to control a TV in this day and age. For such a tiny package the Pulse-Eight adapter enables a lot of functionality. I can turn my TV on and off from my phone over Wi-Fi, using the Official XBMC Remote Android app and a slightly-hacked version of XBMC. But there’s more. Guests who prefer using a TV remote can use its extended buttons to control XBMC playback. The adapter enables communication in both the TV-to-XBMC and XBMC-to-TV directions by passing CEC commands over the HDMI bus. And its inventors maintain a Free Software library, libcec, to control it. This is a much cleaner and cheaper solution than the various Wi-Fi-to-IR converters I’ve looked at. If you run XBMC make sure to check out this adapter. [Less]

On behalf of all committers and contributors, I’m very proud to announce that the Eclipse Linux Tools project version 1.0 release is ready! This release is available today as part of the Juno simultaneous release. An easy way to get started using ... [More] our plugins is to download the Eclipse IDE for C/C++ Developers. Of course, many of these plugins will also be available in Linux distributions and one can also install from our p2 repository. See our downloads page for more information. Many people have made this release possible including the Eclipse Foundation staff, all the kind people who have reported bugs and requested features, those who submitted patches, and of course the committers. Thank you to all! According to git, the following 41 people have written code that exists in our repos: Alexander Kurtakov Alexandre Montplaisir Alphonse Van Assche Alvaro Sanchez-Leon Andrew Overholt Anithra P Janakiraman Benjamin Drung Ben Konrath Bernd Hufmann Charley Wang Chris Aniszczyk Corey Ashford Daniel Barboza Franco Daniel Drigo Pastore Daniel Henrique Barboza Daniel Henrique Debonzi Dmitry Kozlov Elliott Baron Fabio Fantato Francois Chouinard Jeff Johnston Kent Sebastian Krzysztof Daniel Kyu Lee Markus Knauer Matthew Khouzam Mauren Brenner Nick Boldt Niels Thykier Otavio Luiz Ferranti Otavio Pontes Patrick Tasse Phil Muldoon Rafael Medeiros Teixeira Roland Grunberg Sami Wagiaalla Severin Gehwolf Stephen Shaw Wainer S. Moschetta William Bourque Xavier Raynaud Congratulations also to all those involved in the larger Juno release which is comprised of 72 projects and 55 million lines of code! [Less]

The Thermostat team has finally pushed out a new release of the greatest monitoring tool of all times!The relese, code named "Not Yet", offers tons of new features since last official release (although some of them available already to who is using ... [More] the development versions).A noteworthy addition to this release (of which I already blogged during the final phases of its development) is the introduction of a new heap analyser, together with an improved Command Line Client, better separation and isolation of the code by using OSGi, and various plugins. Roman has blogged already abut the future plans for the heap tool, so I direct you to his blog for more details.What I want to show you here, instead, are some of the graphical subtleties that make Thermostat already now one of the nicest tool around.First of all, even if we support pluggable look and feel, the default LAF is an in house theme that resembles the Adwaita theme from Gnome 3.The theme is not complete, but is shaping nicely day after day, and it already support some features, like the scrollbars and tabbed pane:As well as some nicely rendered menues (but they are not part of the release, since I could not push them in time): From the usability point of view, since all the data for the tracked VM is available across the distributed Mongo Instances (right now, we only support local systems though), it's important to offer users feedback of running or not running jvms, so we borrowed a feature from the Eclipse IDE, and exported an API for plugins to install custom decorators: I want to stress the fact that both the decorated icon and the main icon are supplied by plugins. In fact, the whole Thermostat UI is just a plugin container that deliverts the information collected by the hub to the plugins.Plugins can install new type of information if they need to.The kill switch is another example of plugin that hooks into the UI, allowing to terminate java processes in case of need: Thermostat plugins can install two types of views at this stage (although a note of warning is mandatory, the API is not finalized yet), which I define as Renderable and Managed.A renderable view is a view that takes the burden of rendering and installing its own components. We currently support Swing Views, although we are in the process of making the View API generic so that we can allow SWT or other component types. Each Renderable view needs a controller to do anything useful, and although we are trying to not force on plugins the same MVC layout we use internally, by doing this we are able to support reuse of the controllers while simply pluggin new views.Managed views are views that install functional elements like menues or decorators at various pre defined entry points, and let the platform carry on the task of rendering them, usually by means of filters that are associated with the specific VM or other aspect of the system depending of the entry point.Another feature we introduced in this release is the Memory Detail View, which is a view that shows the groth of the memory use together with the current values. Observing this view is very interesting, since it gives a very good overview of the performance, in terms of memory, of the VM, and allows to track very quickly for memory leaks or other anomalies: This is especially true when comparing this view with the Heap Dumper:Which instead offers a summary of the heap, without the details of the memory view. This is a big plus in thermostat, since we firmly believe in information redundancy. We think that allowing users and administrators to view the same set of data correlated and presented in different ways makes much easier the analysis task, which ultimately is meant to detect problem quiker.Also, once again, even in this case, both views are completely based on plugins. You can read the full release announcement for Thermostat 0.3 here. Enjoy! [Less]

I've added support for generating Windows Runtime assemblies with IKVM.Reflection. This is still experimental because it is mostly based on reverse engineering as there currently is virtually no documentation on this. ... [More] The code for generating a trivial component is available here. It doesn't require .NET 4.5 or any Windows Runtime metadata assemblies. The IKVM.Reflection code is available in cvs. BTW, I did this mostly because I was curious about what's involved. Don't read anything into this wrt IKVM.NET itself. It's unlikely to ever support running in WinRT. [Less]

The Thermostat team (Jon, Omair, Mario and myself) are proud to announce Thermostat 0.3, codenamed ‘Not Yet’ (yeah yeah, I know). (For those who don’t know yet, Thermostat is a next generation and free/open source monitoring and diagnosing tool for ... [More] OpenJDK.) The major new feature is the support for creating and analysing memory by creating a heapdump and browsing a histogram of objects in memory. Additional features include a kill switch, using which you can terminate a running process (for example if it grossly misbehaves), a new Look and Feel (named Dolphin, made to look similar to Gnome 3′s Adwaita theme), new command line commands to support heap analysis, numerous little UI improvements and bugfixes. The below screenshot shows the new heap analysis view. It monitors the heap usage of a selected JVM. When you click the big ‘Heap Dump’ button, a heap dump image is created and saved in the MongoDB, it shows up in the list below (you can take and analyze several heapdumps per VM.. they will be listed with the timestamp of their creation). Clicking on the heap dump in that list brings up a histogram view that lists all allocated objects, the number of their instances and the total size of their allocation. This list can be sorted by clicking on the respective table headers. (We are planning several more heap analysis features like searching specific objects and following their paths to GC roots, showing incoming and outgoing references, etc etc, but those will show up in the next release, in about 4 weeks from now.) This was a fairly important release for us, it was our first milestone release, ready just in time for the Red Hat Summit (Deepak will present Thermostat there). Infact, it is the second milestone, milestone 0 was earlier this year when Jon and Omair showed Thermostat at FOSDEM. We took at lot of care and time to make Thermostat solid and useful, and while it’s not overflowing with features yet, we prepared the ground for a lot of greatness. Eventually, Thermostat will support monitoring remote VMs and whole clusters of VMs, and allow drilling down into problem areas and perform deep and fine grained analysis, utilizing information from the JVM itself as well as from the kernel, the operating system and even from the application server. Please read the release announcement for more details about this new shiny release of Thermostat! [Less]

On October 24 of last year I reported an ASP.NET Medium Trust vulnerability. This eventually resulted in KB 2698981 where Microsoft essentially deprecated ASP.NET Partial Trust. The problem I reported was that it ... [More] is possible to abuse Thread.Abort() to create an inconsistent TypedReference that violates type safety. TypedReference is an interesting type and I've been on the lookout for a way to abuse it for a long time. It's purpose is to allow type safe references to be used in a generic way. To implement this a TypedReference contains both a pointer and a type and all operations it allows make sure that type safety isn't violated. It's a primitive type, so the runtime knows about it and treats it specially. It can be used from partially trusted code and because it can contain a reference to a location on the stack, the runtime enforces that TypedReference values can only be used from a single thread (by disallowing boxing or storing it in arrays or fields). However, by having one thread repeatedly overwriting a TypedReference location on the stack with two different values and a second thread aborting the first thread at the right moment, you can end up with a TypedReference that combines the pointer from one value and the type from another value and thus violating type safety. The source of the PoC is available here. [Less]

DRAFT A while back I did a little blogging on a system called JPRT, the hardware used and a summary on my java.net weblog. This is an update on the JPRT system. JPRT ("JDK Putback Reliablity Testing", but ignore what the letters stand for, I ... [More] change what they mean every day, just to annoy people :\^) is a build and test system for the JDK, or any source base that has been configured for JPRT. As I mentioned in the above blog, JPRT is a major modification to a system called PRT that the HotSpot VM development team has been using for many years, very successfully I might add. Keeping the source base always buildable and reliable is the first step in the 12 steps of dealing with your product quality... or was the 12 steps from Alcoholics Anonymous... oh well, anyway, it's the first of many steps. ;\^) Internally when we make changes to any part of the JDK, there are certain procedures we are required to perform prior to any putback or commit of the changes. The procedures often vary from team to team, depending on many factors, such as whether native code is changed, or if the change could impact other areas of the JDK. But a common requirement is a verification that the source base with the changes (and merged with the very latest source base) will build on many of not all 8 platforms, and a full 'from scratch' build, not an incremental build, which can hide full build problems. The testing needed varies, depending on what has been changed. Anyone that was worked on a project where multiple engineers or groups are submitting changes to a shared source base knows how disruptive a 'bad commit' can be on everyone. How many times have you heard: "So And So made a bunch of changes and now I can't build!". But multiply the number of platforms by 8, and make all the platforms old and antiquated OS versions with bizarre system setup requirements and you have a pretty complicated situation (see http://download.java.net/jdk6/docs/build/README-builds.html). We don't tolerate bad commits, but our enforcement is somewhat lacking, usually it's an 'after the fact' correction. Luckily the Source Code Management system we use (another antique called TeamWare) allows for a tree of repositories and 'bad commits' are usually isolated to a small team. Punishment to date has been pretty drastic, the Queen of Hearts in 'Alice in Wonderland' said 'Off With Their Heads', well trust me, you don't want to be the engineer doing a 'bad commit' to the JDK. With JPRT, hopefully this will become a thing of the past, not that we have had many 'bad commits' to the master source base, in general the teams doing the integrations know how important their jobs are and they rarely make 'bad commits'. So for these JDK integrators, maybe what JPRT does is keep them from chewing their finger nails at night. ;\^) Over the years each of the teams have accumulated sets of machines they use for building, or they use some of the shared machines available to all of us. But the hunt for build machines is just part of the job, or has been. And although the issues with consistency of the build machines hasn't been a horrible problem, often you never know if the Solaris build machine you are using has all the right patches, or if the Linux machine has the right service pack, or if the Windows machine has it's latest updates. Hopefully the JPRT system can solve this problem. When we ship the binary JDK bits, it is SO very important that the build machines are correct, and we know how difficult it is to get them setup. Sure, if you need to debug a JDK problem that only shows up on Windows XP or Solaris 9, you'll still need to hunt down a machine, but not as a regular everyday occurance. I'm a big fan of a regular nightly build and test system, constantly verifying that a source base builds and tests out. There are many examples of automated build/tests, some that trigger on any change to the source base, some that just run every night. Some provide a protection gateway to the 'golden' source base which only gets changes that the nightly process has verified are good. The JPRT (and PRT) system is meant to guard the source base before anything is sent to it, guarding all source bases from the evil developer, well maybe 'evil' isn't the right word, I haven't met many 'evil' developers, more like 'error prone' developers. ;\^) Humm, come to think about it, I may be one from time to time. :\^{ But the point is that by spreading the build up over a set of machines, and getting the turnaround down to under an hour, it becomes realistic to completely build on all platforms and test it, on every putback. We have the technology, we can build and rebuild and rebuild, and it will be better than it was before, ha ha... Anybody remember the Six Million Dollar Man? Man, I gotta get out more often.. Anyway, now the nightly build and test can become a 'fetch the latest JPRT build bits' and start extensive testing (the testing not done by JPRT, or the platforms not tested by JPRT). Is it Open Source? No, not yet. Would you like to be? Let me know. Or is it more important that you have the ability to use such a system for JDK changes? So enough blabbering on about this JPRT system, tell me what you think. And let me know if you want to hear more about it or not. Stay tuned for the next episode, same Bloody Bat time, same Bloody Bat channel. ;\^) -kto [Less]

During the last couple of days, Madeleine and I dedicated for a little adventure, which was to clean up our attic. And what a great journey it’s been. I met old friends that I haven’t seen in ages. I have met dreams that never came true. And things ... [More] that came true, that I would never have dared to dream of. I met some ghosts of the past. I remembered smells and sounds that I thought long forgotten. Lots and lots of memories of nice people that I have met on my way. I have seen love that’s long gone, and love that somehow never happened. And we cleaned up lots of garbage and dirt. Oh boy, loads of garbage and dirt. The above pictures were made in April 1999. A friend of mine made this picture during a short trip to the Baltic Sea. This was just days before my life would change forever. It was a very happy time. A few days later I would meet Madeleine for the first time. Had I known what sort of adventure I was heading into… I would do all of it again She turned my life upside down, a few months later I would move in with her in Freiburg, say goodbye to many of my old friends for the last time (many of them I never met again), and it’s been my best decision ever. [Less]