Recently in Java Category

I knew I could get Java working in Firefox on my Tiny Core 2.11 Linux installation. I just had to think about it for a while.

I first tried the OpenJDK packages in Tiny Core, but those didn't work. Now that I know what I'm doing ... sort of ... I could probably get them to work, but I went about things another way.

Before I start, let me just stay that I didn't do this the entirely "kosher" way, but it works and for now (and for my idea of what Tiny Core is), I'm OK with it.

First I got the self-extracting Java runtime from Java.com.

After a few aborted attempts, I decided to do this in the /home directory, which in Tiny Core is /home/tc

I had the self-extracting .bin file jre-6u20-linux-i586.bin in the Desktop portion of the /home directory. I made a directory for it:

tc@box:~$ mkdir java

Then I moved the .bin into it — I wanted everything where I could keep an eye on it:

tc@box:~$ cd Desktop

tc@box:~$ mv jre-6u20-linux-i586.bin /home/tc/java

I went into my new directory and, per instructions from java.com, made the file executable:

tc@box:~$ cd /home/tc/java

tc@box:~$ chmod a+x jre-6u20-linux-i586.bin

Then, also per java.com instruction, I extracted and installed the archive:

tc@box:~$ ./jre-6u20-linux-i586.bin

After scrolling through the boilerplate EULA, I agreed to the terms and had the Java runtime installed in the directory I created.

(I know that it's better to have this somewhere under usr/bin, and I might very well move it later, but for now this works, so I'm keeping it.)

The next step was making the symbolic link to the plugin. Most instructions say to make this link in /home/tc/.mozilla/plugins. THIS DID NOT WORK in Firefox 3.0.4 aka Minefield.

Instead, the place to make the symbolic link is /usr/local/firefox/plugins

So opened a terminal, switched to root and did that:

tc@box:~$ sudo su

tc@box~# cd /usr/local/firefox/plugins

tc@box~# ln -s /home/tc/java/jre1.6.0_20/plugin/i386/ns7/libjavaplugin_oji.so libjavaplugin_oji.so

That leaves the symbolic link here:

/usr/local/firefox/plugins/libjavaplugin_oji.so

which leads to:

/home/tc/java/jre1.6.0_20/plugin/i386/ns7/libjavaplugin_oji.so

Remember, it was my choice to extract and install the Java runtime in the /home directory. There are probably better places for it, but until I know Tiny Core a whole lot better, I'll keep it where I can see it ...

I started Firefox 3.0.4 (aka Minefield) looked in Tools - Add-ons - Plugins, and the Java plugin was right where it was supposed to be.

Just to be sure Java will run in the browser, go to Edit - Preferences - Content and be sure the "Enable Java" box is checked.

Another way to check for Java is to go to about:plugins in the URL window of the browser. You should see a long list of Java-specific output.

I did confirm that Java works in Minefield/Firefox, and now I can use Tiny Core for those few yet critical tasks that require the Java runtime, making TC that much more valuable to me.

Potential problem: One thing I'm noticing is that the java_vm process is still knocking around in my system, even though I'm not using the Java runtime at this particular moment.

It wasn't using any CPU but was eating about 400 MB of RAM. Nice little thing, that Java.

I killed java_vm in a terminal, and it took Firefox/Minefield with it. Nice.

So I have Java, but I'll be keeping an eye on it, wondering if it will behave (and checking my other systems for errant java processes that run on too long).

As a way of explaining what this is all about, Cameron Simpson wrote the following way back in 2005:

The JVM gets started once and hangs around because a JVM has a noticable startup cost. If you want web pages with Java content to be "snappy" in loading (bandwidth aside) it helps if the JVM is already present and initialised, and so it doesn't go away when idle.

Provided it's consuming no CPU then it's no added burden on your system; memory contention will page it out to your swap space if necessary.

Do you have a technical reason for wanting it gone or does it just seem "untidy" to your eye?

I hope that's true. In my case, the /swap on my drive is encrypted and not available to be used by Tiny Core, so I'll be keeping an eye on java_vm when I run Java in TC.

I booted the Toshiba 1100-S101 with Ubuntu 8.04 for the first time in 25 days, according to the Update Manager. Or at least it was 25 days since I updated the install.

Either way, I've been running a nearly carbon copy of this laptop with OpenBSD 4.4, lately with the Xfce 4.4 desktop environment, and I'd gotten quite used to it. While I still had only Flash Player 7 through the Opera browser in OpenBSD, I did have the Java runtime installed, so I thought ... thought I could use all the Web-based applications I need to use that require Java. Thought.

Here I am, 10 p.m., working at home, and I discover that LogMeIn just doesn't like OpenBSD. Even in Linux, when you don't have Java you can still use LogMeIn. It's way, way, way better with Java, which is why I installed Java both in Ubuntu 8.04 and OpenBSD 4.4. My other Java-based applet I use, a fairly simple uploading mechanism (for which I could use FTP but the company I'm dealing with has it hooked up so images take forever to process when you FTP them but process immediately when you use the Java app ... so you can guess which one I've begrudgingly turned to), and that works fine with the Java in OpenBSD as well as in Ubuntu.

But LogMeIn ... oh, LogMeIn ... you piss me off. I set up, tested and used Java in Ubuntu 8.04 to control a remote Windows desktop with LogMeIn Free (and I'm announcing right here, right now, if I can get LogMeIn to work in OpenBSD, I will stop being a freeloader and buy your damn service ... but I'm not opening up my wallet just yet.

Anyhow, I'm merrily doing my work on the OpenBSD Toshiba laptop when I fire up LogMeIn in Firefox. I try to bring up my remote machine and I get a blank screen. It appears from my feeble attempts at figuring out the problem that LogMeIn is trying to use ActiveX even though I'm not running it on a Windows box or using Internet Explorer. LogMeIn doesn't need ActiveX. It doesn't even need Java (though, as I say, it's damn near unusable without it). Don't get me wrong, it works great from Windows box to Windows box with ActiveX. It's nearly as seamless with Java, and thus I have Java — with the express purpose being the enjoyment of said seamlessness.

But I had no LogMeIn. So I did my work, doing everything as best as I could. Then I booted into the Windows XP partition on my OpenBSD laptop. Yep, it came with Windows loaded, and I just shrunk the NTFS partition and slapped OpenBSD 4.4 on the newly freed half of the hard drive (and yes, dividing a 20 GB drive between XP and OpenBSD doesn't exactly give you a ton of room in either OS).

My XP partition even has Service Pack 3 and IE7. So I fired up IE, allowed it to install ActiveX (is it ActivX or ActiveX — 'e' or 'no e' ... I have no idea).

LogMeIn ran great in XP, I did my thing, turned off the laptop and went to bed at midnight.

The next day, which is right now, I pulled out the Ubuntu 8.04 Toshiba, cranked it on and tried out LogMeIn. Works great in Ubuntu with Java.

For the Ubuntu update, wait for the next entry ...

When I set up this Toshiba Satellite 1100-S101 laptop with OpenBSD 4.4 late last year, I decided to go with Firefox 2.0.0.16 instead of the newer Firefox 3.0.1.

I had used FF3 in Ubuntu and on Windows quite a bit, and I finally began running it in Mac OS now that I finally upgraded the iBook to OS X 10.4.

But until now I stuck with FF2 on this OpenBSD laptop.

By the time OpenBSD 4.5 is released in May, FF2 will be no more. That was another factor governing my decision to finally upgrade to FF3.

I finally decided to make the leap from FF2 to FF3. (Remember that OpenBSD doesn't generally update binary packages after each release. Unless you run -current and compile everything, it's six months between upgrades for the OS and the applications.)

I was prepared for trouble, but everything went well. It didn't hurt a bit. All of my FF2 settings and bookmarks are intact, as are my add-ons (including Web Developer). Java still works, too. And performance of FF3 seems more than a little bit snappier than FF2. I can really feel the difference with Web-based apps that use a lot of Javascript.

Yeah, I'm months late to the FF3 party (at least on this platform), but I can more than safely say that I'm damn glad I finally and painlessly made the switch.

To replace FF2 with FF3, here's what I did in an xterm window:

$ sudo pkg_delete mozilla-firefox
Password:
mozilla-firefox-2.0.0.16p3: complete
Clean shared items: complete
$ sudo pkg_add -i firefox3
firefox3-3.0.1p3: complete
--- firefox3-3.0.1p3 -------------------
Please see /usr/local/mozilla-firefox/README.OpenBSD
for information about running Firefox on OpenBSD.

OpenBSD users face a similar dilemma in version 4.5, in which OpenOffice 2.4 will co-exist along with OO3. For the release after that, just like with FF, OO2.4 will be gone, and only OO3.x will remain. I'm OK with that, too. I just started using OO3 in Windows, and I think it's a pretty good release thus far.

I love it when things work. It happens more often than not in OpenBSD, and that's why I've stuck with it. If things were breaking down software-wise, I'd be sprinting back to Linux. But as long as not having Flash 9 or 10 doesn't totally harsh my proverbial mellow (OpenBSD is mired in Flash 7 due to subsequent Linux Flash Players insisting on ALSA sound, which the BSDs don't have), I'm comfortable.

And if I could manage to edit video in Blender, I would work around the lack of up-to-date Flash.

Now ... back to the OpenBSD way of keeping things up to date (or not ...).

I can't decide whether, and if so how much, I'm troubled by keeping the same version of various apps on my machine for six months at at time. At one level, I'm happy not to be constantly doing apt-get update apt-get upgrade or having the Update Manager pop up every day.

But if you want to keep current in OpenBSD, you need to either patch your box to -stable, or just run -current which is what developers and other edgy types install on their own equipment. I'll confess that if I understood a little better how to make a -release box -stable, or keep a -current box current, I'd be more game for doing it (and I might get there at some point). I do know that a lot of compiling is involved, and I'm no fan of sitting and waiting for ports to build. But if Firefox 3.0.8 is what I craved, I could get it now either in by running -current or by and building the port. Even in Ports, Firefox is stuck at 3.0.1 in my 4.4 environment.

I've seen a few users claim that keeping an OpenBSD box at -stable or running -current and updating it is no big deal. I'd love for that to be the case.

Right now, on this install, I have maybe 2.5 GB in /usr, and after my experience running out of space to build Java, I'm reluctant when it comes to bringing down the source of OpenBSD and compiling it. This is just about as close to a "production" machine as I have, and I can't risk bricking the install, so I'll be ordering my OpenBSD 4.5 CDs very soon (make that very, very soon) and upgrading that way. I've done it once, and hopefully I can do it again.