GNU Classpath

The second release candidate is available. Unlike the previous rc, this one is buildable on Linux again (tested with Mono 2.10.5). It also fixes a regression in final field handling. Changes (relative to rc 0): ... [More] Updated version to 7.1.4532.1 Fixed Linux build issue due to assembly.class filename case error in tools.rsp Updated copyright years in LICENSE Merged in OpenJDK 7u4 changes in THIRD_PARTY_README. Bug fix. AssemblyClassLoader.InternalsVisibleToImpl() would crash with NRE if it got called on a single assembly class loader, because it should call GetLoader(Assembly) to get the AssemblyLoader instead of GetLoaderForExportedAssembly(). Bug fix. When resolving properties corresponding to fields with type 2 access stubs, unloadable types with the same name should compare as equal. Bug fix. When a final field is wrapped in a property, any assemblies that are concurrently compiled with the declaring assembly will access the backing field directly and hence the declaring assembly will need an InternalsVisibleToAttribute to allow them access. This fix makes sure that this attribute is applied when the field is accessed from another (concurrently compiled) assembly. IKVM.Reflection: Added workaround for Mono 2.10 bug in AssemblyName (public key token for ECMA public key is not created correctly). IKVM.Reflection: Added workaround for Mono to StrongNameKeyPair. IKVM.Reflection: Disallow key container constructor of StrongNameKeyPair when running on Mono on Windows. IKVM.Reflection: Bug fix. Type.GetInterfaces() should work for unbaked types. When the final release is done, it will include the full release notes. Binaries available here: ikvmbin-7.1.4532.1.zip Sources: ikvmsrc-7.1.4532.1.zip, openjdk-7u4-stripped.zip [Less]

The IcedTea project provides a harness to build the source code from OpenJDK6 using Free Software build tools, along with additional features such as a PulseAudio sound driver and support for alternative virtual machines. A new set of security ... [More] releases is now available: IcedTea6 1.10.8 IcedTea6 1.11.3 All updates contain the following security fixes: S7079902, CVE-2012-1711: Refine CORBA data models S7110720: Issue with vm config file loadingIssue with vm config file loading S7143606, CVE-2012-1717: File.createTempFile should be improved for temporary files created by the platform. S7143614, CVE-2012-1716: SynthLookAndFeel stability improvement S7143617, CVE-2012-1713: Improve fontmanager layout lookup operations S7143851, CVE-2012-1719: Improve IIOP stub and tie generation in RMIC S7143872, CVE-2012-1718: Improve certificate extension processing S7145239: Finetune package definition restriction S7152811, CVE-2012-1723: Issues in client compiler S7157609, CVE-2012-1724: Issues with loop S7160677: missing else in fix for 7152811 S7160757, CVE-2012-1725: Problem with hotspot/runtime_classfile Full details of each release can be found below. What’s New? New in release 1.10.8 (2012-06-12): Security fixes S7079902, CVE-2012-1711: Refine CORBA data models S7110720: Issue with vm config file loadingIssue with vm config file loading S7143606, CVE-2012-1717: File.createTempFile should be improved for temporary files created by the platform. S7143614, CVE-2012-1716: SynthLookAndFeel stability improvement S7143617, CVE-2012-1713: Improve fontmanager layout lookup operations S7143851, CVE-2012-1719: Improve IIOP stub and tie generation in RMIC S7143872, CVE-2012-1718: Improve certificate extension processing S7145239: Finetune package definition restriction S7152811, CVE-2012-1723: Issues in client compiler S7157609, CVE-2012-1724: Issues with loop S7160677: missing else in fix for 7152811 S7160757, CVE-2012-1725: Problem with hotspot/runtime_classfile Bug fixes PR1018: JVM fails due to SEGV during rendering some Unicode characters (part of 6886358) New in release 1.11.3 (2012-06-12): Security fixes S7079902, CVE-2012-1711: Refine CORBA data models S7110720: Issue with vm config file loadingIssue with vm config file loading S7143606, CVE-2012-1717: File.createTempFile should be improved for temporary files created by the platform. S7143614, CVE-2012-1716: SynthLookAndFeel stability improvement S7143617, CVE-2012-1713: Improve fontmanager layout lookup operations S7143851, CVE-2012-1719: Improve IIOP stub and tie generation in RMIC S7143872, CVE-2012-1718: Improve certificate extension processing S7145239: Finetune package definition restriction S7152811, CVE-2012-1723: Issues in client compiler S7157609, CVE-2012-1724: Issues with loop S7160677: missing else in fix for 7152811 S7160757, CVE-2012-1725: Problem with hotspot/runtime_classfile Bug fixes PR1018: JVM fails due to SEGV during rendering some Unicode characters (part of 6886358) The tarballs can be downloaded from: http://icedtea.classpath.org/download/source/icedtea6-1.10.8.tar.gz (sig) http://icedtea.classpath.org/download/source/icedtea6-1.11.3.tar.gz (sig) SHA256 checksums: 7723882c52d21f859c67f64d84764d5e6c69ac79245ecc0579ccac29e086000a icedtea6-1.10.8.tar.gz 7d91c407b9795bd6f6255bcf0fb808416b36418c57f601dc47cfabff83194cf4 icedtea6-1.11.3.tar.gz Each tarball is accompanied by a digital signature (link above). This is produced using my public key. See details below. PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 The following people helped with these releases: Andrew Dinn (checking of S7160757) Andrew Haley (checking of S7110720, S7152811 & S7143606) Andrew John Hughes (checking of S7143872, reproducer testing & release management) Omair Majid (checking of S7079902, S7143851 & S7143606) Pavel Tisnovsky (PR1018, checking of S7143617 & S7157609) Jon VanAlten (checking of S7145239) Jiri Vanek (checking ofS7143606) We would also like to thank the bug reporters and testers! To get started: $ tar xzf icedtea6-<ver>.tar.gz $ cd icedtea6-<ver> Full build requirements and instructions are in INSTALL: $ ./configure [--enable-zero --enable-pulse-java --enable-systemtap ...] $ make Happy Hacking! [Less]

Once upon a time there was a nice feature, when Gnome was a decent and sane environment, and you wanted to post your patches to mailing list using evolution (p.s. that work for all kind of documents made of more than one file): Opening a file with ... [More] the file dialog and attaching it to the mail (this is the part that still works today... until they will decided nobody really needs email attachments!).Most of the time, you would find yourself into the situation that you want to propose more patches, which you had previously saved in the same location as the first one.That was easy indeed, because the software, being developed by sane and smart people, remembered the last place where you opened a file and promptly proposed that very same place as your new starting point! It seems, though, that one of the last sane features that survived under Gnome 3 is finally gone! Now, anytime you try to attach a document, Evolution forces you to find it again, defaulting to the user home directory, requiring that you remembed the position, and follow all the path to the file again, without any other reason than the obvious one that Gnome 3 and Evolution developers don't apparently use patch reviews at all... [as well as obviously not using their own software].No fear for the braves, though, at least the files are still preserved where you put them. Randomly moving their location is scheduled only for the next release. [Less]

Among insects, monarch butterflies and dragonflies have the longest migrations; migrating JDK bugs involves a long journey as well! As previously announced by Mark back in March, we've been working according to a revised plan to transition the JDK ... [More] bug management from Sun's legacy system to initially an Oracle-internal JIRA instance which is afterward made visible and usable externally. I've been busily working on this project for the last few months and the team has made good progress on many aspects of the effort: JDK bugs will be imported into JIRA regardless of age; bugs will also be imported regardless of state, including closed bugs. Consequently, the JDK bug project will start pre-populated with over 100,000 existing bugs, some dating all the way back to 1994. This will allow a continuity of information and allow new issues to be linked to old ones. Using a custom import process, the Sun bug numbers will be preserved in JIRA. For example, the Sun bug with bug number 4040458 will become "JDK-4040458" in JIRA. In JIRA the project name, "JDK" in our case, is part of the bug's identifier. Bugs created after the JIRA migration will be numbered starting at 8000000; bugs imported from the legacy system have numbers ranging between 1000000 and 79999999. We're working with the bugs.sun.com team to try to maintain continuity of the ability to both read JDK bug information as well as to file new incidents. At least for now, the overall architecture of bugs.sun.com will be the same as it is today: it will be a gateway bridging to an Oracle-internal system, but the internal system will change to JIRA from the legacy database. Generally we are aiming to preserve the visibility of bugs currently viewable on bugs.sun.com; however, bugs in areas not related to the JDK will not be visible after the transition to JIRA. New incoming incidents will be sent to a separate JIRA project for initial triage before possibly being moved into the JDK project. JDK bug management leans heavily on being able to track the state of bugs in multiple releases, especially to coordinate delivering synchronized security releases (known as CPUs, critital patch updates, in Oracle parlance). For a security release, it is common for half a dozen or more release trains to be affected (for example, JDK 5, JDK 6 update, OpenJDK 6, JDK 7 update, JDK 8, virtual releases for HotSpot express, etc.). We've determined we need to track at least the tuple of (release, responsible engineer/assignee for the release, status in the release) for the release trains a fix is going into. To do this in JIRA, we are creating a separate port/backport issue type along with a custom link type to allow the multiple release information to be easily grouped and presented together. The Sun legacy system had a three-level classification scheme, product, category, and subcategory. Out of the box, JIRA only has a one-level classification, component. We've implemented a custom second-level classification, subcomponent. As part of the bug migration we've taken the opportunity to think about how bugs should be grouped under a two-level system and we'll the new system will be simpler and more regular. The main top-level components of the JDK product will include: core-libs client-libs deploy install security-libs other-libs tools hotspot For the libs areas, the primary name of the subcomportment will be the package of the API in question. In the core-libs component, there will be subcomponents like: java.lang java.lang.class_loading java.math java.util java.util:i18n In the tools component, subcomponents will primarily correspond to command names in $JDK/bin like, jar, javac, and javap. The first several bulk imports of the JDK bugs into JIRA have gone well and we're continuing to refine the import to have greater fidelity to the current data, including by reconstructing information not brought over in a structured fashion during the previous large JDK bug system migration back in 2004. We don't currently have a firm timeline of when the new system will be usable externally, but as it becomes available, I'll share further information in follow-up blog posts. [Less]

I'm pleased to announce that GWorkspace 0.9.1 is out.Some release highlights: Enhancements / new features New Modern vs Classic style which control:classic vs. alpha-blended selectiontransparent dock vs classic dock stylenew "scale" attribute for ... [More] the desktop, for uniform scalingBrowser icons (Eric W.) Fixes & MaintenancePDF Content Inspector fixed and updatedNSUInteger updates for new APIscrash fix on exit when Grayscale background images were selectedupdates for integer positions and resolutions to avoid blurring of elementsNSDragOperation updatesThis release is highly recommended when compiling and running GWorkspace against the current GNUstep core release. [Less]

I have been, and still am, quite a fan of Gnome. I followed the development of Gnome3 and was relatively pleased when it came out, despite all the bashing. I even find some workflows sorely lacking when switching to other desktops, which is a good ... [More] sign (for Gnome). It has its rough edges of course, and I hoped they would be ironed out, but I get to think that this might never happen, because some of the things seem to be intentional. Let me list a few of the things that I am most concerned about: - The timezone-aware clock. I loved this thingy in Gnome2, I would add any location I want, and the clock would show me the time in those places in the popup view. Since I am working with heavily distributed team, this is an extremely useful feature. The clock in Gnome3 instead is very basic. I have seen a discussion somewhere to re-introduce the timezone aware clock back into Gnome3, but apparently it never happened. And extensions.gnome.org doesn’t have anything like that either. - The hopping notification icons. Unless you are very good with the mouse, it becomes a little bit of a chase to click one of those notification icons in the lower right corner. Why the hell do the need to show a name in the taskbar, and move around while you hover over them??? This is so usability-backwards! Moving things are always a bit of a double edged sword in any GUI. Yes, movements *can* be a very useful visual cue to something happening, but needs to be implemented with great care to not end up being totally confusing. In this particular case I simply don’t get it: why not simply show the icons and only show the ‘name’ (or whatever, sometimes it’s really just some crappy variable name or such) in a tooltip when hovering over it?? There is completely no good reason to shuffle those icons around! - Epiphany’s new fullscreen mode. The idea is SO good!! But the implementation is so far off, I cannot believe it. First: once maximized there is *NO* way to unmaximize it. I mean, yeah, ALT+F5. After having looked it up in the *web*. Similar for *CLOSING* the frakking browser window. It requires to do 2 mouse moves and 2 clicks. Not to speak of the initial confusion of the close button being replaces by a menu, that simply should not be there. Yeah, CTRL+W. I know. It seems like one half of Gnome devs target idiots who need huge title bars in order to not miss them, and the other half targets superusers who never use the mouse and know gazillions of shortcuts. This is just wrong. - Since Gnome 3.4 some applications seem to use a new theme with slick scrollbars and stuff, while the other half uses a different theme. I guess it’s because of GTK2 vs. GTK3 dichotomy, but why?? Why not make them look the same until every major app is switched to GTK3?? Now the whole experience is totally inconsistent. I hated this when it happened with Ubuntu’s new scrollbar (and the new Gnome3.4 scrollbar is only slightly better… requires mouse-superskills) now Gnome upstream repeats the same mess. - For some unknown reason, Evolution becomes more and more broken with every release. In Gnome3.2, it would freeze every now and then when I enabled spam filtering. Now it freezes whenever the computer comes back from suspend, which is the new OFF. (Ok, it doesn’t strictly freeze, it just doesn’t seem to be able to connect to any network.) Fail. Ah, and it manages to always come up on the wrong screen. I find the state of Gnome quite sad. On one side I really like many of the ideas. On the other side, it really feels a bit like 1998 in many respects. And this is not because of needing to re-learn new concepts, I actually like to try and learn new ways of work. It is really because some things are made unnecessarily hard, for no apparent reason. Or buggy. Or both. I really wish the that those issues get ironed out over time, because I do like Gnome and the underlying ideas. [Less]

Terminal 0.9.8 was released by the GNUstep Application Project. It is mainly a maintenance release to tix bugs, enhance portability to more platforms (including GNU/HURD and OpenBSD) and current GS core libraries.

Some classpath/icedtea servers changed networks/ip addresses on Sunday. Changes should propagate through DNS on Monday. This can cause connection errors to planet.classpath.org, builder.classpath.org (buildbot and jenkins) and icedtea.wildebeest.org (hg backups). Apologies for the late notice.

Bloody hell. GNOME hackers, can someone sit Linus down and get him sorted so he stops whinging? I mean, we all know GNOME 3 and its Shell have some rough edges. Given that computers users since the stone-age have been adverse to change, it’s not ... [More] surprising that people complained about GNOME 3.x being different than GNOME 2.x (actually, more to the point, being different than Windows 95. How dare they?). Even though we believe in what we’re doing, we’re up against it for having shipped a desktop that imposes workflow and user experience changes on the aforementioned change-adverse hypothetical user. Surely, however, the negative PR impact of Linus constantly complaining about how he’s having such a hard time using GNOME exceeds what it might cost to the GNOME Foundation of getting somebody over to the Linux Foundation to help him out? Oh well, too late now. Meanwhile, I certainly do agree that extensions.gnome.org is completely useless if the first thing you see on 3.4 release day is “your web browser version isn’t new enough”. It’s not just Fedora; running Epiphany 3.4 here on a current Ubuntu system, same problem. On the other hand, if you add ppa:gnome3-team/gnome3 and ppa:webupd8team/gnome3 to a system running the current Ubuntu release you can completely ditch Unity. You get an up-to-date GNOME 3.4 that works great, and thanks to webupd8 packaging extensions, you get a fair degree of customization over the experience. Yeah, there is still lots of room for improvement, and of course there are design decisions that make you scratch your head, but come on, it’s not all bad. AfC [Less]

anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API More on Groklaw.