One exciting feature in the recent release of Fedora 32 is the inclusion of .NET Core in the default repositories. This makes Fedora 32 the first community Linux distribution with .NET Core available out of the box! In this post, lets take a quick look at using .NET Core on Fedora 32. We will cover installing .NET Core packages and building a container image. All using software only from Fedora! ...

This post covers the versions and components in .NET Core 1.x. Components .NET Core consists of multiple components that are each versioned independently and can often be mixed and matched. The Shared Framework contains the APIs and the Virtual Machine and other runtime services needed for running .NET Core applications. The current .NET Core Virtual Machine is called CoreCLR. This executes the .NET bytecode by compiling it JIT and provides various runtime services including a garbage collector. The complete source code for CoreCLR is available at https://github.com/dotnet/coreclr. The .NET Core standard APIs are implemented in CoreFX. This provides implementations of all your favourite APIs such as System.Runtime, System.Theading and so on. The source code for CoreFX is available at https://github.com/dotnet/corefx. The Host is also sometimes called the muxer or driver. This components represents the dotnet command and is responsible for deciding what happens next. The source for this is available at https://github.com/dotnet/core-setup. The SDK consists of the various tools (dotnet subcommands) and their implementations that deal with building code. This includes handling the restoring of dependencies, compiling code, building binaries, producing packages and publishing standalone or framework dependent packages. The SDK itself consists of the CLI , which handles command line operations (at https://github.com/dotnet/cli) and various subprojects that implement the various operations the CLI needs to do. Versions Each of the components listed above are versioned separately. You can find out the version of each of those components. ...

Looking to try out OpenJDK 9? If you didn’t know, OpenJDK 9 is going to be the reference implemtation for Java 9 (assuming the pattern for Java 7 and Java 8 continues). Pre-release packages for Fedora 23, 24, 25 and Rawhide as well as RHEL 7 are available on copr: https://copr.fedoraproject.org/coprs/omajid/openjdk9/ Please note that these are not official Fedora (or RHEL) packages. Official Fedora packages will be proposed and added to Fedora closer to OpenJDK 9’s release. ...

Inspired by this post by Mark Wielaard I started wondering how OpenJDK 9 would fare in a -Wmisleading-indentation test. So I built OpenJDK 9 using -Wall to find out. First, though, a big heads up: the OpenJDK 9 build selectively enables and disables warnings and turns on -Werorr. There doesn’t seem to be a straight- forward way of enabling all compiler warnings everywhere. I ended up patching various makefiles to comment out various DISABLED_WARNINGS* flags. Hotspot needed a separate patch to initialize WARNING_FLAGS with -Wall in hotspot/make/linux/makefiles/gcc.make. Then I built OpenJDK 9 using: ...

I posted 3 patches today The first patch is for OpenJDK 9. It creates a hole that allows alternative plugin implementations to plug into (pardon the pun) OpenJDK and make use of existing plugin-specific classes in OpenJDK. The second and third patches are for IcedTea-Web. They allow IcedTea-Web to (progressively) build against OpenJDK8 and OpenJDK9. What does this mean? Soon we might actually be able to build and run IcedTea- Web against OpenJDK. Yes, an Open Source/Free Software plugin running on top of OpenJDK (without any custom patches). Of course, a lot of this is still up in the air. The OpenJDK folks might not accept the patch, though I am hopeful they will - it’s very small and conservative. ...

On December 5, 2013, the OpenJDK6 b29 source bundle was published at https://java.net/projects/openjdk6/downloads/. This is a security bugfix release that includes all the security patches since the b28 release. A complete list of changes is available too. The test results were not ideal. The TCK failed, with all issues again basically boiling down to limited cryptography support. There are patches available to fix this. As far as I can tell this is not a regression. ...

On October 4, 2013, the OpenJDK6 b28 source bundle was published at https://java.net/projects/openjdk6/downloads/. This includes all the security patches since the b27 release as well as a major version bump in hotspot to hs23. A complete list of changes is available too. The test results were not ideal. The TCK failed, with all issues basically boiling down to limited cryptography support. There are patches available to fix this. As far as I can tell this is not a regression. ...

Someone asked me earlier today about how to contribute patches to OpenJDK. OpenJDK is probably not the easiest upstream to contribute patches to - their patch approval system is a little different from most other projects. I have tried to summarize the basic steps here. Let me know in comments if anything is not clear. The OpenJDK Developer’s Guide covers most of this, but some of it is in too much detail and some of it is outdated. The process I describe here is what I have seen others use and what I have been using myself. ...

I have always been impressed by the effort OpenJDK folks go to maintain API compatibility. I recently came across a nifty little trick that is used in the OpenJDK codebase to help achieve this goal. Behold the SharedSecrets class! The name of the class is a little misleading since it doesn’t have anything to do with the cryptographic concepts of shared secrets. The javadocs do a (slightly) better job describing its purpose: ...

I have been playing around with awesome and ran into some issues with Java programs (apparently others users are running into those problems too). I hacked together a patch against OpenJDK7 that seems to solve all my issues: diff --git a/src/solaris/classes/sun/awt/X11/XWM.java b/src/solaris/classes/sun/awt/X11/XWM.java --- a/src/solaris/classes/sun/awt/X11/XWM.java +++ b/src/solaris/classes/sun/awt/X11/XWM.java @@ -102,7 +102,8 @@ METACITY_WM = 11, COMPIZ_WM = 12, LG3D_WM = 13, - CWM_WM = 14; + CWM_WM = 14, + AWESOME_WM = 15; public String toString() { switch (WMID) { case NO_WM: @@ -131,6 +132,8 @@ return "LookingGlass"; case CWM_WM: return "CWM"; + case AWESOME_WM: + return "awesomewm"; case UNDETERMINED_WM: default: return "Undetermined WM"; @@ -573,8 +576,12 @@ // getIntProperty(XToolkit.getDefaultRootWindow(), XAtom.XA_CARDINAL)) == 0); } + static boolean isAwesomeWM() { + return isNetWMName("awesome"); + } + static boolean isNonReparentingWM() { - return (XWM.getWMID() == XWM.COMPIZ_WM || XWM.getWMID() == XWM.LG3D_WM || XWM.getWMID() == XWM.CWM_WM); + return (XWM.getWMID() == XWM.COMPIZ_WM || XWM.getWMID() == XWM.LG3D_WM || XWM.getWMID() == XWM.CWM_WM || XWM.getWMID() == XWM.AWESOME_WM); } /* @@ -754,6 +761,8 @@ awt_wmgr = CWM_WM; } else if (doIsIceWM && isIceWM()) { awt_wmgr = XWM.ICE_WM; + } else if (isAwesomeWM()) { + awt_wmgr = XWM.AWESOME_WM; } /* * We don't check for legacy WM when we already know that WM Given the effort it’s taking to push a fix for mutter (the default gnome3 window manager), I wouldnt hold my breath waiting for this code to make it upstream.