GNU Classpath

Just a couple of days ago I found out that some of my favourite musicians decided to join together to release an album, and allowed to preorder it on a crowdfunding website, Music Raiser. The name of the band is “O.R.k.” and the founders are none but ... [More] Lef, Colin Edwin, Pat Mastelotto and Carmelo Pipitone. You probably have heard their names, if not, Colin Edwin is the bassist from Porcupine Tree while Carmelo Pipitone is the gifted guitarist from Marta Sui Tubi, an extremely original Italian band, they probably did the most interesting things in Italian music in the last 15 years or so; Lef, aka Lorenzo Esposito Fornasari, has done so many things that is quite hard to pick just one, but in Metal community he is probably best know for Obake. Finally, Pat Mastelotto is the drummer of King Crimson, and this alone made me jump on my seat! One of the pre-order bonus was the ability to participate to a Remix Contest, and although I only got the stems yesterday in the late morning I could not resist to at least give it a try, and it’s a great honour for me that they have put my attempt on their Youtube channel: It’s a weird feeling editing this music, after all, who am I to cut and remix and change the drum part (King Crimson, please forgive me!), how I ever dare to touch the guitars and voice, or rearrange the bass!? But indeed it was a really fun experience, and I hope to be able do this again in the future. And who knows, maybe they even like how I messed up their art and they decide to put me on their album! Nevertheless, it has been already a great honour for me to be able to see this material in semi-raw form (and a very interesting one!), so this has been already my first prize. I’m looking forward now to listen the rest of the album! [Less]

I'm happy to announce that JFreeSVG version 3.0 has been uploaded to SourceForge. JFreeSVG is a fast and lightweight API for creating SVG content in Java. This release features: new handling for BasicStroke cap, join and ... [More] miterlimit; a new ZIP option when writing SVG to files; a demo for exporting Swing UIs to SVG; removal of the CanvasGraphics2D implementation (to focus on SVG only); a fix for handling of PathIterator.SEG_CLOSE; a fix for y-coordinate bug in drawImage(); a workaround for ClassCastException when exporting Swing UIs on MacOSX with Nimbus L&F. To ensure that JFreeSVG provides a fully functional Graphics2D implementation, I tested it using the Swingset3 demo with modifications to redirect the screen output directly to JFreeSVG to produce SVG output. I've always liked the way that Swing uses the Java2D API to cleanly separate its rendering from having any direct knowledge of the actual output target. Here is an example: SVG not supported in your browser! This turned out to be an effective test, because it uncovered a bug in one of the drawImage() methods that has remained undetected in all previous JFreeSVG releases. One last thing...the JFreeSVG repo at GitHub is now public, which will make it easier for other developers to tweak the code for experimentation or bug fixes (if you spot a bug though, please report it to me). If you'd like to give feedback on this post, please comment via the JFreeSVG forum. [Less]

In firefox development, it’s normal to do most development tasks via the mach command. Build? Use mach. Update UUIDs? Use mach. Run tests? Use mach. Debug tests? Yes, mach mochitest --debugger gdb. Now, normally I run gdb inside emacs, of course. But ... [More] this is hard to do when I’m also using mach to set up the environment and invoke gdb. This is really an Emacs bug. GUD, the Emacs interface to all kinds of debuggers, is written as its own mode, but there’s no really great reason for this. It would be way cooler to have an adaptive shell mode, where running the debugger in the shell would magically change the shell-ish buffer into a gud-ish buffer. And somebody — probably you! — should work on this. But anyway this is hard and I am lazy. Well, sort of lazy and when I’m not lazy, also unfocused, since I came up with three other approaches to the basic problem. Trying stuff out and all. And these are even the principled ways, not crazy stuff like screenify. Oh right, the basic problem.  The basic problem with running gdb from mach is that then you’re just stuck in the terminal. And unless you dig the TUI, which I don’t, terminal gdb is not that great to use. One of the ideas, in fact the one this post is about, since this post isn’t about the one that I couldn’t get to work, or the one that is also pretty cool but that I’m not ready to talk about, was: hey, can’t I just attach gdb to the test firefox? Well, no, of course not, the test program runs too fast (sometimes) and racing to attach is no fun. What would be great is to be able to pre-attach — tell gdb to attach to the next instance of a given program. This requires kernel support. Once upon a time there were some gdb and kernel patches (search for “global breakpoints”) to do this, but they were never merged. Though hmm! I can do some fun kernel stuff with SystemTap… Specifically what I did was write a small SystemTap script to look for a specific exec, then deliver a SIGSTOP to the process. Then the script prints the PID of the process. On the gdb side, there’s a new command written in Python that invokes the SystemTap script, reads the PID, and invokes attach. It’s a bit hacky and a bit weird to use (the SIGSTOP appears in gdb to have been delivered multiple times or something like that). But it works! It would be better to have this functionality directly in the kernel. Somebody — probably you! — should write this. But meanwhile my hack is available, along with a few other gdb scxripts, in my gdb helpers github repository. [Less]

Over the last twelve months or so, one of my projects has been fixing and reviewing fixes of javac lint warnings in the JDK 9 code base (varargs, fallthrough, serial, finally, overrides, deprecation, raw and unchecked) and once a warning ... [More] category is cleared, making new instances of that category a fatal build error. Ultimately, all the warnings in the jdk repository were resolved and -Xlint:all -Werror is now used in the build. Being involved in fixing several thousand warnings, I'd like to share some tips for developers who want to undertake an analogous task of cleaning up the technical debt of javac lint warnings in their own code base. First, I recommend tackling the warnings in a way that aligns well with the build system of the project, with a consideration of getting some code protected by the compiler from some warning categories as soon as possible. While the build of the JDK has been re-engineered over the course of the warnings cleanup, to a first approximation the build has been organized around Hg repositories. (At present, in JDK 9 the build is actually arranged around modules. A few years ago, the build was organized around Java packages rather than repositories.) A warnings cleanup isn't really done until introducing new instances of the warning cause a build failure; new warnings are too easy to ignore otherwise. Therefore, for JDK 9, the effort was organized around clearing the whole jdk repository of a warning category and then enabling that warning category in the build as opposed to, say, completely clearing a particular package of all warnings and then moving to the next package. There are two basic approaches to resolving a warning: suppressing it using the @SuppressWarnings mechanism or actually fixing the code triggering the warning. The first approach is certainly more expedient. While it doesn't directly improve the code base, it can offer an indirect benefit of creating a situation where new warnings can be kept out of the code base by allowing a warning to be turned on in the build sooner. The different warning categories span a range of severity levels and while some warnings are fairly innocuous, others are suspicious enough that I'd recommend always fixing them if a fix is feasible. When resolving warnings in the JDK, generally the non-deprecation warnings categories were fixed while the deprecation warnings were suppressed with a follow-up bug filed. The non-deprecation warnings mostly require Java language expertise to resolve and little area expertise; deprecation warnings are the reverse, often quite deep area expertise is needed to develop and evaluate a true fix. Tips on addressing specific categories of lint warnings: [cast]: Warn about use of unnecessary casts. Since these warnings are generated entirely from the the contents of method bodies, there is no impact to potential callers of the code. Also, the casts analyzed as redundant by javac are easy and safe to remove; fixing cast warnings is essentially a zero-risk change. [fallthrough]: Warn about falling through from one case of a switch statement to the next. When such a falling through is not intentional, it can be a very serious bug. All fallthrough switch cases should be examined for correctness. An idiomatic and intentional fallthrough should have two parts: first, the cases in question should be documented in comments explaining that the fallthrough is expected and second, an @SuppressWarnings({"fallthrough"}) annotation should be added to the method containing the switch statement. See also the discussion of switch statements in Java Puzzlers, Puzzler 23: No Pain, No Gain. [static]: Warn about accessing a static member using an instance. This is an unnecessary and misleading coding idiom that should be unconditionally removed. The fix is to simply refer to the static member using the name of the type rather than an instance of the type. This coding anti-pattern is discussed in Java Puzzlers, Puzzle 48: All I Get Is Static. [dep-ann]: Warn about items marked as deprecated in JavaDoc but not using the @Deprecated annotation Since Java SE 5.0, the way to mark an element as deprecated is to modify it with a @Deprecated annotation. While a @deprecated javadoc tag should be used to describe all @Deprecated elements, the javadoc tag is informative only and does not mean the element is treated as deprecated by the compiler. A element should have an @deprecated javadoc tag in its javadoc if and only if the element is @Deprecated. Therefore, the fix should be to either remove the @deprecated javadoc tag if the element should not be deprecated or add the @Deprecated annotation if it should be deprecated. [serial]: Warn about Serializable classes that do not provide a serialVersionUID. Serialization is a subtle and complex protocol whose compatibility impact on evolving a type should not be underestimated. To check for compatibility between the reader of serial stream data and the writer of the data, besides matching the names of the reader and writer, identification codes of the reader and the writer are also compared and the serial operation fails if the codes don't match. When present, a serialVersionUID field of a class stores the identification code, called a Stream Unique Identifier (SUID) in serialization parlance. When a serialVersionUID field is not present, a particular hashing algorithm is used to compute the SUID instead. The hash algorithm is perturbed by many innocuous changes to a class and can therefore improperly indicate a serial incompatibility when no such incompatibility really exists. To avoid this hazard, a serialVersionUID field should be present on all Serializable classes following the usual cross-version serialization contracts, including Serializable abstract superclasses. If a Serializable class without a serialVersionUID has already been shipped in a release, running the serialver tool on the type in the shipped release will return the serialVersionUID declaration needed to maintain serial compatibility. For further discussion, see Effective Java, 2nd Edition, Item 74: Implement Serializable judiciously. [overrides]: Warn about issues regarding method overrides. As explained in Effective Java, 2nd Edition, Item 9: Always Override hashCode when you override equals, for objects to behave properly when used in collections, they must have correct equals and hashCode implementations. The invariant checked by javac is more nuanced than the one discussed in Effective Java; javac checks that if a class overrides equals, hashCode has been overriden somewhere in the superclass class chain of the class. It is common for a set of related classes to be able to share a hashCode implementation, say a function of a private field in the root superclass in a set of related types. However, each class will still need to have its own equals method for the usual instanceof check on the argument to equals. [deprecation]: Warn about use of deprecated items. Well documented @Deprecated elements suggest a non-deprecated replacement. When using a replacement is not feasible, or no such replacement exists, @SuppressWarnings("deprecation") can be used to acknowledge the situation and remove the warning. A small language change made in JDK 9 makes suppressing deprecation warnings tractable. [rawtypes]: Warn about use of raw types. [unchecked]: Warn about unchecked operations. Both rawtypes and unchecked warnings are linked to the same underlying cause: incomplete generification of APIs and their implementations. Generics shipped in 2004 as part of Java SE 5.0; Java code written and used today should be generics aware! Being generics-aware has two parts, using generics properly in the signature / declaration of a method, constructor, or class and using generics properly in method and constructor bodies. Many uses of generics are straightforward; if you have a list that only contains strings, it should probably be declared as a List. However, some uses of generics can be subtle and are out of scope for this blog entry. However, extensive guides are available with detailed advice. IDEs also provide refactorings for generics; check their documentation for details. I hope these tips help you make your own Java project warnings-free. [Less]

I recently had occasion to scan some papers using a sheet-fed Ricoh printer/scanner/fax/copier. It seems to think that about 6 MB is as big of an email attachment as it can send so it splits up the PDFs into base64-encoded attachments. If you find ... [More] yourself in a similar situation: save the raw base64 text (if you’re using GMail, “show original” is your friend) and trim the extraneous text. concatenate the multiple pieces together: cat part1 part2 > all.base64. decode the whole thing: cat all.base64 | base64 -d > myscan.pdf. [Less]

As part of milling Project Coin in JDK 9, the try-with-resources statement has been improved. If you already have a resource as a final or effectively final variable, you can use that variable in the try-with-resources statement without declaring a ... [More] new variable in the try-with-resources statement. For example, given resource declarations like // A final resource final Resource resource1 = new Resource("resource1"); // An effectively final resource Resource resource2 = new Resource("resource2"); the old way to write the code to manager these resources would be something like: // Original try-with-resources statement from JDK 7 or 8 try (Resource r1 = resource1; Resource r2 = resource2) { // Use of resource1 and resource 2 through r1 and r2. } while the new way can be just // New and improved try-with-resources statement in JDK 9 try (resource1; resource2) { // Use of resource1 and resource 2. } An initial pass has been made over the java.base module in JDK 9 to update the JDK libraries to use this new language feature. You can try out these changes in your own code using a JDK 9 snapshot build. Enjoy! [Less]

As part of milling Project Coin in JDK 9, the try-with-resources statement has been improved. If you already have a resource as a final or effectively final variable, you can use that variable in the try-with-resources statement without declaring a ... [More] new variable in the try-with-resources statement. For example, given resource declarations like // A final resource final Resource resource1 = new Resource("resource1"); // An effectively final resource Resource resource2 = new Resource("resource2"); the old way to write the code to manager these resources would be something like: // Original try-with-resources statement from JDK 7 or 8 try (Resource r1 = resource1; Resource r2 = resource2) { // Use of resource1 and resource 2 through r1 and r2. } while the new way can be just // New and improved try-with-resources statement in JDK 9 try (resource1; resource2) { // Use of resource1 and resource 2. } An initial pass has been made over the java.base module in JDK 9 to update the JDK libraries to use this new language feature. You can try out these changes in your own code using a JDK 9 snapshot build. Enjoy! [Less]

I just committed  ACPI support on OpenBSD for GAP's Battery Monitor.Check it out and enjoy GNUstep on your laptops.

The second release candidate is available. It can be downloaded here or from NuGet. What's New (relative to rc 0): Fixed build error when using Java 8u25 or newer. Bug fix. Unsafe.compareAndSwapObject should ... [More] resolve field before passing it to MakeTypedReference. Implemented OperatingSystemMXBean.getFreePhysicalMemorySize and OperatingSystemMXBean.getTotalPhysicalMemorySize. Binaries available here: ikvmbin-8.0.5449.1.zip Sources: ikvmsrc-8.0.5449.1.zip, openjdk-8-b132-stripped.zip [Less]

DataBasin 0.8 is out!After several months of development and testing, many news:DataBasin is now divided in its DataBasinKit framework which is LGPL'd and the application itself(CSV writing) Support of empty fields in empty semi-joined objects ... [More] through query parsing(CSV writing) Support for writing fields in exact order as in user query, trough query parsingSelect Identify supports LIMITCustomizable CSV file quoting and separatorSupport for COUNT and aggregate queriesObject Inspector supports selection of values in cellsThe most important news is the DataBasinKit separation.The most important feature instead is DataBasin ability to parse the SOQL query and thus rearrange the output fields in CSV files not as Salesforce returns them but as the user requested them. The same feature allows related objects (. notation) to be null and retain the correct columns in the CSV file. [Less]