JavaIntegration

Java in Ubuntu

Goals

  • The default install should be the best Free Software JVM using software only in main.
  • Eclipse should work out of the box.
  • Firefox should have a working Java plugin. Blocking on security manager support.
  • It should be trivial to replace the Free JVM with a non-Free commercial one.

Todo list

  • Check libgcc1 from gcc-4.0 binary compatability against the one in main
  • Package gcc-4.0 source for main
  • Make gcj,gij,libgcj 4.0 the defaults
  • Upload eclipse
  • Default javac compiler to ecj.

  • Write release notes explaining how to get gcjwebplugin, and what the security risks are (No functioning SecurityManager support in this release)

  • Go through other Java packages in Universe to make sure that if they can be compiled with gcj that they are.
  • Consider updating GCC4 mid-February with updates from new java-gui-20050128 branch. This branch is updates with fixes from classpath for more GUI support.

Measuring Best

  • Platform coverage
  • Performance
  • Debuggability
  • Conformance

Choices

Evaluation

Platform Coverage

  • gcj / gij: alpha, amd64, arm, hppa, i386, ia64, m68k, powerpc, s390, sh, sparc
  • kaffe: alpha, amd64, arm, i386, m68k, sparc
  • ikvm: alpha, arm, amd64, i386, powerpc, s390, sparc
  • sablevm: alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc

Performance

http://klomp.org/mark/free-vm-benchmarks/ http://www.klomp.org/mark/free-vm-benchmarks/getallen.html

  • Note: Author of these benchmarks is GNU Classpath maintainer, not associated with any VM directly.
  • gcj: Low overhead. All precompiled, but can load classes through GIJ when required to.
  • gij: Low overhead. Pure interpreter, but can load binary compiled classes. Because it is part of gcj, core classes are all compiled.
  • ikvm:
  • kaffe: JIT Compiler. Quite good.
  • sablevm: State of the art interpreter.

Debuggability

  • gcj: Uses gdb
  • gij: None
  • kaffe: None
  • ikvm: Convert to CIL and use standard .NET / Mono debugging tools.

  • sablevm: Possible with e.g. Eclipse thanks to JVMDI and JDWP support. For now requires manual installation of a debug-enabled snapshot (see: http://sablevm.org/lists/sablevm-announce/2005/000005.html for quickstart instructions), but is expected to be incorporated into the mainline by the end of May.

Conformance

  • All of these JVMs use classpath. ikvm appears to use native floating point sematics, rather than the JVM model.

Recommendation

For performance critical applications, gcj is a clear win. For the rest, I recommend gij. It has the platform support that we need, can use compiled classes if they're available, has a solid release cycle, and an active maintainer team. Because it's based on the same code as gcj, we will always know that we can compile commonly used code and have it just be faster. There is some work going on now to build a JIT mode for gij, but that work has not been committed.

For compiling to bytecode, Eclipse's ecj is a clear win. It is branded and used commercially in a number of products.

Unless there's a clear reason not to, all Java packages should be compiled with gcj and provide both byte code and natively compiled packages.

When SableVM's support for debugging is incorporated into the mainline, it should be easy (automatic? default?) to make Eclipse use it while running and debugging applications.

In Summary:

  • The default Java VM should be gij
  • The default Java compiler should be ecj
  • Java libraries should be compiled to native code using gcj where it works
  • We don't currently have a solid open source option for a browser plugin, but are investigating options to bring gcjwebplugin up to par
  • SableVM should be used where debugging support is desired

Non-Free VMs

There are three logical choices for non-Free VMs to install

  • Blackdown: http://www.blackdown.org/ - amd64 and i586 only (deb ftp://ftp.tux.org/java/debian/ sarge non-free).

  • IBM: (Installer package) - ###FIXME list
  • Sun: (Installer package) - ###FIXME list
  • BEA JRockit ?? as far I can understand from the license you can re-distribute it.

    • Here's the full EULA for JRockit. http://commerce.bea.com/products/weblogicjrockit/50_eula.jsp To sum it up, the terms are almost EXACTLY the same as Sun's JVM, with the exception that JRockit can be redistributed alone, woth other JVMs, or however you wish, as long as you do not modify it (whether medofication of distributed default config files is acceptable or not is unclear). BEA's EULA still has the same indemnification clause, and it's still closed source, meaning we won't be able to provide a PPC binary (they do have AMD64 binaries though).

Debian has a utility, a simple shell script really, called java-package. You run it on a Sun or IBM SDK (powerpc ???) or JRE package, and it produces a .deb file. This utility is not ideal for a number of reasons:

  • It is a CLI utility. Some users may be turned off by this.
  • It's fairly ugly. It's a bunch of shell script. It doesn't generate mime associations for some important things.
  • Adding support for a new SDK or JRE version requires a new upload of the package (this might not be that bad).
  • The user has to go get the JRE from Sun without much of a tutorial about why or how.

An idea has been in my (JerryHaltom) head for awhile on a java-package replacement. It would be a GUI application, druid style. The first pane would describe what's going on. The second would have an embedded browser or some such reference Sun's license agreement and requesting you to comply with it. Afterwards, the download would be done and it would Just Work. If we are unable to automate it to this level, we could have an embedded browser direct the user to java.net, and intercept the actual download and handle it (we can do that, right? sounds like a cool program!)

There are a number of ways we could go about doing the actual installation:

  • The same way java-package does. Generate a .deb and install it in the background.
  • Extract the JRE into a specific custom location, set up alternatives and alter the environment to make it "installed". Register proper mime types and mime associations, etc.
  • Kick off Sun's process (it's really bad).

It would be ideal to generate a .deb package. This would allow the .deb package to be created on one workstation and deployed to a company's internal apt repository for deployment across their own desktops.

Future (Post-Hoary)

Thanks

  • Thanks to the many folks in #classpath (mjw, tromey, man-di, and others!), Jerry Haltom (wasabi), and Matthias Klose (doko).

From CelsoPinto Mon Dec 13 13:09:48 +0000 2004 From: Celso Pinto Date: Mon, 13 Dec 2004 13:09:48 +0000 Subject: Proposal Message-ID: <20041213130948+0000@https://www.ubuntulinux.org>

I'd like to propose a complete Java solution, being a Java developer:

* Simple Java JRE package (e.g. java-jre-sun): similar to msttcorefonts package in that the preinst script downloads the JRE from Sun's site. Has a nice dialog to choose the Java version to download but depends on "hardcoded" download URLs. After downloading, create a Debian package with the downloaded JRE by using a ported and modified version of the java-package Debian utility.

* Java JDK package (e.g. java-jdk-sun): same as Java JRE package, but download the full JDK.

  • Both create a .desktop file in the Internet menu, so that Java Web Start can be easily visible
  • Both create a javawrapper, so that execution of .jar archives can be performed by modifying the binfmt_misc settings on a startup script
  • To download a different Java version, one should use the dpkg-reconfigure utility?

  • Since Ubuntu is GNOME-based, it'd be really nice to modify the swing.properties file to use the GTK L&F by default.

  • Both update the mozilla plugins (if mozilla or derivate is installed)

* Create a package for Eclipse 3.0 (e.g. eclipse-java-ide).

* Create a package for Eclipse plugins, as follows:

  • Visual Editor (eclipse-plugin-visualeditor)
  • Eclipse Modeling Framework (eclipse-plugin-emf)
  • Graphical Editing Framework (eclipse-plugin-gef)
  • etc...

* As i understand, Ubuntu already has some Java libraries available. Check if more need to be added.

* Create a J2EE meta-package (e.g. java-j2ee-platform)which depends on:

  • Jboss package (e.g. jboss-as)
  • Hibernate package (e.g. hibernate)
  • Sun's J2EE libraries

* Create a J2EE Developer meta-package, that depends on:

  • Jboss IDE (e.g. eclipse-plugin-jboss-ide)
  • and suggests java-j2ee-platform

I have a lot of ideas about Java integration, but they all depend on the Java roadmap for Ubuntu.

From ivarvasara Sun Jan 9 19:02:29 +0000 2005 From: ivar vasara Date: Sun, 09 Jan 2005 19:02:29 +0000 Subject: how to help Message-ID: <20050109190229+0000@https://www.ubuntulinux.org>

I'm also competent with Java, and wouldn't mind learning more about package management etc. Is there a place to consolidate and organize Ubuntu/Java development or is this it ?

I posted this on http://www.ubuntuforums.org/showthread.php?p=49604#post49604

"I finally found a way to distribute a fully packaged SUN JRE: i'll need to create a project (which will be known as the Ubuntu-Java project) and I cannot distribute any other competing JVM (like gjc or the GNU classpath).

I reckon this fullfils the goals I'm proposing: to bring the a lot of java tools and java integration to Ubuntu.

This is all pretty, but I have a problem: I cannot create a sourceforge.net project for this because they require the packages to have it's full source available and full source for SUN's JVM, afaik, is a no-no. Therefore, I'll need a mirror to store this, so my question is: does anyone know of someone who might be *really* willing to store the repository?"

Any ideas?

From CelsoPinto Fri Jan 21 00:19:21 +0000 2005 From: Celso Pinto Date: Fri, 21 Jan 2005 00:19:21 +0000 Subject: Message-ID: <20050121001921+0000@https://www.ubuntulinux.org>

Although I agree with the freedom provided by a free jvm, I cannot help but ask: what will you say when a user installs JBoss on a dev machive and tries to run that against a free jvm without any success? Because I don't want to pollute the Ubuntu distribution - which I love as much as I love Debian btw - I'm starting a 3rd-party project of my own that distributes SUN's JVM nicely packaged and ready to install. The objective is to do as little patching as possible on upstream applications (native Eclipse is a no-no), besides providing packages for them.

Anyway, I'll be looking really close to what the Ubuntu developers will do to integrate Java packages in the distribution.

From JerryHaltom Fri Jan 21 22:03:26 +0000 2005 From: Jerry Haltom Date: Fri, 21 Jan 2005 22:03:26 +0000 Subject: Sun's JVM Message-ID: <20050121220326+0000@https://www.ubuntulinux.org>

If you distribute Sun's VM, you must agree to idemnify them in any lawsuits that may arise out of your distribution of that software. Do you agree to this? Debian doesn't, Ubuntu shouldn't. Simple as that. Sorry.

From CelsoPinto Sun Jan 23 01:54:40 +0000 2005 From: Celso Pinto Date: Sun, 23 Jan 2005 01:54:40 +0000 Subject: Sun's JVM Message-ID: <20050123015440+0000@https://www.ubuntulinux.org>

I reckon you're a bit off. You are permitted to redistribute the JVM's with a project but you cannot include any other competing VM (GNU Classpath, IBM's, etc). I believe that is why Debian doesn't redistribute it.

From JerryHaltom Tue Jan 25 16:12:25 +0000 2005 From: Jerry Haltom Date: Tue, 25 Jan 2005 16:12:25 +0000 Subject: Message-ID: <20050125161225+0000@https://www.ubuntulinux.org>

... ms, Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.

Notice (vi). You would also violate (i).

From CelsoPinto Tue Jan 25 17:16:41 +0000 2005 From: Celso Pinto Date: Tue, 25 Jan 2005 17:16:41 +0000 Subject: VM alternatives Message-ID: <20050125171641+0000@www.ubuntulinux.org>

It would have been nice if you even bothered to see the status of the projects you mentioned. Please mind that a JVM that doesn't have 100% compatibility with Sun's JVM isn't a good alternative since you'll have to tackle lots of problems and complaints. Just my 2c.

From JerryHaltom Tue Jan 25 17:33:12 +0000 2005 From: Jerry Haltom Date: Tue, 25 Jan 2005 17:33:12 +0000 Subject: Message-ID: <20050125173312+0000@https://www.ubuntulinux.org>

Well, that's a nice thing to say, but practically, doesn't matter. There are *NO* Free JVM's with 100% compatibility with commercial JVMs and we are NOT ALLOWED to distribute Sun's. Those are our constraints.

From CelsoPinto Tue Jan 25 17:52:46 +0000 2005 From: Celso Pinto Date: Tue, 25 Jan 2005 17:52:46 +0000 Subject: Message-ID: <20050125175246+0000@https://www.ubuntulinux.org>

like I said earlier, I started my own project because I already know that my goals do not meet the constraints of the Ubuntu Linux project, therefore i'm not stepping on anyone's toes (I think). If there aren't any 100% compatible free JVMs, how can you expect to have a good integration with Java? What will you say: "sorry, no Swing/AWT apps but you can run nice services as long as they don't use any swing/awt API's." It's non-sense... we should all put some pressure on Sun instead of playing cat & mouse.

From JeffBailey Tue Jan 25 19:02:48 +0000 2005 From: Jeff Bailey Date: Tue, 25 Jan 2005 19:02:48 +0000 Subject: Swing/AWT Message-ID: <20050125190248+0000@www.ubuntulinux.org>

Swing/AWT isn't a complete show stopper these days:

http://www.ewetel.net/~katrin.salecker/jamvm-gpl.png http://people.redhat.com/graydon/free-swing-jedit-jan-22-2005.png

I'm far more concerned by the lack of a security manager for network facing applications. Classpath 0.13 has the starting pieces needed for this (requires updates on the VM side).

http://brutus.apache.org/gump/kaffe/project_todos.html is probably a better measure of how far Free Java is. This page shows the buildability of the various Apache Java stuff. It's hovering around 25% right now, but you can see that there's two or three top blockers. I'm waiting to see what the picture looks like once those are solved.

From CelsoPinto Tue Jan 25 23:13:52 +0000 2005 From: Celso Pinto Date: Tue, 25 Jan 2005 23:13:52 +0000 Subject: Brainstorming Message-ID: <20050125231352+0000@www.ubuntulinux.org>

Guys, there's a lot of brainstorming going on... should we take this discussion to a mailing list? if so, which one?

From MattZimmerman Wed Jan 26 03:56:04 +0000 2005 From: Matt Zimmerman Date: Wed, 26 Jan 2005 03:56:04 +0000 Subject: Re: Brainstorming Message-ID: <20050126035604+0000@www.ubuntulinux.org>

The place for Ubuntu development discussion is the ubuntu-devel mailing list

From OlafurArason Thu Jan 27 00:53:56 +0000 2005 From: Olafur Arason Date: Thu, 27 Jan 2005 00:53:56 +0000 Subject: Just to fuel the rumors Message-ID: <20050127005356+0000@https://www.ubuntulinux.org>

This point to a possible open-source java. But I think people a least at first will still want sun java. I'm hoping that this is true, because I'm on linux/ppc and the latest version is 1.3 and I haven't gotten that working. http://www.weiqigao.com/blog/2005/01/17/1106011880000.html

From ThomasPerl Thu Mar 31 21:06:50 +0100 2005 From: Thomas Perl Date: Thu, 31 Mar 2005 21:06:50 +0100 Subject: sun jvm Message-ID: <20050331210650+0100@www.ubuntulinux.org>

for me as java developer i think its important to have the sun j2sdk included, because it's simply said the "standard java" one wants to have when he wants to do anything useful. i like the idea of JerryHaltom (java-package like GUI app for downloading and packaging/installing j2sdk) because at the state the open projects are now, a java developer trying out ubuntu will cry out loud for "that crappy java implementation linux has".. i guess these people expect the j2sdk, and if you don't supply just free software java implementations, they will believe sun's j2sdk is not available for linux and go "what a piece of crap - i hate linux/ubuntu".

really, bring j2sdk somehow in here, or if not make some decent "warning" that defaults are to free software, but j2sdk CAN be installed with ubuntu, maybe referring to a package like java-package.

From goofrider Sun Apr 24 03:12:04 +0100 2005 From: goofrider Date: Sun, 24 Apr 2005 03:12:04 +0100 Subject: A Pragmatic Ubuntu Java Packaging Proposal Message-ID: <20050424031204+0100@https://www.ubuntulinux.org>

In Response to The Recommendation section of this original proposal

I think it's kinda premature to debate about a default JVM in Ubuntu, considering that all of the Free JVMs still have compatibility issues to various degrees, let alone proposing distribution of gcj compiled native binaries.

Personally, I think distributing natively compiled binaries kinda missed the point of Java. But what's more important is that while gcj-complied Java programs doesn't need Sun's JVM (nor any JVM) to operate, most Java progrmas are likely to depend on Sun's class libraries, which we're not allowed to redistribute them even as a part of Sun's JVM, so redistributing them as standalone, precomiled native binaries is a no-no.

Current State of Java in a Debian/Ubuntu

As of now, we can't rely on Free JVMs for all Java software due to compatibility issues. Nor can we redistribute any J2SE-compliant JVM due to licensing issues. Debian has traditionally provided very few Java packages, and Ubuntu has even fewer.

For anyone who's accustomed to apt-get, using Java on Ubuntu/Debian can be a real pain. We have to unpack tarballs in /opt, download all JAR dependancies for each programs, edit classpaths and $JAVA_HOME in shell scripts, writing our own init.d scripts too if they needed to be run as daemons, yada yada yada. Upgrading software and libraries is equally painful.

One thing is certain: even if Sun GPL'd Java today or a 100% Sun-compatible Free JVM appears tomorrow, we still have a lot of work to do to repackage all the existing Java software out there for Ubuntu. And without existing Java packages for Ubuntu, it's extremely counter-productive for Ubuntu users to develop or debug Free JVMs. If we continue to insist on a viable, Free JVM before we provide large-scale Java support, we'll continue to perpetuate this chicken-and-egg problem. I believe a more pragmatic approach is needed.

Identifying Targeted Audiences for Ubuntu Java

There are basically 2 audiences for Java: developers/administrators and desktop users. For devel/admin users, the use of make-jpkg is sufficient for its purpose IMHO. I'd say keep developing it as the prefered means of installing Sun/IBM JVMs. Developers and maintainers need a working Java environment now to do their work. Whether we'll have a 100%-compatible Free JVM or not largely depends on the work of these people. We shouldn't make it any harder for them.

Multiple-JVM support is really important in this environment, because a developer may be need to test programs on Free and non-Free JVMs on the same machine. The current Debian Java policy doesn't handle multiple JVM very well. Maybe adopting the JPackage policy would be a viable solution?

While most Java programs cannnot be included in main because they rely on Sun's JVM, it shouldn't be a concern for devel/admin users. We probably shouldn't consider introducing Java programs en-mass in main until we can decide on a de facto Free JVM anyways (which should be considered a completely different issue from packaging).

For desktop users, make-jpkg might be intimidating, though I fail to see why it's a showstopper. Maybe all we need is a little better documentation. Since Ubuntu's mission is to provide a complete environemnt for desktop users using only components in main, we can't really expect to provide complete support for desktop users in the near term simply because there isn't a 100%-compatible Free JVM we can ship in main. However, some desktop Java programs may be good candidates to be distributed as gcj-compiled native binaries, given that they can compile and operate with Free class libraries. GUI applications that depends on SWT are particularly good candidates because they're implicitly platform-dependant anyways.

Nevertheless, it's obvious that we simply DO NOT have the infrastructure to provide Java support for desktop users until we can provide a usable Java environment using completely Free tools. So I think it'll be prudent to focus on providing Java packages for devel/admin in universe in the mean time, so they can work more efficiently to improve Free JVMs and move existing Java packages to main eventually. As of now, the question of what default Free JVM to use in Ubuntu main or to-gcj-or-not is rather moot.

A Summary of my Proposal

  • We need to provide Java packages and we need to start ASAP. Just put them in universe for now. We'll move them to main gradually as they passes tests against Free JVMs.

  • Like it or not, Sun's JVM is the de facto standard. So let's just produce Java packages and test them against Sun's JVM for now. Eventually, Sun will loosen the licensing policy or a 100% (or even 90%)-compatible Free JVM will appear.
  • What default JVM we choose is the wrong question. We need proper multiple JVM support. Without which, developers can't efficiently develop Free JVMs and maintainers can't test packages against emerging Free JVMs without possibly breaking their working Java environment. A default JVM will emerge eventually when one of the Free JVMs becomes mature enough for us. Just let it happen on its own and focus our time on more important things.
  • We should consider JPackage's policy, especially concerning FHS, classpaths, package names and multiple JVMs. The upshot is that JPackage users are Java experts, they're actively trying to iron these wrinkles out, and they've already asked many questions we asked ourselves, and many more than we haven't, some of which they've already solved.
  • JPackage also provides generic tarballs in addition to RPMs. I think their generic tarballs are modified to follow JPackage's policy. So if we adopt some kind of JPackage compatibility, we can just use their generic tarballs as our upstream source. If we use their naming schemes too, then we can even resuse their dependancy metadata. It'll save us a lot of time in repackaging.
  • Our imminient goal should be getting Ubuntu to provide essential packages like Eclipse, Tomcat, JBoss, JEdit, Jakarta libaries, etc., ASAP. The JVM is just the mean, not the end. The developers should be our focus right now. We can consider full desktop support when the time is ripe.

-- goofrider / 2005.04.23

From GuidoDraheim Sun Apr 24 08:47:21 +0100 2005 From: Guido Draheim Date: Sun, 24 Apr 2005 08:47:21 +0100 Subject: agreed Message-ID: <20050424084721+0100@https://www.ubuntulinux.org>

.......... that's what it is like in the real world ......... (and yes, I had so many problems with java that I stopped bothering with any third party "iamagoodgeek" attempts of ohsogoodnew schemes. If you have never populated a yourproject-0.1/lib/* bestcompatible area then you do not know java. As a result, developments occur targetting the jpackage mix, bug reports are only handled for that - any other borken thing is an S.E.P.; if bin/j* is linked to something different than sun binaries then I would never try to list ubuntu as supported for java development)

From DavidFu Sun May 8 11:53:37 +0100 2005 From: David Fu Date: Sun, 08 May 2005 11:53:37 +0100 Subject: free-java-sdk Message-ID: <20050508115337+0100@https://www.ubuntulinux.org>

How about the free-java-sdk? It is using SableVM, and it has a layout similar to Sun's SDK. You can set JAVA_HOME to it, so it should look familiar to a normal Java Developer. http://packages.debian.org/unstable/misc/free-java-sdk

CategoryLookMergeDelete

JavaIntegration (last edited 2008-08-06 16:19:06 by localhost)