GNU Classpath

GitHub is now the main repository for JNode sources : https://github.com/jnode . We are now using GitHub’s issue tracker. Bookmark and Share More » Powered by Bookmarkify™

GWorkspace allows for easy mounting and unmounting of volumes (disks, usb sticks, CD-ROMs) like you would do manually on console, without the requirement of daemons or other tools.Here is how.First, be sure your underlying operating system is ... [More] correctly configured to allow you to do that. I'll show as example how I configured my Debian system.Your current user needs to have the permissions to mount the volume(s), this is usually done by being part of the correct group. For Debian we find cdrom and floppy as ready groupscdrom:x:24:multixThe predefined mount-point for the cdrom is /mnt/cdrom, since I usually handle with USB sticks I added a mount point for it:$ ls -l /media/total 8lrwxrwxrwx 1 root root    6 Jan  1  1970 cdrom -> cdrom0drwxr-xr-x 2 root root 4096 Jan  1  1970 cdrom0drwxr-xr-x 2 root root 4096 Nov 27 14:01 usbNow, let's add the correct lines to /etc/fstab for our usb entry. The cdrom entry is usually already configured by Debian./dev/hdc        /media/cdrom0   udf,iso9660 user,noauto     0       0/dev/sdb        /media/usb      auto    defaults,users  0       0I auto shall determine the file system automagically, while users allows for user permissions for the mounted files. You can check if everything is configured fine if you can "mount" from the command line with your current user.Then open SystemPreferences and configure the managed paths as shown here:SystemPreferences - Mount pointsConfigure the mount points for removable media, here I have enabled the cdrom and the usb mount points. The mtab path is currently ignored by GWorkspace, so don't bother and the default value is anyway correct for Linux.Now, in GWorkspace we can select Check for disks under the Tools menu.GWorkspace - check for disksIf everything goes well, voilà, your volume will get mounted. It will appear on the destkop if you have the Desktop enabled and you can show its content. In any case it shall be visible in the File Viewer in its mount place.Usb stick contentsIf all options are set correctly as suggested, the volume is readable, writable as you can check with the Attributes Inspector. Also we can open the .zip file with Zipper easily.Zipper and AttributesTo unmount a volume, just drag its icon to the Recycle Bin. [Less]

New month, new talks. Many new talks, in fact - all of JavaOne 2013 presentations have been published online. In addition, the OTN team has been busy publishing interviews from Devoxx on the Oracle Java YouTube channel. But first, let's start with a ... [More] video from Kaushik Srenevasan from Twitter University on Profiling Java in Production diving into the home grown HotSpot tooling at Twitter using the Linux perf profiler.At Devoxx, Nighthacker Stephen Chin interviewed Brian Goetz and Stuart Marks on Project Lambda. OTN's Tori Wieldt interviewed Brian as well. And if you just can't get enough of watching Brian talk about Lambdas and want to start playing with Lambdas yourself, Stephen, Stuart and Brian will be hosting a NightHacking Worldwide Event on Lambdas on January 16th.Also as Devoxx, Tori interviewed Mark Reinhold on Java SE 8, Jigsaw and a lot more. And if you can't get enough of listening to Mark, his JavaOne 2013 presentations are now online as well:The Modular Java Platform and Project JigsawAsk the JDK ArchitectsOther OpenJDK related talks from JavaOne that are available now are:OpenJFX: State of the UnionJDK 8 Compact Profiles for Embedded and Oracle ADF Mobile on iOS DevicesIt Takes a CommunityWholly Graal: Accelerating GPU Offload for JavaWhere Next with OpenJDK Community Build and Test?There are many more presentations on the JavaOne 2013 sessions website. [Less]

Fixed a nasty bug (I was using the wrong macro) that was causing GWorkspace not to mount removable volumes (like an USB key) on Linux.

Last week brought a first Early Access build of JDK 7u60: Build b01. A list of changes is available in the JDK Bug System. As the focus of the JDK 7u60 release is plain old bug fixes, this first build contains bug fixes across the JDK code base. As ... [More] part of the Early Access build community testing efforts, the Apache Lucene team has given this build a spin already with some encouraging results. If you find issues during your own testing of this build, please report a bug.Moreover, if you are interested in participating in regular community testing of Early Access builds, you can join the quality-discuss mailing list at OpenJDK, and let the community know about your experiences.In addition, a new Early Access build of JDK 8: Build b118 is now available for testing. This build updates HotSpot in JDK 8 to HotSpot 25 build 60 and updates the man pages. An extensive list of changes since the previous build is linked off the download site. For developers making their own OpenJDK builds, and looking to compare their regression test results with others, JDK 8 b118 regression test results have been posted to the quality-discuss mailing list, as usual.The next build, b119, has already been tagged.Happy testing! [Less]

The annotation processing API, both the processor-specific portion of the API in javax.annotation.processing and the language modeling portions in javax.lang.model.*, are being updated to support the new language features in Java SE 8. ... [More] Procedurally, the proposed changes are covered by the second maintenance review of JSR 269: Maintenance Draft Review 2. As summarized on on the maintenance review page, there are three categories of changes from the version of the API shipped with Java SE 7: Cleaning up the existing specification without changing its semantics (adding missing javadoc tags, etc.) API changes to support the language changes being made in Project Lambda /JSR 335. These includes adding javax.lang.model.type.IntersectionType as well as javax.lang.model.element.ExecutableElement.isDefault. API changes to support the language changes being made under JSR 308, Annotations on Java Types. These include javax.lang.model.AnnotatedConstruct and updating javax.annotation.processing.Processor. The small repeating annotations language change, discussed on an OpenJDK alias, is also supported by the proposed changes. A detailed specification difference is available. Please post any comments here or send them to me through email. [Less]

Here we are! After starting a bit more that two years and more than one hundred thousands lines of code after, we finally released Thermostat 1.0, codenamed “The Snowman”. We do always have code names for releases, they are usually based on books ... [More] , either titles or characters or situations, even when they are not directly based on a book we had read, there’s usually something out there that wrote about our release anyway If you’re interested in the Snowman puzzle, I suggest you to read the nice original announcement from Jon, right here. Thermostat has an awesome set of features, and with 1.0 we’re officially freezing (hint hint: “The Snowman”) the public API for plugins. From now on, the 1.0 tree will be dedicated to long term maintenance and stabilisation, and occasionally backporting plugins as appropriate from the main development tree, which is now 1.1.0: Thermostat 1.0 is the result of long hours of work, a great team, great upper management and a amazing Community that pushed and sustained us in the right way. I can tell you, it’s not easy to get something like this and is all too easy to miss important aspects, so I’m very proud we actually released a good 1.0. Of course, there’s always room for improvements, so please, help us making this a better, more stable release, help us improving it! We’re open for suggestions, we want to hear your experience and what you are searching from a monitoring platform. I specifically say monitoring platform because Thermostat is long gone as a “simple” (ehm…) monitoring tool. We decided that it really does make sense to make possible for people to write their tool on top of our code, which is not only a very good way to extend our program in ways we didn’t think of, but it’s also important for our own sanity when we do extend it This is why the plugin API is so important for us. Thermostat itself is all based on plugins, in fact. And I really mean everything, for example the various filters (like living vs non livig vms, or the search fields), or even the side panel with the host accordion, this is all plugins (even if some of them still “internal” for a reason or another). And it looks good too we did lots of fine tuning and improvements in Swing, with customs components. I believe that one of the most exciting part at least for me was to actually force Swing to behave like a modern toolkit, which is an experience I will likely put in a book at some point… It has been a great, fun and challenging journey so far, and I really want to thank everyone who contributed to Thermostat across the years, the Thermostat team as a whole including our Red Hat Brno team, Pavel, Jiri and Jana, the performance team at Red Hat, especially Nathans and Lukas, all the occasional contributors who just stopped by and yelled regarding some bugs, Giovanni, who helped us writing the plugin descriptor infrastructure, which is what really let you write and plug external components into the framework, and everyone else who contributed. A special thanks, though, the most special one, goes to my wife, since she really supported me over those insanely long days! Now, on for a new adventure, there’s still so much work to do, and it’s going to be equally fun, I can assure you! [Less]

I want to show how easy it is to create 3D charts in a Java application, so here I will walk through the steps to create the following chart in a small Java Swing application: The chart shows the number of survivors and non-survivors from the ... [More] sinking of the Titanic, split between men vs women/children, and broken down by passenger class (1st, 2nd, 3rd and crew). The source of the data is this paper (PDF). The background image is from iStockPhoto.com. The chart library I'm using is Orson Charts, which comes in a single jar file (248kB) and uses its own built-in 3D rendering (so there is no dependency on JOGL, Java3D etc). It's made to be simple. It's not free. The first step in creating this chart is to get the data in a form that can be used to create a bar chart (in fact, a stacked bar chart in this case). In Orson Charts, we've defined the CategoryDataset3D interface as the source for data, and provide an easy-to-use implementation StandardCategoryDataset3D (people that have used JFreeChart, another chart library I developed, will find this approach very familiar). Here's the code to create the dataset---for each value we are specifying the series key (one series for survivors, another series for victims), a row key (men vs women/children) and a column key (passenger class): private static CategoryDataset3D createDataset() { StandardCategoryDataset3D dataset = new StandardCategoryDataset3D(); dataset.addValue(146, "Survivors", "Women/Children", "1st"); dataset.addValue(104, "Survivors", "Women/Children", "2nd"); dataset.addValue(103, "Survivors", "Women/Children", "3rd"); dataset.addValue(20, "Survivors", "Women/Children", "Crew"); dataset.addValue(57, "Survivors", "Men", "1st"); dataset.addValue(14, "Survivors", "Men", "2nd"); dataset.addValue(75, "Survivors", "Men", "3rd"); dataset.addValue(192, "Survivors", "Men", "Crew"); dataset.addValue(4, "Victims", "Women/Children", "1st"); dataset.addValue(13, "Victims", "Women/Children", "2nd"); dataset.addValue(141, "Victims", "Women/Children", "3rd"); dataset.addValue(3, "Victims", "Women/Children", "Crew"); dataset.addValue(118, "Victims", "Men", "1st"); dataset.addValue(154, "Victims", "Men", "2nd"); dataset.addValue(387, "Victims", "Men", "3rd"); dataset.addValue(670, "Victims", "Men", "Crew"); return dataset; } Take a look again at the screenshot to see how these data items correspond to the items in the chart (the series keys are shown in the legend, the row keys on the z-axis, the column keys on the x-axis, and the values are plotted against the y-axis). Next, we will create a Chart3D object configured with the required plot and renderer to create a stacked bar chart from this data. Here the Chart3DFactory class does all the work for us (we just specify the chart title, subtitle, dataset, and axis labels---we pass null for the row axis because it doesn't need a label): CategoryDataset3D dataset = createDataset(); Chart3D chart = Chart3DFactory.createStackedBarChart( "The Sinking of the Titanic", "Survival data for 2,201 passengers", dataset, null, "Class", "Passengers"); At this point, the chart is ready to use. We're going to display this one in a Swing UI using the ChartPanel3D class...but first we will make a few customisations of the default settings (add a background image, make the chart walls transparent, and change the bar colors). The background image is added with the following code, which specifies the image and how it should be resized to fit the background (obviously the image is coming from a file on my desktop, so you should not use this code without modifying the image source): ImageIcon icon = new ImageIcon("/Users/dgilbert/Desktop/iStock_000003105870Small.jpg"); RectanglePainter background = new StandardRectanglePainter(Color.WHITE, icon.getImage(), new Fit2D(TitleAnchor.CENTER, Scale2D.SCALE_BOTH)); chart.setBackground(background); The Fit2D class allows control over the positioning and scaling of the image. The code here centers the image and scales it to fit the background rectangle (as I write this, I realise I can simplify the API here...that will get done in the next release). Next, I make the chart-box (the walls of the 3D plot) transparent so that the background image is not completely obscured by the chart---to do this, just specify a color with an alpha-value of less than 255: chart.setChartBoxColor(new Color(255, 255, 255, 155)); Finally, I change the default bar colors by customising the renderer. This will need a little bit of explaining: CategoryPlot3D plot = (CategoryPlot3D) chart.getPlot(); StackedBarRenderer3D renderer = (StackedBarRenderer3D) plot.getRenderer(); renderer.setColorSource(new StandardCategoryColorSource( new Color[] { new Color(50, 200, 50), new Color(200, 50, 50) })); In Orson Charts, the Chart3D class is the top-level "umbrella" object and it keeps a reference to a Plot3D instance which in turn manages the dataset and renderer. There are different types of plots (PiePlot3D, CategoryPlot3D and XYZPlot)...our stacked bar chart uses the CategoryPlot3D class so we first get a reference to the plot (applying the necessary cast---you can check the Chart3DFactory documentation to know what sort of plot your chart is using). The plot has a renderer---the type of renderer controls how the data is represented (bars, lines, areas etc). In our case the renderer is a StackedBarRenderer3D, so we get a reference to this and again apply the necessary cast. Now we can apply whatever customisations we want to the renderer. In fact, here we just set the color source to use two custom shades of red and green for the series colors (once again, as I write this I can see the need to simplify the API here for the easy cases...look for that in the next release also). Now we add the chart to our Swing UI using the ChartPanel3D class (and, in fact, we wrap that inside a DisplayPanel3D to get the toolbar that you see in the screenshot). The call to zoomToFit() just ensures that the chart is sized to fit the available space in the panel: ChartPanel3D chartPanel = new ChartPanel3D(chart); chartPanel.zoomToFit(OrsonChartsDemo.DEFAULT_CONTENT_SIZE); content.add(new DisplayPanel3D(chartPanel)); And that's it. The complete source for the demo is here (there's very little code in addition to what I've already shown you). I encourage you to download the free evaluation for Orson Charts, run the demos, and see for yourself how easy it is to create great looking 3D charts in Java. [Less]

Late last night, fuelled by energy drinks for the first time since university, after a frantic hacking session to put out some fires discovered at the last minute, I prepared my first ever 1.0.0 release.  I wanted to share some retrospective thoughts ... [More] about this.It's worth mentioning that the project uses a slightly modified implementation of Semantic Versioning.  So 1.0.0 is a significant release: it indicates that the project is no longer in a beta status, rather it's considered stable, mature even.  Any public API the project provides is considered frozen for the duration of 1.X.X release train.  Any mistakes we have made (and I fully expect we'll discover plenty of them) in terms of interface design, we are stuck with for a while.  This part is a little bit frightening.Oh, I should specify that the project is Thermostat, an open source Java monitoring tool.  Here's the release announcement from our announcement list archives.  My last post (woah, have I not posted anything since February?  Bad code monkey!!) also mentioned it.Thermostat consists of a core platform including a plugin API, and ships with several useful plugins.  Leading up to this release, our focus has been primarily on the core platform and API.  Releasing 1.0.0 is somewhat exciting for us as we can move into primarily maintenance mode on the core, while building out new features as plugins.  Writing brand new code instead of lots of tweaking and refactoring of existing code?  Yes, please!But what I really want to write about isn't the project itself, but the process and the things I learned along the way.  So, in no particular order:Estimation is hardThis project was started by two engineers about two and a half years ago.  There was an early throwaway prototype, then a new prototype, which eventually became today's code base but looks nothing like it.  Over time things started to look more and more reasonable, and we started thinking about when we'd be releasing a 1.0 version.  I want to say that probably for more than a year, we've been saying "1.0 is around the corner".  And each time we said it, we believed it.  But we were, until recently, obviously wrong.  Now there are various reasons for this, some better than others.  In that time, there were new requirements identified that we decided we couldn't release 1.0 without implementing.  Naturally, estimates must be revised when new information appears.  But a lot of it is simply believing that some things would take significantly shorter than it actually did.  I want to think that this is something that improves with experience, and will be mindful of this as we move into building out new features and/or when I'm one day working on a new project.Early code and ideas will changeWhen I think back to the early days of this project, before it even had a name, it's hard to imagine.  This is because it is so incredibly different from where we ended up.  Some parts of our design were pretty much turned inside out and backwards.  Entire subsystems have been rewritten multiple times.  We've used and abandoned multiple build systems.  And this trend doesn't seem to be slowing down; we've had ideas brewing for months about changes targeting the 2.X release train that will change the picture of Thermostat in significant ways again.  One really awesome result of this is that nobody working on the project can afford to indulge their ego; any code is a rewrite candidate if there is a good reason for it, no matter who wrote it originally or how elegantly.  And everyone understands this.  Nobody gets attached to one implementation, one design.  It's nice to be working in a meritocratic environment.  It's a sort of freedom: freedom from attachments, and freedom to innovate.Good test coverage helps make changes safeSo this one is something that's probably been noted by a lot of developers.  I know I've been taught this in school, read it in various places, and so forth.  But it is working on Thermostat that has really driven it home for me.  In the early days, we didn't really have any tests.  It made sense at the time; we didn't really know where we were going, the code base was small and undergoing radical changes very regularly.  But time went on, and it became clear that this project was going to be around for a while, and both the code base and the group of contributors were growing.  So, we started adding tests.  Lots and lots of tests.  No new code was accepted without tests, and over time we filled in gaps in coverage for pre-existing code.  The happy result has been an ability to make very invasive changes with the confidence that side effects will be minimal, and likely detected at test time.  I cannot exaggerate the number of times I've been thankful we put in the effort to get our unit and integration tests to this level.Automation is kingHave a repetitive, error-prone task?  Script that.  Over time Thermostat has grown a collection of useful little helper scripts that save contributors time and effort, over and over again.  From firing up typical debug deployments, to release management tasks, to finding source files with missing license headers; we write this stuff once and use it forever.  These type of things go into version control of course, so that all developers can benefit from them.  Also, testing automation.  The common term used is of course Continuous Integration Testing, and for ages we've been using a Jenkins instance to run tests in sort of a clean room environment, catching problems that may have been hidden by something in a developer's environment.  This has saved us a lot of pain, letting us know about issues within hours of a commit, rather than discovering them by accident days, weeks, or months later and having to wonder what caused the regression.  I'll have to insist on a similar set up for any non-trivial project I work on.That's all I have to say.  Hopefully it won't be so long before my next post.  I've actually been meaning to make a "battle station" write-up; I'm a remote employee, and invested time and money in a convertible standing desk setup and some clever mounting techniques to keep my workspace neat despite the number of devices involved.  Until then, Adieu! [Less]

After reaching 8000 @OpenJDK followers back in June, it's time for another update: 9000! Since it has historically taken a couple of months to for another thousand followers to appear, the number of followers may cross the 10k mark around FOSDEM. ... [More] Which reminds me - the Call for Participation for the Free Java devroom at FOSDEM closes in a few days, so I really need to get my abstract submitted. [Less]