GNU Classpath

We are pleased to announce the release of IcedTea6 1.12.0! 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 ... [More] alternative virtual machines. This is the first major release in a year (1.11 was released on 2012-01-30). In accordance with the release policy, 1.10 will no longer receive security updates. If you find an issue with one of these releases, please report it in our bug database under the appropriate component. Development discussion takes place on the OpenJDK distro-pkg-dev mailing list and patches are always welcome. Full details of each release can be found below. What’s New? New in release 1.12.0 (2013-01-29) Import of OpenJDK6 b27 (all changes already in security updates) Import of OpenJDK6 b26 S7071826: Avoid benign race condition in initialization of UUID S7123896: Unexpected behavior due to Solaris using separate IPv4 and IPv6 port spaces S7142509: Cipher.doFinal(ByteBuffer,ByteBuffer) fails to process when in.remaining() == 0 S7157903: JSSE client sockets are very slow S7174440: JDK6-open build breakage S7175845: JSSE client sockets are very slow S7176477: TEST: Remove testcase test/java/lang/SecurityManager/CheckPackageDefinition.java from jdk6-open S7184700: Backout changes with wrong id for 7157903 S7199153: TEST_BUG: try-with-resources syntax pushed to 6-open repo Import of OpenJDK6 b25 S6790292: BOOTDIR of jdk6 u12 will not work with jdk7 builds S6967036: Need to fix links with // in Javadoc comments S7007299: FileFontStrike appears not to be threadsafe S7022473: JDK7 still runs /etc/prtconf to find memory size S7058133: Javah should use the freshly built classes instead of those from the BOOTDIR jdk S7107919: Remove hotspot assertion due to Solaris 8 kstat “unimplemented”. S7123519: problems with certification path S7126889: Incorrect SSLEngine debug output S7127104: Build issue with prtconf and zones, also using := to avoid extra execs S7128474: Update source copyright years S7128505: Building on em64t system does not work S7149751: another krb5 test in openjdk6 without test infrastructure Backports S6706974: Add krb5 test infrastructure S6764553: com.sun.org.apache.xml.internal.security.utils.IdResolver is not thread safe S6761072: new krb5 tests fail on multiple platforms S6883983: JarVerifier dependency on sun.security.pkcs should be removed S4465490: Suspicious about double-check locking idiom being used in the code S6763340: memory leak in com.sun.corba.se.* classes S6873605: Missing finishedDispatch() call in ORBImpl causes test failures after 5u20 b04 S6980681: CORBA deadlock in Java SE believed to be related to CR 6238477 S7162902: Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8 S6414899: P11Digest should support cloning S4898461: Support for ECB and CBC/PKCS5Padding S6604496: Support for CKM_AES_CTR (counter mode) S6682411: JCK test failed w/ ArrayIndexOutOfBoundException (-1) when decrypting with no data S6682417: JCK test failed w/ ProviderException when decrypted data is not multiple of blocks S6687725: Internal PKCS5Padding impl should throw IllegalBlockSizeException and not BadPaddingException S6812738: SSL stress test with GF leads to 32 bit max process size in less than 5 minutes with PCKS11 provider S6867345: Turkish regional options cause NPE in sun.security.x509.AlgorithmId.algOID S6924489: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_OPERATION_NOT_INITIALIZED S7088989: Improve the performance for T4 by utilizing the newly provided crypto APIs Bug fixes PR902: PulseAudioClip getMicrosecondsLength() returns length in milliseconds, not microseconds PR1050: Stream objects not garbage collected PR1113: Add tapset tests to distribution. PR1117: IcedTea6 prebuilds far too many classes on bootstrap PR1121: Old installs still suffer from GCC PR41686 PR1119: Only add classes to rt-source-files.txt if the class (or one or more of its methods/fields) are actually missing from the boot JDK PR1114: Provide option to turn off downloading of tarballs (–disable-downloading) PR1176: Synchronise CACAO rules between IcedTea6/7/8 where possible RH513605, PR1171: Updating/Installing OpenJDK should recreate the shared class-data archive G422525: Apply pax markings before using a freshly built JVM. PR986: IcedTea7 fails to build with IcedTea6 CACAO due to low max heap size CACAO PR1120: Unified version for icedtea6/7 CA166, CA167: check-langtools fixes for icedtea6 Implemented sun.misc.Perf.highResCounter CACAO now identifies by its own Mercurial revision Some memory barrier maintenance Ability to run when compiled as Thumb on armv5 (no Thumb JIT though) Stop creating pseudo files for OpenJDK (libjsig.so, Xusage.txt) Clang fix for the i386 backend CONTRIBUTE: Reference code submission process wiki instructions. INSTALL.CACAO: Update, so following the instruction actually works. Make doxygen work CA172, PR1266, G453612: ARM hardfloat support src/scripts/java.in: Look for cacao executable in install path, not in PATH. src/vm/jit/alpha/asmpart.S: Fix copyright header. src/vm/jit/alpha/asmpart.S: Properly set up GP in asm_abstractmethoderror Use @abs_top_builddir@ for support scripts JamVM ARMv6 armhf: Changes for Raspbian (Raspberry Pi) PPC: Don’t use lwsync if it isn’t supported X86: Generate machine-dependent stubs for i386 When suspending, ignore detached threads that have died, this prevents a user caused deadlock when an external thread has been attached to the VM via JNI and it has exited without detaching Add missing REF_TO_OBJs for references passed from JNI, this enable JamVM to run Qt-Jambi PR1155: Do not put version number in libjvm.so SONAME SystemTap Addition of garbage collection probes The tarball can be downloaded from: http://icedtea.classpath.org/download/source/icedtea6-1.12.0.tar.gz (sig) SHA256 checksums: 4f27f3f42b57836cfb11541736282ccfc22de3f4acc0e540560fcf5512d66ced icedtea6-1.12.0.tar.gz Each tarball is accompanied by a digital signature available at the above ‘sig’ link. 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 this release: Lukas Berk (garbage collection probes) Andrew Haley (PR584 & other ARM32 port fixes) Andrew John Hughes (all other fixes, OpenJDK updates & release management) Robert Lougher (JamVM fixes) Omair Majid (PR1050 & other PulseAudio fixes) Xerxes Rånby (JamVM updates & ARM32 fixes) Stefan Ring (CACAO updates & fixes) Ralph Sennhauser (G422525) Yasumasa Suenaga (SystemTap fixes) Pavel Tisnovsky (S4465490, S6883983, S6761072, S6764553, patch & test fixes) Jon VanAlten (tapset test work) Mark Wielaard (SystemTap & makefile fixes) We would also like to thank the bug reporters and testers! To get started: $ tar xzf icedtea6-1.12.0.tar.gz $ cd icedtea-${version} Full build requirements and instructions are in INSTALL: $ ./configure [--with-parallel-jobs --enable-pulse-java --enable-systemtap ...] $ make Happy hacking! [Less]

RoboVM 0.0.1 got released this week by Trillian AB. RoboVM’s main focus is to compile Java to native for deployment on mobile devices such as iOS and Android. RoboVM uses a Java to Objective-C bridge built using LLVM. Good news is that the same ... [More] process work for converting Java applications to native applications on GNU/Linux systems as well! Mario Zechner the author of libgdx posted this nice picture from inside DDD/GDB of his first HelloWorld compiled to native X86 code running on a GNU/Linux machine. http://www.robovm.org/ [Less]

This is the first entry of a series about Thermostat plugin development.The API is still being finalised, although most of the things we will show in this series of article should have little or no changes until the 1.0 release and will not have ... [More] incompatible changes during at least all of 1.x series. Before starting, I think is a good idea to describe the overall general architecture of the Thermostat Framework.Thermostat is a multi-tier application, where each tier consist of one or more different implementations of the same set of services. This is done to accomodate various possible deployment scenarios, which we usually describe as horizontal scalability. For example, Thermostat can be deployed in a single host environment or over the web to track multiple hosts (or clusters). It would be silly (and extremely resource intensive) to ask users to configure a servlet container or remote database just to quickly check the memory use of a small application. When possible, and when security is less of a concern, Thermostat clients talk directly to the (presumably local) database. When such scenario is not desirable, we need to plug some kind of proxy in between, but we don't want to change the implementation of the client, especially since it may be user code we have no control over.Still speaking about Databases, we also want to be able to support different kind of databases. Currently Thermostat uses MongoDB, which is a NoSQL database. But what if the users can't install MongoDB on their machines, and instead need to use some other kind of Database, perhaps an SQL one, like Postgres or MySQL, just for the sake of example? The solution to this problem resides in the service architecture. Thermostat services are small units, most of the time Interfaces, that export functionality. In the Database case this functionality is provided by the Storage API. Storage deals with plain Java objects opportunely annotated. Plugin developers can then request the current available Storage service, the Thermostat framework will then pass the most appropriate for the current use case in the deployment scenario. A new backend can be easily implemented and the framework configured to return this new implementation in the given scenario.Another example is the GUI client. We currently support two GUI frameworks, Swing and Eclipse, plus command line commands. It's possible for a plugin developer to only provide plugins for one GUI target, which means that Thermostat simply won't activate the plugin if the other frameworks is not available.Of course, this introduce a level of redundancy that can lead to code duplication, so in all the framework we keep a lot of attention in modularization and reuse. Shared components that are agnostic to the specific view or deployment solution can be shared, and Services consist of the smallest possible unit of deployment. This means that Services consume and depend on other services in order to export the necessary functionality. The way all those services are handled is via OSGi bundles. Basically everything in Thermostat is a plugin, where plugin consist of one or more OSGi bundles. In this set of articles I will guide you through the development of a simple plugin, and will show you how to access and configure Thermostat to enable, and extend when necessary, the desired functionality.Chapter 0. The Plugin!Next week we will have FOSDEM. Now, Thermostat is a monitoring tool... so what's better than monitoring People's presentations at FOSDEM? :)We will write in those days a simple scheduler plugin to do exactly this. We will import from a file the presentations and speakers details for the JavaDev Room into the database, and we will create a stop watch to track time for each presentation.The client will read presentation details from the database and keep count of the time remaining for each presentation. We will use the Swing Client and the Agent frameworks, we won't have any Eclipse or command line option.We will use maven to take care of dependencies and build the scheduler, but of course it‘s possible to use ant or gradle or anything else. We also don‘t require any particular IDE, in fact, even if the most of Thermostat is developed in Eclipse, I will use NetBeans 7.2 to code this plugin.The code for the plugin is located here:http://icedtea.classpath.org/people/neugens/scheduler-plugin/Simply clone the repository:hg clone http://icedtea.classpath.org/people/neugens/scheduler-plugin And open in your favourite IDE. I will update the code constantly, but I'll make sure to tag for each entry of this series. The first tag is "tutorial_day_1a". Chapter 1. Structure and initial code drop There is a minimal recommended structure needed to create and deploy a new Thermostat Plugin, although this is not mandatory of course.We will expand the structure as needed, but for this first part, we will only have one task: show the first UI component as quickly as possible.This is how it will look at the end of the day: Pretty boring, I know... But we will improve things in the coming days, don't worry :)The Client API has various entry points. Most of the services are shared between the client frameworks, although some are specific to the Swing GUI. For example, is possible add a Menu or decorate the VM and Host Tree with additional information.In fact, if you pay close attention, the Tree has been annotated already, the icons indicate an host (the computer icon close to the Pegasus host) or few JVMs running on the Pegasus system (annotated with the Duke icon).Those annotations are provided by a plugin too, they are not part of the core Thermostat (but Thermostat comes with full optionals, so every installation will have this plugin already, don't worry :)The Host and VM tree behaves as a selector. It allows to move between virtual machines and hosts by simply selecting one of them to display the correct information. When one entry is selected, a plugin controller is instantiated. Plugin developers need to provide this controller. The controller will register some information regarding the type of view it will support, for example if it's an Host or a VM type of view.This is typically done by creating an InformationService specialisation. We will see in more details those components and how to use them, for now this short introduction is only meant to show that Thermostat makes heavy use of the MVC architecture. With this information at hand, we can describe the layout of this first code drop:/scheduler-plugin /client-common/client-controllers/client-swing Each of those directories contain a maven pom and some source files (I won't bother with tests just yet, but I may add some later ;)The common subproject contains common stuff used by both the swing and controllers sub packages, while controllers contains... well... the controllers and finally client-swing contains the Swing based views.Each modules is a different OSGi bundle, with an actual Activator (with the exception of the common package, which at this point doesn't need an Activator). The reason to have this separation in place is both reusability and the ability to support more clients type, but it's perfectly legal to have everything in one single package.Let's have a closer look at the content of each bundle.First the controllers: Then the common packages:  And finally the client: Chapter 2. Common CodeThe common code contains and abstract class and one interface right now. Those are:SchedulerViewProvider SchedulerViewAs the javadoc for the ViewProvider  states and the name rather easily implies, the class is responsible to create Views. It's usually responsible to create the main view for the plugin and should be registered (with an actual implementation). It's not mandatory to have this class registered and used, the Controller can instantiate the views directly if this is desired. The reason to have this class and the view handled this way is, once again, to allow modularity.Note how the SchedulerView extends BasicView and implements UIComponent. BasicView is a common class to all the Views in Thermostat, it contains boilerplate code to aid notification of some default actions like visibility, which are common to all the views. UIComponent is a marker interface, it's used to indicate that the class can be used as a target for drawable content.Thermostat divides user interface elements in two categories, Managed components are components that will provide Actions, but that are managed by the framework completely. An example of this category are menu options or context actions, like the "Kill VM" switch that shows up when right clicking on one VM in the Host and Virtual Machine Tree in the main client UI. Those do not need to be marked as UIComponent. Drawable components are complex elements that need to delegate all the work to the plugin, and need to be marked as UIComponent, as we will see in a minute. This interface has a couple of specialisation depending on the target framework, in our simple plugin we are interested in SwingComponent, which we will explore next. Chapter 3. Views and GUI code The client swing bundle contains the actual implementation for the classes defined in the common-code. The most interesting part of this bundle are the activator, where the SchedulerViewProvider is registered, and the SwingSchedulerView:public class SwingSchedulerView extends SchedulerView implements SwingComponent {    public SwingSchedulerView() {    }     public Component getUiComponent() {        return new JLabel("Scheduler is here!");    }}Note how SwingSchedulerView also implements SwingComponent. Chapter 4. ControllersThe Activator for the controller shows how to use an utility that makes life in OSGi easier, MultipleServiceTracker, which allows to listen for more than one service at once and be notified after all the services required have been activated.In this case we are interested (for now) inApplicationServiceSchedulerViewProviderWe have seen already the view provider.ApplicationService is a class that provides some services like access to the ApplicationCache or a system wide executor service and the TimerFactory. In particular, the cache and the timer factory are important services, in that they enable time based actions and caching of the state of application, which is extremely useful since views in thermostat are stateless, this means that the framework doesn't do any effort to save the state of the view, is completely responsibility of the plugin to ensure a consistent state and to remember user settings even during the lifetime of the same session (for example, this is where we would save which tab is open or if a button is pressed and so on).At this point (although this may change in the future, but unlikely before 2.0) programmers should not assume that controllers and views are the same objects each time, views can be recreated at any time, the only guarantee is that views are not disposed while they are visible.The same constraints are valid for controllers (this is less of a limitation than may seem at the first glance, and highly simplifies the internal architecture).The Activator creates a SchedulerInformationService and register it as InformationService. InformationService are units that signal a Point of Interest for Thermostat and are denoted internally as @ExtensionPoint. Plugins register InformationService with some specialisation, for example HostRef or VmRef. This basically means they provide a PoI that shows up when either something in HostRef or VmRef that matches the given Filter is selected (in our case, we use a predefined filter than matches everything).Our plugin is a HostRef since we are not interested in tracking Virtual Machine events here, we rather want a system wide PoI (like tracking the DevRoom schedule :)Note also the Dictionary property, this is very important to configure the PoI. Next and final part of this walk through is the SchedulerMainController. Here you can finally see where the UIComponent is used, making the controller completely agnostic to the actual type of the view, so that we can simply replace the Swing component with a SWT (or JavaFX or perhaps even an Android component in the future), and still reuse everything else without changes of sort.Chapter 5. Build and DeploymentBuilding the plugin is just a matter of doing a: mvn clean installThe maven pom contains the configuration for the bundles, which is mandatory to load modules inside Thermostat; although can be done in a different way than the one proposed here (for example, manually editing the MANIFEST), using maven (or gradle) abilities to automatically create the bundle manifest is definitely easier and less error prone. Regarding deployment, an automatic way to deploy plugins is not yet in the thermostat repository as of this writing, but is being finalised (with patch post for review) and is scheduled by 0.6 which should happen in a couple of weeks. Right now there is some minor manual fiddling required.This basically means we need to copy the jar files in the $THERMOSTAT_HOME/libs directory (this is done by the copy_jars script included with the plugin sources) and then edit the file: $THERMOSTAT_HOME/distribution/target/etc/commands/gui.propertiesAdding the following jars at the end of the bundles entry: thermostat-tutorial-client-swing-0.0.1-SNAPSHOT.jarthermostat-tutorial-client-controllers-0.0.1-SNAPSHOT.jarthermostat-tutorial-client-common-0.0.1-SNAPSHOT.jarChapter 6. ConclusionThermostat is a very complex application, although part of the complexity is hidden by the comprehensive and rich API. This small tutorial has introduced some of the basics building blocks of the Thermostat powerful API.The next entries of this series will add more content to the Swing View and start handling Database communication. [Less]

I finally fixed the limitation that classes dynamically loaded by an assembly class loader can't access the internals of the assembly. Here's a simple demonstration of the problem. Suppose you have these two classes: ... [More] class Other {   static {     Test.m();   } } class Test {   public static void main(String[] args) throws Exception {     Class.forName("Other");   }   static void m() {     System.out.println("Test.m");   } } Now if you compile Test.class (without Other) into an assembly with a ClassPathAssemblyClassLoader and run this with IKVM.NET 7.2 you'll see something like this: C:\j>ikvmc Test.class -classloader:ikvm.runtime.ClassPathAssemblyClassLoader IKVM.NET Compiler version 7.2.4630.6 Copyright (C) 2002-2013 Jeroen Frijters http://www.ikvm.net/ note IKVMC0001: Found main method in class "Test" note IKVMC0002: Output file is "Test.exe" C:\j>Test Exception in thread "main" java.lang.ExceptionInInitializerError         at cli.System.Runtime.CompilerServices.RuntimeHelpers._RunClassConstructor(Unknown Source)         at IKVM.Internal.TypeWrapper.RunClassInit(Unknown Source)         at IKVM.NativeCode.java.lang.Class.forName0(Unknown Source)         at java.lang.Class.forName(Class.java:287)         at Test.main(Test.java:9) Caused by: cli.System.MethodAccessException: Test.m()         at Other.<clinit>(Test.java) The call from Other to Test fails with a MethodAccessException, because the dynamic assembly does not have access to the internal members of the Test.exe assembly. Long ago I considered fixing this by adding an InternalsVisibleToAttribute to all statically compiled assemblies that allows the runtime generated dynamic assembly access to its internals, but I dismissed this because it would mean that untrusted code could abuse this same assembly identity to access the internals of any ikvmc compiled assemblies. Forging a StrongNameKeyPair Yesterday I realized that I could use InternalsVisibleToAttribute without opening a security hole. When the IKVM runtime is running as fully trusted code, it can forge a StrongNameKeyPair to attach to the dynamic assemblies it generates and thereby gain access to the statically compiled assemblies, without giving untrusted code the same access. The only downside to this approach is that it relies on an implementation detail of the CLR (and Mono). I try to stay away from depending on implementation details, but in this case the gain far outways any risk. Using It From C# It also works for your C# assemblies. By adding a custom attribute, you can now enable dynamically loaded Java classes access to your assembly internals. Here's a C# example: using System;using System.Runtime.CompilerServices;using java.lang;using java.lang.reflect; [assembly: InternalsVisibleTo("DemoApp-ikvm-runtime-injected, PublicKey=00240000048000009400000006020000002400005253413100040000010001009D674F3D63B8D7A4C428BD7388341B025C71AA61C6224CD53A12C21330A3159D300051FE2EED154FE30D70673A079E4529D0FD78113DCA771DA8B0C1EF2F77B73651D55645B0A4294F0AF9BF7078432E13D0F46F951D712C2FCF02EB15552C0FE7817FC0AED58E0984F86661BF64D882F29B619899DD264041E7D4992548EB9E")]interfaceIFoo {   Program Instance { get; } }classProgram : InvocationHandler {   staticvoid Main() {     Class c = typeof(Program);     var cl = c.getClassLoader();     var interfaces = newClass[] { typeof(IFoo) };     var handler = newProgram();     var proxy = (IFoo)Proxy.newProxyInstance(cl, interfaces, handler);     Console.WriteLine(proxy.Instance);   }   publicobject invoke(object obj, Method m, object[] objarr) {     returnthis;   } } Here we create a Proxy for the non-public interface IFoo. This is allowed because of the InternalsVisibleToAttribute that gives access to an assembly named DemoApp-ikvm-runtime-injected with the specified public key. The name of the assembly must be the name of the current assembly (in this example "DemoApp") with "-ikvm-runtime-injected" appended. The public key is always the same. The corresponding private key does not exist. Development Snapshot Please note that this is a development snapshot, not a release or release candidate. So consider it untested. Changes: Use InternalsVisibleToAttribute to allow the runtime to dynamically inject classes into statically compiled assemblies. Stop generating proxy helpers for non-public interfaces. Added support for RadialGradientPaint in Graphics.setPaint(). Binaries available here: ikvmbin-7.3.4772.zip [Less]

There have been more important contribution than mine to this project, but still, it's nice to get my name in it even for such small things :) http://hg.openjdk.java.net/openjfx/8/controls/rev/30c264fe5819 It also gives a way to get used to the ... [More] process before doing more important and difficult patches, and I can't wait to see the OpenJFX talks at the Java DevRoom at FOSDEM.A big thanks to the OpenJFX developers! [Less]

[As sent to distro-pkg-dev] I’d like to do a couple of new releases of both 6 & 7 by the end of this week (Friday the 25th of January, 2013). This will enable us to get some fixes out to users that are lurking only in HEAD. This is particularly ... [More] true of 6 where the last major release is nearly a year ago (30th of January, 2012). Note that 2.4.0 is already tagged in the forest, so any remaining changes prior to release will only take place in IcedTea7. These release will also make the upcoming security release easier, as we will then update them rather than the aging 1.10 and 2.2, as stated in the release policy. In particular, it is becoming painful to maintain 1.10 as it has two HotSpot releases. Others are, of course, welcome to update these releases if they so wish. I intend to delay creating branches for these releases until after the release, as neither repository is particularly high traffic at the moment. Please bear this in mind if you intend to commit work this week, and perhaps consider delaying it until the week after if it will be fairly disruptive. If anyone has objections to the release of 1.12 and 2.4 this Friday, please reply to this mail as soon as possible. I’m unwilling to delay them much further as we get closer to the update, and I’d rather not be bundling feature updates with security updates. The security update will still bring updates for 1.11, 2.1 and 2.3 (2.1 being for the ARM32 port), so an option remains between the new releases and the old. [Less]

I'll be speaking in the Free Java dev room at FOSDEM on Sunday afternoon on Project Nashorn and OpenJFX. See you there!

The last couple of years, I had to pass FOSDEM, for various reasons. I am very very happy that I finally sorted things out for this years FOSDEM, and I’m ready to go (hotel and trains booked). I will do a presentation about my Shark & Zero work ... [More] on Saturday afternoon, and co-present Thermostat with Mario on Sunday noon, both in the Java dev room. FOSDEM is one of those rare events in my life about which I can say that it had a very significant impact. I wouldn’t be where I am today, if I hadn’t attended it a few years ago. I am very happy that I can finally go there again, and meet lots of old and new friends and collegues. See you there, and cheers! [Less]

I don’t like to go into too much detail about security updates, but I think it’s necessary to point out a few facts about the one we released yesterday, given some of the inaccuracies I’ve seen been spread on Twitter and elsewhere. Patches were ... [More] belatedly approved for OpenJDK 7u. OpenJDK 6 is not affected. 8004933: Improve MethodHandle interaction with libraries 8006125: Update MethodHandles library interactions Running Java code from the command-line is quite different from running it via a browser plugin. In the latter situation, the user generally does not invoke the code and it runs in a sandbox with a much restricted set of privileges. Security issues occur when ways are found of achieving privilege escalation and being able to do thiings from the browser plugin that shouldn’t be allowed, such as invoking a program on the user’s computer. Bugs that allow this have a much higher security impact. Such escalation is fairly irrelevant when running Java from the command line as generally users run without a security manager and the code has full privileges anyway. It is generally advisable to only run plugins in the browser that are needed (this applies to both Java and others such as Flash) and, where possible, whitelists should be used so that plugins are only used on pages approved by the user (of course, this depends on how informed the user is about giving such approval). So, all these advisories to turn off the Java browser plugin have some merit, as if you don’t use the plugin, you won’t be hit by browser-based exploits from either this issue or any future issues which may occur. Some people, of course, have no choice but to use the plugin, as some sites they use require it. In these situations, the plugin should only be used on those sites and disable for others; browsers such as Firefox and Chromium are now starting to provide users with more options (such as ‘click to play’) as to when and where plugins are invoked, and this will also help with security issues. As always, any opinions expressed here are my own, and not those of Red Hat, Inc. [Less]

The recent Windows RT jailbreak enabled me to run IKVM on my Surface RT. Out of curiousity I decided to run a part of the test suite. Only three tests failed, one because it relies on specific GC behavior and two because they ... [More] use JVM.DLL. Previously, IKVM's JVM.DLL assemblies were created with ilasm, because that was the easiest way to create unmanaged exports at the time. However, ilasm doesn't seem to support ARM, so I added this support to IKVM.Reflection and wrote a simple tool to generate unmanaged export assemblies. Of course, supporting unmanaged exports on Windows RT in IKVM.Reflection is not very useful, but it was an interesting exercise to learn a little bit about the ARM instruction set. I also did some more useful work. I finally got around to changing how ikvmc handles assembly references. It now works like the C# compiler and uses the IKVM.Reflection support for missing assemblies that I added for mcs. This means that it no longer automatically loads assemblies (apart from the IKVM runtime and class library assemblies) and you need to add explicit references for indirectly used assemblies as well. The downside is that this has the potential to break some builds, but the upside is that the compilation process is now more predictable and only loads the actually required assemblies, like a "real" compiler, instead of the System.Reflection heritage that required loading even unused dependencies. Another change is that ikvmstub jars are now officially deprecated from being used with ikvmc (it will still work for a while, but a warning message is issued). Finally, it is now illegal to explicitly reference a secondary assembly in a shared class loader group. Previously this caused a warning message, but now this is an error. You need to reference the primary assembly. Changes: Deduplicate ikvmc messages based on all parameter values, not just the first one. Allow ikvmc messages to be suppressed based on any number of parameter values. Fixed ikvmc to write fully specific -nowarn options to suppress file. Fixed ikvmc to handle missing types. Added ikvmc support for missing assemblies. Officially deprecated using stubs with ikvmc. Bug fix. Don't add duplicate methods to attribute annotation interfaces. The primary cause of this was attributes with virtual properties where we would add the base class property as well as the derived class overridden property. Changed build process to replace ilasm usage to generate JVM.DLL with a custom tool. Bug fix. Local variable analysis for finally blocks was incorrect. Fixes bug #3600788. Changed ikvmc to give an error message (instead of a warning) when referencing a secondary assembly from a shared class loader group). Made ikvmc EditorBrowsableAttribute construction fully symbolic, to avoid having to load System.dll. Disabled automatic assembly loading for ikvmc. Suppress ikvmc warnings after an error has occurred (to avoid obscuring the fact that compilation failed). IKVM.Reflection: Added UniverseOptions.ResolveMissingMembers and deprecated EnableMissingMemberResolution(). IKVM.Reflection: Added Universe.ResolvedMissingMember event. IKVM.Reflection: Fixed importing of CLR types with funny names (where we'd previously run into bugs in CLR's Type.Name and Type.Namespace). IKVM.Reflection: Restructured relocation writing to pack all relocation in a page in the same block, as WoA apparently requires this. IKVM.Reflection: Implemented ARM startup stub. IKVM.Reflection: Implemented ARM unmanaged exports. Binaries available here: ikvmbin-7.3.4764.zip [Less]