So that's the real world: I'm just starting to use Java 5. Java 6 is a distant dream - IBM's JDK 6 just went gold after an year-long beta, but there is no WebSphere update yet to include the new JDK, I guess I'll have to wait another 1-2 years until this update is fully complete, supported, tested, endorsed, and available in my clients' production servers. So when it comes to Java 7, well, I think I'll be happy if I can use that in large-scale, mission-critical applications (with IBM gear anyway), before I retire...

The real problem is that Java 5's language features were implemented with too many ties to the J2SE 5.0 platform: -source 5 will only accept -target 5. There's an unsupported javac switch that will allow some generics to target 1.4. But javac could do much better, as proven by third-party tools like RetroWeaver and JBoss Retro. (Similar support from javac would be much simpler than in those tools; javac could generate alternative code for older JVMs straight away, instead of generating 5.0-only bytecode that needs to pass through complex bytecode transformations to be replaced by alterenative code.) But it's also hopeles to use these tools in the environments I deal with. These translators have two severe problems:

1) They are not official tools. If I propose to use these things, my client's first question will be "is this supported by [insert large app server vendor here]?".
2) They make the edit/compile/deploy/debug cycle even more complex. I have systems with several dozen EARs and over a hundred projects, and I depend on the productivity of IDEs that update deployment into servers, automatically and quickly, and these IDEs have no flexibility to add a bytecode post-processor anywhere (but correct me if I am wrong, it's been some time since I last checked these tools).

So, my #1 wish for Java SE 7, whatever is the set of new language features that we decide to implement, is: make a best effort to support these features with -target 5, or at the very least -target 6. All features proposed to date are in the category of syntax sugar that's easily compilable into bytecode that current JVMs can load. Of course there's always some corner casees, like J2SE 5.0's enums which required new serialization support in the guts of the Java core; or in the same release, generics requiring new reflection APIs. So even if the proposals for Java SE 7 require special runtime support, there are several workarounds:

- Generating different code for older JVMs, even if it's slower (good solution when the runtime support is only an optimization).
- Backporting the new runtime support to the older JVMs, but making it private - for example, repackaging new APIs into sun.* packages, and translating calls to these APIs.
- Proving compatibility jars that can be dropped in older JREs' lib/endorsed. BTW, this could also be a great solution for critical new core APIs. See the backport-util-concurrent project for a good example - but it shares the same problems of being a non-official, non-supported package (although it's easier to sneak into projects: just drop the jar in your EAR's /lib and don't tell anyone...).

]]> 2008-01-14T12:18:21Z 2007-10-05T18:02:53Z tag:weblogs.java.net,2007:/blog/opinali/232.8380 2007-10-05T18:02:53Z

Tabs are only a problem if you mix tabs and spaces before the first non-whitespace char, or indent some lines with tabs and others with spaces, or if you use tabs after the first non-whitespace char. If you have discipline to use tabs the way God intended when He created the ASCII charset; that is, using tabs (and only tabs) for indentation only - then tabs have the advantage of allowing each programmer to pick his or her preferred indentation size, and none of the claimed disadvantages.

I have written a small Java utility that will scan a directory tree with text files, and fix tab/whitespace usage automatically. I wrote this utility after searching, and not finding, anything similar on the Internet - it seems there are some utilities (created from programmers from the dark side of the force) that will do the reverse operation of expanding tabs to spaces. I think only Jalopy would do what I wanted, but at the cost of forcing me to run a full reformat.

The code is very small, so I'm just including it in this blog; enjoy if you find it useful. It's released to the public domain. The program is easy to use and efficient, and I won't claim that any code is bug-free but I've been using it for a couple years without any issues. I fear however, that this code may be confused by filesystems with links (limitation of java.io), or arbitrary Unicode data (I assume 8-bit chars). And I didn't have time to add really cool features like IDE integrations. Clearly it's not a sufficiently advanced program to make me the next famous open source project leader, so I'm posting this here just to help other programmers who are in the Right side of the Tab Wars... yeah, you know what you're supposed to do now: just wait till all your coworkers go home next Friday night; checkout the entire company repositories' sources; run FixTabs from the root; commit. ;-)

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.IOException;
import java.io.RandomAccessFile;
import java.util.ArrayList;
import java.util.regex.Pattern;

/**
 * Fixes usage of physical tabs in text files: Tabs are mandatory for indentation,
 * and only allowed for that purpose (forbidden after first non-blank in line).
 * 
 * @author osvaldo
 */
public class FixTabs
{
	private static int spacesPerTab = 4;
	private static final ByteArrayOutputStream baos = new ByteArrayOutputStream();
	private static final String[] defaultIncludes = { ".*\\.java", ".*\\.properties" };
	private static final String[] defaultExcludes =
	{
		"\\..*",     // .svn, Unix, Eclipse hidden directories
		"CVS",       // CVS
		"bin",       // Common output directory for Eclipse
		"dist",      // Common output directory for NetBeans
		"build",     // Common output directory for NetBeans
		"nbproject", // Common output directory for NetBeans
		"target",    // Common output directory for Maven
	};

	public static void main (final String[] args)
	{
		if (args.length > 3 ||
				(args.length > 0 && ("-?".equals(args[0]) || "-help".equals(args[1]))))
			help();
		
		final File root = new File(args.length < 1 ? "." : args[0]);
		
		if (args.length >= 2) try
		{
			spacesPerTab = Integer.parseInt(args[1]);
		}
		catch (NumberFormatException e)
		{
			help();
		}
		
		final ArrayList includeList = new ArrayList(); 
		final ArrayList excludeList = new ArrayList(); 

		for (int i = 2; i < args.length; ++i)
		{
			if (args[i].startsWith("+"))
				includeList.add(Pattern.compile(args[i].substring(1)));
			else if (args[i].startsWith("-"))
				excludeList.add(Pattern.compile(args[i].substring(1)));
			else
				help();
		}
		
		if (includeList.isEmpty()) for (final String p: defaultIncludes)
			includeList.add(Pattern.compile(p));
		
		if (excludeList.isEmpty()) for (final String p: defaultExcludes)
			excludeList.add(Pattern.compile(p));

		final int count = fixDirectory(root,
			includeList.toArray(new Pattern[includeList.size()]),
			excludeList.toArray(new Pattern[excludeList.size()]));
		System.out.println("Fixed: " + count);
	}
	
	private static void help ()
	{
		System.out.println(
			"FixTabs [root [spacesPerTab [+includePattern*] [-excludePattern*]]]\n" +
			"Ex.: FixTabs . 4 +.*\\.java +.*\\.properties -CVS");
	}

	/**
	 * Processes a directory recursively.
	 */
	private static int fixDirectory (final File dir, final Pattern[] includeFiles,
		final Pattern[] excludeDirs)
	{
		System.out.print(dir.getAbsolutePath() + " ... ");
		final File[] files = dir.listFiles();
		if (files == null) return 0;
		int count = 0;
		int changed = 0;
		
		for (int i = 0; i < files.length; ++i)
		{
			final File file = files[i];
			
			if (file.canRead() && file.canWrite() && !file.isHidden() &&
					matchesAny(includeFiles, file.getAbsolutePath()))
			{
				if (fixFile(file)) ++changed;
				++count;
			}
		}
		
		System.out.println(Integer.toString(changed) + '/' + count);
		
		for (int i = 0; i < files.length; ++i)
		{
			final File file = files[i];
			
			if (file.isDirectory() && !matchesAny(excludeDirs, file.getName()))
				changed += fixDirectory(file, includeFiles, excludeDirs);
		}
		
		return changed;
	}

	/**
	 * Checks a string against a set of patterns; returns true if any pattern matches.
	 */
	private static boolean matchesAny (final Pattern[] patterns, final String s)
	{
		for (Pattern p: patterns)
			if (p.matcher(s).matches())
				return true;
		
		return false;
	}

	/**
	 * Processes a single file.
	 * 
	 * @param file The file to process.
	 * @return true if file was touched; otherwise, it was already okay.
	 */
	private static boolean fixFile (final File file)
	{
		RandomAccessFile raf = null;
		
		try
		{
			raf = new RandomAccessFile(file, "rw");
			final byte[] originalData = new byte[(int)raf.length()];
			raf.readFully(originalData);
			final byte[] fixedData = fix(originalData);
			if (fixedData == null) return false;
			raf.seek(0);
			raf.write(fixedData);
			raf.setLength(fixedData.length);
			raf.close();
			return true;
		}
		catch (IOException e)
		{
			System.err.println(e);
			return false;
		}
		finally
		{
			if (raf != null) try { raf.close(); } catch (IOException e) {}
		}
	}

	/**
	 * Fixes tabs & spaces, if needed.
	 * 
	 * @param data Original data in ASCII format (1 byte = 1 char).
	 * @return Fixed data, or null if no fix was necessary.
	 */
	private static byte[] fix (final byte[] data)
	{
		baos.reset();
		boolean changed = false;
		boolean indenting = true;
		int position = 0;
		
		for (int read = 0; read < data.length; ++read)
		{
			final byte c = data[read];
			
			if (c == '\n')
			{
				indenting = true;
				position = 0;
				baos.write(c);
			}
			else if (c == '\r')
				baos.write(c);
			else if (indenting)
			{
				if (c == ' ')
				{
					if (++position % spacesPerTab == 0)
					{
						changed = true;
						baos.write('\t');
					}
				}
				else if (c == '\t')
				{
					baos.write(c);
					position += (spacesPerTab - position % spacesPerTab);
				}
				else
				{
					for (int i = 0; i < position % spacesPerTab; ++i)
						baos.write(' ');
					
					baos.write(c);
					indenting = false;
					++position;
				}
			}
			else
			{
				if (c == '\t')
				{
					changed = true;
					
					do
					{
						baos.write(' ');
					}
					while (++position % spacesPerTab != 0);
				}
				else
				{
					baos.write(c);
					++position;
				}
			}
		}
		
		if (indenting) for (int i = 0; i < position % spacesPerTab; ++i)
			baos.write(' ');

		return changed ? baos.toByteArray() : null;
	}
}

I particularly like fix 6523674: Allow different styles of java object fields allocation. This improvement makes HotSpot smarter about laying out the fields of objects with inheritance. Elaborating further on the bugtrack commnents, say you have "class A { int x; byte y; }" and "class B extends A { short z; }". Up to 6.0u1, HotSpot would generate the following layouts (ignoring the object header, and assuming 32-bit platform / 4-byte alignment):

class A:
--------
0-3:   x
4:     y
5-7:   (padding:3)

class B:
--------
0-3:   x
4:     y
5-7:   (padding:3)
8-9:   z
10-11: (padding:2)

The new release is better, it uses free space in the superclass layout when possible (e.g. when the derived class has small fields that fit in some "inherited" padding slot):

class B:
--------
0-3:   x
4:     y
5:     (padding:1)
6-7:   z

In the example, notice that "z" is a 16-bit field so it only needs to be aligned on a 16-bit boundary. Final result, instances of "B" will be 4 bytes smaller in the new JVM, which makes everything better (allocation/construction time, GC overhead, CPU cache efficiency, locality, etc.). This optimization should be more effective for code with deep inheritance hierarchies, and even better for 64-bit platforms that require 64-bit references and bigger alignment; for example, "class C { Object o; int i; }" results (again ignoring the header) in a packed 8-byte object for 32 bits, but under a 64-bit JVM it expands to a 16-byte object with 4 bytes of padding after "i" (since "int" is always 32-bit regardless of the JVM), so this padding can now be used for small fields of subclasses - and under a 64-bit JVM, most types become "small" (compared to alignment): everything except references, longs and doubles. In short, if you have a big server app that keeps tons of complex objects in memory (e.g. caches of persistent entities), you may observe some significant improvement with this update. Tell me if you find anything.

Other major change is the new packaging of Java DB (née Derby), which is now installed on a separate directory. I like this much better. But the installer created the full "db" directory tree under the JDK installation dir, just without any files - anyone confirm this as a bug? And while I'm at this, Java DB's BAT files for Windows stink. Please give me proper native launchers, just like for all JDK tools. Get rid of those pesky frameworks/VeryLongAndMixedCaseName/bin directories also, I always hated that in Derby, why can't you have a single /bin? And why is full documentation included for Java DB but not for the JDK (I'm not claiming that the docs should be bundled or not -- just that it should be consistent). Java DB is still badly integrated into the JDK, please make it look more like an extension of the JDK and not as some alien project that was just zipped into the JDK installation bundle. Yeah I know Sun has already made the most critical integration work, like testing/validating each release. But they must walk this extra mile to deliver a better developer experience.

Higher in my with list, however, is: please update the installer so the installation of the Java update checker is optional. I hate it, as well as ANY software that (without my explicit consent) installs any kind of preloader, auto-updater, monitor, and other crap that just sucks RAM and "phones home" periodically. This stuff should all be either off by default, or allow the user to switch off in the installer and not after the fact after digging in some configuration tool.

Now, how STUPID is that? Because of this explicit GC call, performed repeatedly by EVERY SINGLE BEAN, the JVM would freeze with 100% CPU usage for several minutes, when the application server decided to clean up its cache, removing hundreds of expired entity beans.

The problem apparently happened only on a setup using JBoss 4.2.0 and Sun JDK 1.5.0_09 but not in another with JBoss 4.0.2 and Sun JDK 1.5.0_11, both with similar (JBoss's factory-standard) JVM settings. It's possible that the JDK contributed to the problem. A forced full-GC shouldn't take a lot of time in a JVM that's mostly idle except for a simple cache reaper, and with 120Mb of used heap out of 512Mb. It was taking 1 full second per GC. I guess the long GC time could have been caused by some of the several GC bugs fixed by JDK 1.5.0_10, but I didn't investigate further. I told the client to add -XX:+DisableExplicitGC to the server launching script.

It's been several years now that there is NO reason to invoke System.gc() in Java VMs in normal code, only in very special cases (e.g., I do it a lot in microbenchmarks because I want to start each test cycle with the heap in a similar state). Even management/cleanup features in the core of application servers shouldn't do it (one never knows when a burst of client requests may arrive), let alone application code. Thumbs down to JBoss for not disabling explicit GC by default; and two thumbs down to the J2EE / Java EE specs for not forbidding it in app code, at least I didn't find such rule in the specs.

Now, how many thumbs down for Intersystems? I'll have to unwear my shoes and I'll be missing a few thumbs still. This mistake is typical of a Java rookie (and a bad one), it's embarrassing in a product of a respected software company. Your Studio doesn't seem to offer an option to disable generation of the System.gc() calls; I don't know the product and perhaps there is a way, but this "feature" should not exist even as an optional / non-default choice. Just find whoever did this, and fire the idiot. I considered writing this blog in politically correct mode, i.e. "in a certain OODBMS's EJB support..." but I decided to be more explicit because all Caché customers should be warned about this issue, even if it's just potential issue, limited to some JVM builds only. (The JVM has no obligation to respond fast to dumb explicit GC calls, even when a boatload of free space exists; the fact that it happens most of the time, in most JVMs under common configurations, is just a bonus.)

One last remark: diagnosing this bug was a piece of cake thanks to the JDK's jstat and jstack tools. The RAS facilities of the JVM often saves my day, it's a top item in my list of "why I use Java instead of X, Y or Z".

One of the fixed perf bugs is Bug 4803284: Bad performance when HotSpot cannot optimize polymorphic calls, which I reported in January 2003 against JDK 1.4.1. That bug received a partial fix with Tiger-b28, when Sun promised the full solution "in next major release" (Mustang), splitting this to Bug 5074577. There's also a dupe, Bug 4898726: Nonstatic method calls take lot more time than static method calls. Well, it seems Sun kept the promise and these bugs are all fully solved now!

I obviously had to re-run my MethodBench (included in the bug report) to see if the new fix did any difference (as the partial fix already made me happy). And it does, only for HotSpot Server:

JDK 5.0 Update 7:

D:\Java\Bench\Method>java -server -Xbatch MethodHard
*** Testing (Hard) ***
Interf  TPoly   Poly    Virtual Final   Static  Native
35,530  25,682  01,155  01,155  01,146  01,138  259,300

JDK 5.0 Update 8:

D:\Java\Bench\Method>java -server -Xbatch MethodHard
*** Testing (Hard) ***
Interf  TPoly   Poly    Virtual Final   Static  Native
14,754  23,599  01,134  01,130  01,134  01,134  254,700

JDK 6.0 build 94:

D:\Java\Bench\Method>java -server -Xbatch MethodHard
*** Testing (Hard) ***
Interf  TPoly   Poly    Virtual Final   Static  Native
13,711  25,318  01,142  01,146  01,146  01,155  67,980

(The Reflection test is very slow in the "Hard" case, and I'm in a hurry now.)

The improvement is in the Interf test (interface calls), where both 5.0u8 and Mustang beat u7 in 14ns vs. 35ns per call. Other tests show only marginal improvements. Well, in a world full of complex frameworks abusing of interfaces, this optimization may be significant. And this is for a "hard" test where the compiler cannot infer a single concrete type (devirtualization). See the relevant benchmark code:

public void bench ()
{
	int calls = operations / 1000;
	// Note: HelperB and HelperD are unrelated classes (don't inherit each other),
	// but both implement the polyHardF() method defined by HelperInterface.
	HelperInterface helper = null, h1 = new HelperB(), h2 = new HelperD();

	for (int i = 0; i < 1000; ++i)
	{
		switch (i / 500)
		{
		// Here, I periodically reassign the helper variable to either HelperB or HelperD,
		// making the call-site below really polymorphic, which kills easy dataflow-based
		// dervirtualization.  Notice also that 50% of all calls will go to each class,
		// so profiling won't let the JIT decide to optimize one case (e.g. helperB) in
		// detriment of the other with a type-check + inlining only for the hot case.
		case 0: helper = h1; break;
		case 1: helper = h2; break;
		}

		for (int j = 0; j < calls; ++j)
			// This is the polymorphic, interface-based, call-site to optimize.
			// The invoked methods perform a trivial operation, but one that
			// cannot be optimized out (it updates a static variable).
			helper.polyHardF(i);
	}
}

From the bugtrack comments, it seems that this fix is not specific to interface calls. It's only an artifact of my benchmark that the limitation of the optimizer was only caught in the MethodHard/Interf test. But since interface-based calls are by far the hardest ones to optimize (due to multiple inheritance), this is good news for complex OO code overall.

How does HotSpot compile this code, in 5.0u8 and Mustang? I looked at the code (using Mustang's debug build and -XX:+PrintOptoAssembly) and saw that it actually inlines both HelperB's and HelperD's implementations of polyHardF(). It's a strong demonstration of several optimizations combined: the compiler must determine that there are only two possible concrete types for the call-site, and that both deserve inlining... and there's more - let's check the code:

# Start of the inner loop: int j = 0...

0d8   B12: #    B13 <- B11  Freq: 15356
0d8     XOR    EBP,EBP
0da

# ...Loop body...

0da   B13: #    B29 B14 <- B12 B18      Loop: B13-B18 stride: not constant  Freq: 30715
0da     MOV    ECX,[ESP + #12]
0de     MOV    EBX,[ECX + #4]
0e1     NullCheck ECX
0e1

# The "payload" code for the inlined methods is here, because both
# implementations of testHardF() are identical = { ++x; } where x is a static int
# (and it's the same x, in a shared superclass).  HotSpot was smart enough to
# merge part of the common code (the read and the increment) and move it up.

0e1   B14: #    B16 B15 <- B13  Freq: 30715
0e1     MOV    ECX,#344
0e6     MOV    EDI,[ECX + precise klass Helper: 0x00a3e2a8:Constant:exact *]
0ec     ADD    EDI,[ESP + #16]

# Guard code: helper instanceof HelperB?

0f0     CMPu   EBX,precise klass HelperB: 0x00a3c3d0:Constant:exact *
0f6     Jne,us B16  P=0.266667 C=-1.000000
0f6

# Inlined code for (the rest of) HelperB.testHardF().

# I don't understand completely the need for this code, but I guess HotSpot
# wants to keep track of stack frames, and/or produce a trap if there is some
# change in the class hierarchy that invalidates the inlining.

0f8   B15: #    B18 <- B14  Freq: 22524.3
0f8     MOV    ECX,[ESP + #12]
0fc     #checkcastPP of ECX
0fc     MOV    [ESP + #12],ECX
100     MOV    EBX,#344

# Here the new value for x is stored -- the read and increment were moved up
# for sharing, but the write must be performed in the right place (I think)
# to not produce illegal behaviors: e.g., if helper is neither HelperB nor HelperD,
# quite possible if it is null (the benchmark code makes difficult to prove the
# never-null property of helper), then a NullPointerException should be raised
# and x should not be updated due to out-of-order code.

105     MOV    [EBX + precise klass Helper: 0x00a3e2a8:Constant:exact *],EDI
10b     JMP,s  B18

# Guard code: helper instanceof HelperD?

10b
10d   B16: #    B26 B17 <- B14  Freq: 8190.66
10d     CMPu   EBX,precise klass HelperD: 0x00a3c438:Constant:exact *
113     Jne,us B26  P=0.000001 C=-1.000000
113

# Inlined code for (the rest of) HelperD.testHardF().
# Same stuff as before.  It's sad that, both methods being exactly identical,
# HotSpot inlines and merges only part of their bodies, but doesn't do it
# neither for this bookkeeping code nor for the store.  Quite likely HS doesn't
# want that, so it doesn't lose the ability to walk stacks precisely, in events
# like GC, OSR, and exception stack-trace filling (don't you hate JVMs that don't
# report exact line numbers for all frames, in compiled code?).

115   B17: #    B18 <- B16  Freq: 8190.65
115     MOV    ECX,[ESP + #12]
119     #checkcastPP of ECX
119     MOV    [ESP + #12],ECX
11d     MOV    EBX,#344
122     MOV    [EBX + precise klass Helper: 0x00a3e2a8:Constant:exact *],EDI
122

# ...End of the inner loop: ++j; go back if j < calls

128   B18: #    B13 B19 <- B15 B17 B27  Freq: 30715
128     INC    EBP
129     CMP    EBP,[ESP + #0]
12c     Jlt,s  B13  P=0.999935 C=15360.000000

That's it. But just so you don't think the optimizer is now perfect, it could be even better, if HS could combine the switch statement with versioning of the inner loop, so the overhead of testing helper's concrete type and branching to the correct inlined code would be reduced to 1/500th, like this:

switch (i / 500)
{
case 0:
	helper = h1;
	for (int j = 0; j < calls; ++j)
		helper.polyHardF(i);
	break;
case 1:
	helper = h2;
	for (int j = 0; j < calls; ++j)
		helper.polyHardF(i);
}

This transformation would even dispense the complex optimizations we just saw, because in the new code, there are two call-sites that are trivially identified as non-polymorphic, so the compiler is free to inline with zero overhead, and also do other tricks like replacing the entire loop by "x += 500", thus delivering a >500X boost (in this case, my microbenchmark would be declared "broken" as such code pattern hardly occurs in real app code). But the above optimization is really, really difficult; there is no optimizer (for Java at least) that can do it. Which allows me to conclude with two of my favorite clichés:
a) There's room for the next major release to be even faster.
b) Human Assembly hackers (with enough time in their hands) will always win.

Enjoy the new JDK's performance. I haven't yet tried it on real-world application benchmarks, but there are other important perf bugfixes, like Bug 6298694: bad performance with big object in heap, probably much more important than my "pet bug" discussed here, because the latter can screw up with concurrent GC performance.

There are other Java programs and libraries that rely on native libs, but this is indeed very rare in such "standard" components like Tomcat, that is not published by Sun and the JCP but it's very close to such official status. Tomcat is the RI for the Servlets and JSP JSRs, and it's the Web container inside Sun's J2EE server, as well as JBoss and others. Because Tomcat is so popular -- I don't know any numbers, but I guess it should be the #1 Java Web container either directly or indirectly as piece of larger J2EE products -- this native-code support will eventually propagate to the other servers, products and apps that rely on Tomcat.

And of course, there is also Grizzly, presented in JavaOne 2005; this is an effort to optimize Tomcat with java.nio, part of Sun's GlassFish project. I wonder whether Grizzly and Tomcat's native connector (which also uses java.nio) are competing or complementary projects? In either case, none of these projects have yet reached production quality, so we'll have to wait for serious benchmarking.

The Java VM technology is wonderful, it can very often compensate the overheads imposed by Java's high-level design and beat native compilers, thanks to the opportunities of dynamic optimizations. But there are a few areas where native code is still better, like strong interaction with the OS (e.g. for front-end TCP/IP handling), and "extreme" algorithms like encryption that depend on such tricks as manual vectorization/SIMD (very often you gotta get down to Assembly, because not even stock C compilers are good enough on these). Now that java.nio and DirectBuffers solved most of the Java/native overhead issues, the biggest reasons to not use more native code are portability and robustness. But if you're not writing new libs, just using stuff like the APR that's already mature and multiplatform, I think there's no conflict with the "Run Everywhere" tenet.

• Very popular. Most developers know it already. Billions of browsers out there support it.
• Mature and stable for several years (although it's apparently evolving again).
• Formally standardized by multiple ECMA specs.
• Familiar to Java programmers, with virtually the same syntax.
• Very small. Its runtime adds 660Kb (uncompressed) to Mustang.

But that was ten years ago, when free / open-source software (FOSS) was also warming up. For example, Eric Raymond’s TCATB would appear only 1+ year later  (May ‘97), and it was visionary at that time. Today, Java is huge, the top business app development platform. Meanwhile, FOSS increased in importance, volume and mindshare by orders of magnitude, and it has also become serious business.

Unfortunately, Java is increasingly seen as a problem in the POV of FOSS users and developers. This is despite many significant improvements in openness since ‘96:

Full source code is available, including Sun’s crown jewels like HotSpot.

The first SCSL releases used to be made available several months late, and updated only for major releases, so only licensees who pay a big fee had full access to up-to-date sources. But now with the Mustang projects, the public sources are updated weekly, so anybody can track its development as closely as for any traditional open source project.

The JCP is an effective forum to drive Java standards in an open way.

It’s less open than projects driven by public forums and more relaxed steering committees (no fees for influential positions, no strong dependency on proprietary software vendors, pure meritocracy, etc.). But every model has its tradeoffs, and not everybody is convinced that a “Pure Open” model would scale to the technical and business realities of J2SE.

The relationship between Sun, the JCP, and other commercial backers of Java, and the FOSS community, is very strong.

The latest version of the JCP’s process (JCP 2.6) certifies that open source groups can implement any JSR, and makes the JSR works more transparent for outsiders. The major Java vendors have strong participation in FOSS projects like those from Apache and Eclipse, not to mention others not directly related to Java, like Linux or OpenSolaris. In fact many JSRs have their Reference Implementations delegated to FOSS projects, historically under the umbrella of Apache Jakarta and more recently in java.net.

Java was always a great player with open standards in general.

Many non-Java developers have the impression that we like to reinvent the wheel, creating our own incarnations of everything. The truth is that we just create new implementations of everything. For example, a Java webserver like Tomcat doesn’t reinvent any wheel or break any standard: it strictly adheres to relevant standards, like HTTP. Somebody could ask why don’t we simply use (and contribute to) an existing free httpd, adding new modules for Java-specific technologies like JSP. But the reason for not doing this is not just the WORA mission. The full vertical integration of the software stack, possible when everything is written in Java and optimized for Java, is advantageous in many fronts, from performance to ease of development and extensibility. The major reasons why other people don’t do the same are that their languages don’t have sufficient performance for systems / middleware programming, or their communities are not big enough to support such projects.

Having said that, Java is not yet true Open Source or true Free Software. Sun’s licenses, SCSL and JRL, don’t grant all rights required by the FOSS communities (Bruno Souza explains this in detail). Sun says they want to avoid a proliferation of dialects of the platform. You may think this is very unlikely because few people will be interested in making changes to the Java language or creating new core APIs. But these are not the only sources of ‘dialectization’. You just have to introduce a new bug, one that would create a JCK failure, and the damage is done: it’s not Java anymore.

How justified is this argument? We can answer this by checking current FOSS Java projects, like Classpath, GCJ and Kaffe. These projects do a pretty good job in respecting Java standards. They don’t add any new public APIs, and their compatibility issues are related to insufficient resources to catch up with the proprietary implementations and to lack of access to the JCK under acceptable terms (this is just fixed with J2SE 5.0). So the community has even started its own free replacement for the JCK, Mauve – a strong evidence of the commitment of the FOSS developers to Java compliance. (But I would be too forgiving to ignore GCJ’s CNI, a proprietary native interface that competes with JNI, and has no reason to exist, except for the immaturity of GCJ. Microsoft also did have good technical excuses for the extensions they created long ago. Dear GCJ developers, please kill this bastard; CNI gives reason to all the paranoids that think opening Java is killing its WORA.)

Java has become too important to be ignored even by those old-school FOSS developers who still love lower-level tools like C. FSF leader Richard Stallman’s Java Trap paper puts this in good perspective. RMS doesn’t seem to be a big fan of Java (“people who write free software often feel Java is sexy…”), but he admits that just not using Java is not an option. The world is now full of Java code and Java programmers, and the only viable solution is having a Free Java implementation. This debate is getting hotter by the day. We recently saw the FSF complaining about the growing use of Java in OpenOffice. I think that if this community didn’t have resources to compete alone in this field, they should be happy that Sun has made OO possible. Of course Sun will put Java wherever it’s a good fit. I was amused by the FSF’s initial reaction, hinting towards a fork of OO to drop, or re-implement in other languages, the pieces that use Java. This is IMHO something that should not happen in a healthy FOSS community – and those who value the Free Software ideology over features could easily pick other choices. Fortunately, it seems that the FSF is going to do the right thing: tweak OO and/or improve GCJ until they work together, so OpenOffice 2.0 offers a 100% Free build for those who care. I am one of those who won’t use that (when OO2 goes FCS, I will certainly run it atop any JVM that deliver the best stability  and performance) so I don’t like the additional delay imposed by this solution. But looking from the Forest view, I think it’s a good thing: OO is not the only software that will benefit from improved Free Java implementations, and these improvements may increase the popularity of Java with Free software users. After all, there is a whole boatload of high-quality Free Java software out there. Any effort spent in converting Java to C for specific apps, even important ones like OO, is wasted effort, in perspective.

The other big news is Apache’s newly-incubated Harmony. Everybody is blogging over Harmony, so I will try to add some new thoughts. Harmony intends to build a complete, compliant J2SE implementation, which is a step forward compared to VM- or library-only projects. They are talking to the FSF over Classpath, because without reusing that, the project is not viable, as the J2SE APIs are too big and fast-moving. I’m very curious about the reaction of some players, like IBM, who has been pushing Sun publicly towards open-sourcing Java. Well, IBM owns at least two completely clean-room, production-quality JVMs (IBM JDK and J9), and it seems they have reimplemented large chunks of the APIs too, especially the most difficult ones like CORBA and Security. AFAIK they can open these sources without breaking contract with Sun. And it’s not just IBM; BEA has also became a competitive player recently with JRockit, and Apple, while not in the clean-room team, has made many significant improvements to HotSpot and APIs like Swing.

But I don’t think this is a simple case of cheap talk. It’s more likely a case of “we’re not giving away our competitive advantage, at least not alone”. For major Java players, having their own proprietary JVM is strategic: to have control over its implementation (e.g. to fix bugs that are important to their own customers), add optimizations for your hardware or application server and vice-versa. This is also the reason why just pledging Sun to unilaterally opensource Java has little chance to work. These companies will not open the code for their Java technology before they sit together and find a common solution, one that doesn’t risk anybody’s business plans. (And Sun must be part of the solution, because nobody else has complete clean-room APIs.) Perhaps the best alternative is endorsing a new, independent Free Java project like Harmony, as those big companies know that such project, even with significant resources, will take several years to start competing with proprietary JVMs, if not in compliance certainly in performance. Then Sun, IBM, BEA and others can play nice, even donating resources and developer time to Harmony, while still boasting their superior proprietary implementations whenever it’s good for business. Some day, a great J2SE implementation will be a commodity, but this day is not today. And if you ask me, there’s nothing wrong with this strategy.

Should a full, top-notch J2SE implementation go Free today, we wouldn’t need Harmony, but then we might worry about potential “misuse” of these sources. The risk of forking has been discussed to death and I don’t think it’s big: the Java community has a strong culture of following its standards, and the current status of Free implementations that are not compliant because they can’t is worse than any purposeful forking. A second possibility is that Java code could be useful for competing platforms. This risk is significant, as .NET is a strong competitor that’s also similar enough to Java to allow easy porting. I don’t think Microsoft would do that, but I wonder about FOSS .NET projects, like Mono or DotGNU. These projects are way behind the proprietary VMs (either Java or .NET); and their developers obviously like .NET better than Java, or perhaps for DotGNU, value their Free agenda more than any of the competing platforms. There are VM projects like RMTk, and library projects like NUnit, providing evidence that Java code can be used to accelerate the production of similar .NET software. Not to mention “hybrid” solutions like IKVM, that allows running unchanged Java code on .NET runtimes. Even if the Java code is eventually replaced by new code, written from scratch to better explore .NET’s style and frameworks, the Java code is very useful for prototyping and to make initial versions available quickly. In an ideal world, both communities could benefit from each other’s work, but in practice, the numbers of Java are still vastly superior to .NET’s, so we’re just giving away and not receiving anything back. Companies with a large investment in Java might worry about giving away technology to the competition. They could use viral licenses like the GPL or CDDL, so the Java code cannot be used in proprietary .NET products that are their main competition, but this won’t prevent that code to foster the opensource .NET offerings. But in the bright side (and now I’m dropping my Java-advocate hat to say this), the migration of code from Java to NET, and eventually vice-versa, is interesting from the interoperability point of view, as we tend to have more compatibility between software of both worlds.

The whole debate is even more interesting when we inspect Sun Microsystem’s overall behavior towards open source. We have to commend Sun not only for past glory like NFS, but for very important, high-profile open source efforts like OpenOffice, NetBeans and OpenSolaris. The latter, btw, is supposed to deliver the promised source code by mid-June. (Solaris X will be very appealing to advanced Java developers as soon as DTrace supports Java.) And the weirdest thing is that in these other opensource efforts, Sun doesn’t have any problem with real FOSS licenses. In OpenSolaris, Sun even adopted a “viral”, MPL-like license, perhaps with the same logic of not helping competitors with proprietary OSes, or even Free ones. And while some people inside Sun are very vocal in favor of open source, James Gosling is not, saying that many customers would “freak.. screaming to the hills” over the prospect of opensourcing Java. I admire James for his brave words, in a time when being anti-opensource is almost politically incorrect – I’m just waiting for the Free zealots comparing JG to Bill Gates due to this quote. I would certainly “freak out” if Sun just opened CVS access to the J2SE project so anybody could check code in. But no serious opensource project works that way, they have layers of leadership and code reviewers to validate contributions; and James knows it, and this didn’t stop Sun from opening Solaris. Check the OpenSolaris roadmap for this, they have planned a process to make external contributions possible without wrecking the quality of the Solaris product. In the Mustang project, even at this stage (without full opensourcing), Sun has also put together the basic process and infra-structure for contributions. I say “basic” because they won’t have a significant volume of contribution before they have a FOSS license, but it’s a solid step towards full opensourcing if this ever happens. Now, with respect to freaking customers, Sun should do some customer education before they opensource Java, just like (I guess) they have/will do for Solaris. It’s just a matter of making clear that the huge engineering and QA effort that was put into J2SE will not be compromised. This implies that, if Sun opensources their implementation of J2SE, they should do that in a way that keeps enough control so they can enforce their standards and vision. Look no further than Eclipse, which organization and process was recently criticized for being less open than other FOSS projects… well, as a satisfied user of Eclipse, I think its governance is ideal like it is, and it seems that OpenSolaris won’t deviate much from that model: Sun will obviously keep a very strong leading position... anyway, Free Java is probably not going to happen that way.

So, what about Harmony? It’s an excellent move from the Free community, probably the best (or only) viable way to produce a Free implementation of J2SE, and then increase even further the penetration of the Java platform. Now, if they have as much success as I wish, and in a few years we have a complete, high-performance Free Java, then we will have real answers to the big questions posed here: whether a “pure” FOSS project can deal with something as complex as a production-quality J2SE platform, and whether any of the FUD against Free Java is justified.