Installing Java on Ubuntu Lucid or Maverick

Sun Java 6 is missing from a standard Ubuntu Lucid or Ubuntu Maverick installation, as well as missing from all of the APT repositories that come prepackaged with Ubuntu – including metaverse, universe, or any other.

Apparently, with the release of Ubuntu 10.04 Sun Java moved to the Canonical Partner repository. This means that to get Sun Java, you have to add the Canonical Partner repository to your list of APT repositories:

sudo add-apt-repository "deb lucid partner"

If using Maverick, then replace “lucid” with “maverick”:

sudo add-apt-repository "deb maverick partner"

Then update your APT cache and install:

sudo apt-get update
sudo apt-get install sun-java6-jre sun-java6-plugin

Once this is done, Sun Java is installed. However, Sun Java is not set as the default Java to use. To make this change, use update-alternatives:

sudo update-alternatives --config java

With the appropriate selections, this should configure Sun Java as the default Java for applications to use. Browsers will have to be restarted to activate the new Java plugin.

Oracle Sues Google Over Java on Android

Oracle – now having purchased Sun – has sued Google over their custom Java virtual machine for the Android mobile platform. In doing so, Oracle has sent reverberations throughout the open source and Java communities.

Google took the Java APIs and enhanced and changed them – then created a virtual machine (called Dalvik) which runs a custom format executable. This was part of the Android software when it was introduced in November 2007, and there were many complaints about Google’s treatment of Java – including complaints from Sun itself. Google’s response at the time to Sun’s complaints was:

Google and the other members of the Open Handset Alliance are working to help solve fragmentation and supporting the developer community by creating Android, a mobile platform that responds to the needs of the developers, has the backing of industry leaders, and will be available as open source under a nonrestrictive license.

To break that statement down, Google was saying:

  • The Open Handset Alliance (not the Java Community Process or JCP) should be the Java stewards for mobile Java.
  • Android (and Android Java) responds to the needs of the developers.
  • Android is backed by industry.
  • Android is available as open source.
  • Android is available under a nonrestrictive license.
  • Java 2 Mobile Edition (J2ME) has none of these capabilities.

Don’t miss the fact that Google created the Open Handset Alliance at the same time, and serves mainly as a source for Android – though it has in recent days been seen as useless by some.

Sun (now Oracle) has had a mobile version of Java (known as J2ME) since before Android existed – but Google bypassed it (and the Java Community Process or JCP) when it created its own JVM. Dalvik executables, in fact, are created from Java binaries, thus involving Java itself in the process of creation and development.

It appears that Google’s Android Java implementation was a direct attack on the JCP and on J2ME. To use J2ME, Google would have had to license it, as it was not available under a license that would have allowed commercial closed-source development: it was under the GPL, but without the classpath exemption that the J2SE had. Because of this lack of the classpath exemption, any development on the standard J2ME platform would have to be released as source code under the GPL.

This action by Oracle fits perfectly into its public persona: consider that Sun’s Chief Open-Source Officer, Simon Phipps, was not even offered a position at Oracle at all. He is or was on the advisory boards for OpenSolaris, OpenJDK, and OpenSparc. Other distinguished Sun engineers have left, including Kohsuke Kawaguchi (chief developer of Hudson), Charles Nutter and Thomas Enobo (both lead developers of JRuby), Tim Bray (Director of Web Technologies – which includes Java and JRuby), and James Gosling (creator of Java). It is notable that all of these people except Simon Phipps are luminaries in the Java realm at Sun. It is as if the Java engineers left wholesale once Oracle was about to take over.

Coverage of the lawsuit has been extensive. Stephen Shankland over at CNet has a story about why Oracle may have chosen to sue. Stephen O’Grady over at RedMonk may have one of the best in-depth analyses of this conflict out there. Groklaw has committed to following the lawsuit through the courts, and has an excellent introductory piece on the lawsuit. Steven Vaughn-Nichols suggests that this lawsuit is only the beginning, and that JBoss, Apache Jakarta, and the JCP better watch out (though I disagree).

From when Google introduced Android and its associated virtual machine, Dalvik, Stefano Mazzochi had one of the most complete explanations of what Google was doing and its implications.

Getting Java Working in Chromium in Ubuntu Lucid Lynx

I recently found myself needing to have the Java plug-in working on Ubuntu. I had been using Google Chrome, and thought that installing Chromium from the standard repositories would fix it – not so.

After some research, I found this article about getting Java working on Ubuntu 9.04 with Chromium. Strangely (or perhaps not) things have not changed in Ubuntu 10.04.

The simple description is the following:

  1. Find libnpjp2
  2. Place a copy of libnpjp2 in Chromium’s plugins directory: /usr/lib/chromium-browser/plugins
  3. Make sure that libjavaplugin* is removed from the plugins directory.
  4. Restart Chromium if necessary.

In the case of Ubuntu 10.04, I found libnpjp2 to be part of Sun’s JRE (and in the sun-java6-bin package):

dgd@cor$ dpkg -S $(locate libnpjp2)
sun-java6-bin: /usr/lib/jvm/java-6-sun-

You can test the results by going to Sun’s Test Page.

Looking at Ubuntu’s bug lists, this bug is related to getting IcedTea Java plugins working. The Google Chromium folks noticed this as well in a bug report of their own.

The problems with IcedTea are related to the fact that the plugin is either in a unsupported plugin format, or more recently, linked against libraries that are not found when running Google Chromium.

Sun’s JDK with works just fine; I’ll stick with that.

Apache Tomcat 7 Released

Apache Tomcat 7 was just recently announced – or more specifically, Tomcat 7.0.0.

Apache Tomcat 7 is the first release of the 7.x series, and thus the Apache Group does not recommend adopting it for business use yet. The code changes that went into Tomcat 7 are so extensive that they would like to have some real-world (but not production) testing first.

Documentation for Tomcat 7.x is available, and Tomcat 7 has its own dedicated download page as well.

Tomcat 7 is the first version to support Servlet 3.0, JSP 2.2 and Expression Language (EL) 2.2.

Java SE 6 is required to run Tomcat 7, but the JDK is not needed; since Tomcat 5.5, only the JRE is required as Tomcat comes bundled with the Eclipse JDT Java compiler to compile JSPs.

OpenVMS runs Tomcat as part of the Secure Web Server (SWS) product. HP-UX has Tomcat as well as Apache Cocoon (now at version 2.2.0 and with a 3.0 Alpha out). Ubuntu has both Tomcat 5 and Tomcat 6.

I just hope that adoption of Tomcat 7 does not follow the pattern of KDE; KDE 4.0 was roundly taken up by all major KDE platforms in spite of the warnings given by the KDE team. Yet, I expect Tomcat 7 to be more reliable than KDE 4 was.

If you have questions about Tomcat, you could always go to ServerFault and ask away. However, there is also a Tomcat-specific source – Why not try both?

Why Java is the Future for OpenVMS

Support for Java in OpenVMS has increased over the years, and now Java for OpenVMS on Integrity is part of the basic system, and includes Java JDK 6.0 and JRE 6.0.

Installing the Secure Web Server (SWS) – based on Apache – you also get Tomcat and Perl for free.

As long as OpenVMS remains viable, I personally expect both Perl and Java to flourish on this platform. Especially, when not using Perl for typical administration tasks, I expect that Java will be available for more powerful duties.

I would even expect to be able to put things like Stripes, Spring, or even Scala and Lift onto OpenVMS. With the portability of Java, one could potentially just copy over class files, Java archives, or even web application archives and expect things to (mostly) work.

The support for both Perl and Java on OpenVMS makes for an exciting time – and Tomcat to boot.

Share your experiences with Java on OpenVMS…

Tomcat Missing Java Standard Tag Libraries (JSTL) in Debian and Ubuntu

If you load Apache Tomcat onto your Ubuntu system, you’ll find that JSTL is missing. Trying the provided JSTL examples will thus result in failure, as will any normal operations that require the standard tag libraries.

This is mainly because of one reason: JSTL is considered to be part of J2EE – which in this case means that JSTL comes with Glassfish (or by translation, Apache Geronimo).

Originally, JSTL was a “built-in” feature of the Glassfish packages in Debian and Ubuntu; however, because of the desirability of having JSTL in Tomcat and other containers, JSTL is now available separately.

The package is glassfish-javaee and contains three JAR files which contain JSTL. The best thing to do is to run this command (whether Debian or Ubuntu):

apt-get install glassfish-javaee

This will install the packages and all dependencies – though if you’ve Tomcat already, there probably won’t be any dependencies required.

I experienced this with Tomcat 6, but Tomcat 5 is probably affected as well.

Making Scala and NetBeans work under Ubuntu Lucid Lynx

Scala is an object-oriented language designed for the Java Virtual Machine (JVM), and a very interesting language. The inventor of Groovy suggested that Groovy would never have been created if Scala was around at the time, and the inventor of Java named Scala as a language he’d use.

NetBeans is an integrated development environment (IDE) which is particularly suited for Java (and was developed in Java besides).

Getting Scala and NetBeans to work together requires some adaptation; the basic directions are at the NetBeans website. There are, however, some caveats to making this work, especially under Ubuntu.

Install NetBeans from the Ubuntu repositories; this will be version 6.8.

The version of Scala installed by default in Ubuntu (the current stable release, 2.7.7) is not suitable. The current release candidate (2.8.0-RC3) from should be installed instead, and into a single directory – /usr/local/scala is a good location. When done, the directory should contain these directories:

  • bin
  • doc
  • lib
  • man
  • meta
  • misc
  • src

The directory which contains these will be SCALA_HOME. Create a file under /etc/profile.d/scala like so:


Then, add this to the file /etc/netbeans.conf (at the end of the netbeans_default_options):

-J-Dscala.home=/usr/local/scala -J-Xmx1024m

At this point, let’s add the modules to NetBeans to support Scala. Download the archives and unpack them.

Start NetBeans, and select the Tools menu, followed by selecting the Plugins menu item. This brings up a new window. Select the Downloaded tab. Click on the Add files button, and select all of the nbm files that you just unpacked. After they appear in the list (all checked), click on Install.

NetBeans will have to be restarted to complete the process.

To check and make sure that everything works, create a new project and check for a category folder for Scala. Also try selecting the Tools menu, and then Scala Platforms – make sure that the path is /usr/local/scala.

Have fun with NetBeans and Scala!