TylerBurton.ca » Java

The Linux Experiment Post Roundup

Tyler Burton — Tue, 10 Jan 2012 01:43:17 +0000

There has been quite a bit of activity on The Linux Experiment over the past little while. Check out the site here or quickly jump to the post that I wrote below.

Big distributions, little RAM 3

How do the ‘big time’ distributions handle on constrained hardware? Take a look.

How to install sun-java6-jdk and Netbeans in Ubuntu 11.10

A simple process to install the official ~~Sun~~Oracle Java JDK and Netbeans IDE in the latest Ubuntu.

Ubuntu 11.10′s WiFi crashes my router

The new Ubuntu release is pretty good. Unfortunately it also causes my router to crash.

Gentoo (A.K.A. “Compiling!”)

My first post for the second Linux Experiment where I speak about my Gentoo first impressions.

How to enable reboot/shutdown in KDE on Gentoo

Closed source AMD/ATI drivers, wireless networking and Flash in Gentoo

How to update your (whole) Gentoo system

A trio of small posts that walk new Gentoo users through setting up and doing some basic things in their new desktop.

How to play Red Alert 2 on Linux

I managed to get this classic game to run great on Linux. It even includes a bit of a hack that allows you to play LAN games. I don’t think you can even do that on Windows any more.

Oh Gentoo

My final post of the second Linux Experiment. Includes my conclusions on running Gentoo as a day-to-day desktop system.

Android development in Netbeans

Tyler Burton — Sat, 25 Jun 2011 01:20:45 +0000

So you want to do Android development but you hate Eclipse? Well fear not, there is another IDE that you can use to meet your mobile development needs. This is a quick guide, mostly for my reference later, on how to setup an Android development environment in Netbeans.

1. Download and install the Android SDK and Netbeans IDE like normal

Pretty self-explanatory just grab the installers from here and here respectively.

2. Download and install the Android plugin for Netbeans

The plugin to use is nbandroid and the easiest way to get it is to download it from right within Netbeans. First add the update xml (http://kenai.com/projects/nbandroid/downloads/download/updatecenter/updates.xml) to Netbeans.

Then simply install the plugin from the refreshed list of available ones.

3. Create an Android project

Just like you would create any other project in Netbeans. This will prompt you that you need to set up the location of the SDK. This can be done through the Manage Android SDK button.

Once created the project should be more or less good to go. Don’t worry if you get an error about a missing file R.java, this file will be automatically generated for your when you build the project the first time.

4. Profit?

That’s pretty much it. Now when you click run it will build and deploy your application to the emulator just like it does in regular old Eclipse.

Dynamically load a jar at runtime

Tyler Burton — Mon, 13 Jun 2011 01:10:48 +0000

A short post but I figured I would throw it up here before I lose my code. There are a couple of different ways that you can load jar’d code at runtime but here is a simple solution that I found to work very easily.

       File myJar = new File("myJar.jar");
       URL url = myJar.toURI().toURL();

       Class[] parameters = new Class[]{URL.class};

        URLClassLoader sysLoader = (URLClassLoader)ClassLoader.getSystemClassLoader();
        Class sysClass = URLClassLoader.class;
        try
        {
            Method method = sysClass.getDeclaredMethod("addURL", parameters);
            method.setAccessible(true);
            method.invoke(sysLoader,new Object[]{ url });

            Constructor cs = ClassLoader.getSystemClassLoader().loadClass("com.example.MyClass").getConstructor();
            MyInterface instance = (MyInterface)cs.newInstance();
            instance.someFunction();
        }
        catch(Exception ex)
        {
            System.err.println(ex.getMessage());
        }

In the code example above the jar at the location pointed to by the url object is dynamically loaded and an instance of the class com.example.MyClass is created that conforms to a known interface MyInterface. This could be used in a situation where you are loading plugins that use a common interface example.

Create a GStreamer powered Java media player

Tyler Burton — Mon, 14 Mar 2011 02:18:08 +0000

For something to do I decided to see if I could create a very simple Java media player. After doing some research, and finding out that the Java Media Framework was no longer in development, I decided to settle on GStreamer to power my media player.

GStreamer for the uninitiated is a very powerful multimedia framework that offers both low-level pipeline building as well as high-level playback abstraction. What’s nice about GStreamer, besides being completely open source, is that it presents a unified API no matter what type of file it is playing. For instance if the user only has the free, high quality GStreamer codecs installed, referred to as the good plugins, then the API will only play those files. If however the user installs the other plugins as well, be it the bad or ugly sets, the API remains the same and thus you don’t need to update your code. Unfortunately being a C library this approach does have some drawbacks, notably the need to include the JNA jar as well as the system specific libraries. This approach can be considered similar to how SWT works.

Setup

Assuming that you already have a Java development environment, the first thing you’ll need is to install GStreamer. On Linux odds are you already have it, unless you are running a rather stripped down distro or don’t have many media players installed (both Rhythmbox and Banshee use GStreamer). If you don’t it should be pretty straight forward to install along with your choice of plugins. On Windows you’ll need to head over to ossbuild where they have downloadable installers.

The second thing you’ll need is gstreamer-java which you can grab over at their website here. You’ll need to download both gstreamer-java-1.4.jar and jna-3.2.4.jar. Both might contain some extra files that you probably don’t need and can prune out later if you’d like. Setup your development environment so that both of these jar files are in your build path.

Simple playback

GStreamer offers highly abstracted playback engines called PlayBins. This is what we will use to actually play our files. Here is a very simple code example that demonstrates how to actually make use of a PlayBin:

public static void main(String[] args) {
     args = Gst.init("MyMediaPlayer", args);

     Playbin playbin = new PlayBin("AudioPlayer");
     playbin.setVideoSink(ElementFactory.make("fakesink", "videosink"));
     playbin.setInputFile("song.mp3");

     playbin.setState(State.PLAYING);
     Gst.main();
     playbin.setState(State.NULL);
}

So what does it all mean?

public static void main(String[] args) {
     args = Gst.init("MyMediaPlayer", args);

The above line takes the incoming command line arguments and passes them to the Gst.init function and returns a new set of arguments. If you have ever done any GTK+ programming before this should be instantly recognizable to you. Essentially what GStreamer is doing is grabbing, and removing, any GStreamer specific arguments before your program will actually process them.

     Playbin playbin = new PlayBin("AudioPlayer");
     playbin.setVideoSink(ElementFactory.make("fakesink", "videosink"));
     playbin.setInputFile("song.mp3");

The first line of code requests a standard “AudioPlayer” PlayBin. This PlayBin is built right into GStreamer and automatically sets up a default pipeline for you. Essentially this lets us avoid all of the low-level craziness that we would have to normally deal with if we were starting from scratch.

The next line sets the PlayBin’s VideoSink, think of sinks as output locations, to a “fakesink” or null sink. The reason we do this is because PlayBin’s can play both audio and video. For the purposes of this player we only want audio playback so we automatically redirect all video output to the “fakesink”.

The last line is pretty straight forward and just tells GStreamer what file to play.

     playbin.setState(State.PLAYING);
     Gst.main();
     playbin.setState(State.NULL);

Finally with the above lines of code we tell the PlayBin to actually start playing and then enter the GStreamer main loop. This loop continues for the duration. The last line is used to reset the PlayBin state and do some cleanup.

Bundle it with a quick GUI

To make it a little more friendly I wrote a very quick GUI to wrap all of the functionality with. The download links for that (binary only package), as well as the source (all package) is below. And there you have it: a very simple cross-platform media player that will playback pretty much anything you throw at it.

	Binary Only Package	All Package
File name:	my_media_player_binary.zip	my_media_player_all.zip
File hashes:	Download Here
GPG signature:	Download Here	Download Here
Screenshots:
Version:	March 13, 2011
File size:	1.5MB	1.51MB
File download:	Download Here	Download Here

Hash Verifier 0.3.0.1 (Java Web Start)

Tyler Burton — Sun, 24 Oct 2010 23:45:48 +0000

Java Web Start is a technology that allows easy deployment of Java based software through a web browser. The advantages of this framework are numerous but one nice thing is that it allows you far more freedom then the completely sandboxed Java applet. In this post I will detail how I converted my Hash Verifier application to run right from the browser.

Java Network Launching Protocol (JNLP)

The javax.jnlp libraries provide the functionality needed to launch the application from within a web browser. This is done through the use of a specially crafted XML file called a jnlp file. This file specifies the application information including the location of the executable jar and any class libraries associated with it. The nice thing about this is that it allows you to specify different class files spending on the platform it is being run on. This is exactly what I needed in order to get the correct SWT libraries loaded on the target platform.

As an example of what a jnlp file looks like here is the file I created for my Hash Verifier application:

Hash Verifier
tylerburton.ca

A graphical file digest generator
Hash Verifier

As you can see I have outlined all of the platform configurations that I am going to be compatible with. Java Web Start takes care of the rest for me automatically.

Digital signatures

The final step is to digitally sign the executable jar. This is required because when deploying an application that is not sandboxed, or one that requires access to low-level functions and libraries (as is the case in SWT), the end user needs to know that the code they are receiving came directly from the source. The easiest way to do this is to follow the instructions here. Unfortunately unless you are willing to pay to have your certificate signed by a trusted certificate authority the end user will need to click OK through a big security warning before they can use your program. It’s a small issue to overcome but if Minecraft can do it without too much of a headache I’m sure you can too.

Easy deployment

It’s as simple as that. I didn’t have to re-write my code, heck I didn’t even have to adjust a single line and it all just works. To see the result on your platform click here.

Note: unfortunately there is an issue with the Mac version of Java Web Start & SWT that prevents it from working correctly. Until Apple fixes this, or OpenJDK takes over and does it, SWT applications cannot be started correctly on that platform through Web Start.

Updates to Java & Mono

Tyler Burton — Sat, 09 Oct 2010 18:19:00 +0000

Both Java and Mono (the open source implementation of C# and .NET) will be receiving pretty big updates this year. These represent two very popular virtual machine based coding platforms that offer portability and a slew of helpful standard libraries. Here are just a handful of the improvements each will see in the coming release.

Java SE 7.0

While no tentative release date has been scheduled for Java 7 yet, the team has recently completed milestone 10 of 10. Sacrificing some features (which will be delayed until Java 8.0) Java 7 still has quite a few intriguing new additions.

G1 (new garbage 1st garbage collector)
This new garbage collector improves upon the original generational one by introducing the concept of regions. You can think of regions has smart versions of the generational lists that should allow the collector to clean up large chunks of garbage with increased efficiency.
Dynamic language support
The JVM will now support some internal changes which will allow dynamic languages (like Perl and Ruby) to leverage the speed and widespread nature of JVM for languages that aren’t strongly typed like Java. This in turn will will let dynamic languages have hooks into the standard Java libraries as well.
NIO (New I/O)
A new set of libraries for dealing with I/O. This will let Java do some interesting things like create symbolic links as well as giving general I/O operations a big performance boost.
Native Java video libraries
New standard video libraries will let the JVM playback and record video sources on any platform. No more relying on external libraries to do the job.
Strings in switch statements
I for one never really understood why you weren’t allowed to do this before. Obviously switch statements are highly optimized to act on numeric values but would it really be that hard for the compiler to change the string switch statement into an if statement for me? Now I don’t have to even think about it anymore.
Automatic resource management
Rather than having to worry about closing that I/O stream, Java will now take care of it for you. The new syntax is:do(BufferedInputStream bis = …) { //do some work} //it will automatically be closed here
Others
Other improvements include compressed 64-bit pointers to save memory, new parallel processing libraries to leverage multi-core CPUs and graphics acceleration improvements.

Mono 2.28

The folks over at the Mono team just finished up a new release that contains quite a few interesting additions as well.

Full C#/ASP.NET 4.0 support
This is nice to see because it means at the very least Mono and .NET are on equal footing when it comes to language syntax.
New generational garbage collector
Moving away from the older Boehm-Demers-Weiser garbage collector to a new generation garbage collector (a la Java) should mean improved performance at the temporary expense of extra memory usage. This should let the runtime decide the best time to schedule a garbage collection action and only focus on the objects most likely to need collection.
Dynamic language support
Similar to Java, this version of Mono now also supports the System.Dynamic libraries. Again this will allow dynamic languages to leverage the portable nature of Mono as well as hooking into the various Mono runtime libraries.
New parallel libraries and frameworks
These new libraries should make it even easier to create applications that make use of parallel processing. Among the libraries is PLINQ, an optimized version of LINQ for multi-core systems.
Overall performance improvements
Mono now targets LLVM which should make it better as a server platform. In addition there have been a lot of code fixes and performance improvements throughout the project. Finally this version of Mono has also removed Glib as a dependency which should make it lighter and more portable.

Introduction to SWT programming

Tyler Burton — Tue, 21 Sep 2010 01:11:22 +0000

Back in this previous post I mentioned the possibility of putting up a sort of how-to guide on SWT programming. Well I’ve finally found some time to do so. I will try to make this as step-by-step as possible so that anyone reading this will completely understand what I’m doing.

What you’ll need

I’m making the following assumptions before starting:

That you’ve already installed the Java Development Kit (not just the Java Runtime)
That you’ve installed Eclipse. You can use an alternative but all of my examples will be based on Eclipse. I’m also going to assume that you are at least familiar enough with Eclipse to compile a Java program.
That you have some understanding of Java or at least some programming experience.
That you have the SWT library for your platform downloaded. You can find this on the download page here.
That you’ve created a project in Eclipse (or your IDE) for this walk through.

Import SWT

The first thing you want to do is import the SWT libraries that you have downloaded as an Eclipse project. Start by creating a new project specifically for SWT. For instance I named mine org.eclipse.swt (following the Java standard namespace naming conventions). Next import the SWT files into that project. To do this simply click File > Import and then choose Archive File under the General folder.

Then browse to the zip file you downloaded and choose the project to import this to (again in my example this project is org.eclipse.swt). When all is said and done you should have a project in your workspace for SWT similar to the one I’ve got here:

SWTify your project

To finish adding the SWT libraries into your project we need to add them to your project’s class path. Right-click on your project and click properties. On the left hand side of the window you will see an item called Java Build Path. On that page there will be a number of tabs: Source, Projects, Libraries, etc. Click Projects and then click the Add button. Select the org.eclipse.swt project and click OK. You should see something like this indicating that the SWT libraries will be included in your project’s build path.

We are now ready to begin programming!

The default SWT program

import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;

public class MySWTProject {

     public static void main(String[] args) {

          Display display = new Display();
          Shell shell = new Shell(display);

          shell.open();

          while(!shell.isDisposed()) {
               if(!display.readAndDispatch()) {
                    display.sleep();
               }
          }

          display.dispose();
     }
}

OK so what does it mean. In SWT all of the graphical things that you can do are tied to a Display object. A Display is essentially a link to the OS’ underlying graphics output. What we are talking about is not a monitor – in fact a Display can contain multiple monitors – but rather a more abstracted concept of graphics. If this sounds confusing don’t worry, for the most part that’s all you’ll really need to know about the Display object.

A Shell should be a little easier to understand. It represents a window, the base application container. In fact if you run the above program you should see something like this:

A Shell can be manipulated in all of the ways that you think it would be. For instance you can give it a title by using the setText() method.

shell.setText(“Here is my window title”);

The open() method tells the Shell to start displaying itself. You can also do some interesting things like using the pack() method to size the Shell in order to make it just large enough to hold whatever you put into it.

The little while loop part first checks to make sure that our shell still exists and then executes any input that we may want our application to respond to (via the readAndDispatch() method). Finally we dispose of all resources we have requested from the OS by calling dispose() on the Display object. This is important because unlike regular Java programming we do not get automatic garbage collection in SWT. There is a silver lining however – calling dispose() on an object like Display will automatically call dispose() on any children that are registered with it. That is why we didn’t need to call dispose() on our Shell.

OK I get it, now show me a button

Interaction is very easy to add. For instance we can add a button to our Shell above by simply adding the following code after the line where we create our Shell.

     Button button = new Button(shell, SWT.PUSH);
     button.setText("Push Me");
     button.pack();

Of course you will also need to import the Button library for this to work. In the constructor we pass in the shell (where we want to attach this button, similar to how we attached our shell to the Display object) and a flag called SWT.PUSH. SWT.PUSH tells the button to act as a push button. Next using setText() again we set the button label. Finally using the pack() method, as described above, we can resize the button to be just large enough. If you re-run the program now you will should see something like the following:

Pretty simple stuff. We can even add an action listener that will respond when the button is pressed by using code like this:

button.addSelectionListener(new SelectionListener() {
    public void widgetDefaultSelected(SelectionEvent e) {
          widgetSelected(e);
     }

     public void widgetSelected(SelectionEvent e) {
          System.out.println("The button was pressed!");
     }
});

Again very simple. I hope that this very brief introduction will help people realize that SWT programming is very similar to regular AWT/Swing GUI creation (although each has their own unique weirdness). If you would like to download the sample code file that I used to create this you can do so here. Please let me know if you have any questions about what I have said above, I’d be happy to help. On the other hand if you want a more in-depth look feel, free to hop over to my Hash Verifier post and grab a copy of the source there. The Eclipse Foundation also has an excellent code snippet section here that will show you how to use each GUI widget.

Happy programming.

Hash Verifier 0.3.0.0 (A.K.A. the SWT re-write)

Tyler Burton — Tue, 07 Sep 2010 02:27:29 +0000

After reading up on how you can use SWT to give Java a more native look and feel I was interested in giving it a shot first hand. I decided to break out old faithful (Hash Verifier) and re-write it completely in Java/SWT. The end result was an application that has essentially equivalent functionality (see below for differences) but is completely cross-platform. No matter what operating system you end up running this on (Windows, Mac OSX, Linux) it should have a native look and feel. I will explain how I accomplished this literal “write once, run anywhere” code below.

Easy deployment

The download consists of three different programs. The first, and main, named HashVerifier.jar is not actually the Hash Verifier program, but rather a simple sequential application launching system that I wrote to make cross-platform deployment even easier. When you run HashVerifier.jar, either by double-clicking on it or by running it from the terminal with java -jar HashVerifier.jar, it opens up the included rules file and begins to execute the lines one after another. If there is a special platform specific file (such as rules.mac) it will run that instead. Let’s take a look at rules:

java -jar AdaptiveSWT swt.jar java -XX:+AggressiveOpts -XX:+UseParallelGC -jar HashVerifierApp

As you can see each line is a separate command to be run.

Getting that right look

When HashVerifier.jar starts it reads each line and runs that as a shell command. The line java -jar AdaptiveSWT swt.jar starts the second included program. AdaptiveSWT uses Java’s built in cross-platform UI toolkit, Swing, and displays a small dialog while it downloads the platform’s native SWT library. This is necessary because otherwise I would need to create separate downloads for each platform, each with their unique native SWT library. By using AdaptiveSWT I can instead let it handle all of the dirty work for me. This is really the trick that lets me release exactly one version of the program that looks correct for everyone. The AdaptiveSWT program is even smart enough to know not to re-download the library if you already have it. That being said if you ever do have an issue where you need to re-download the library either delete the swt.jar file in the program directory or change the first line to java -jar AdaptiveSWT -force swt.jar. This forces the download to happen regardless of it you already have it or not.

Hash Verifier

The next line logically starts the actual Hash Verifier application (with a couple of extra performance enhancing flags passed along as well). This version should work almost identically as the previous with a few key differences:

I have removed the Export to Hash File menu option as I simply just didn’t use it enough to warrant me spending the time to re-develop it.
I have removed the old Help menu option and replaced it with a visit website option.
RIPEMD-160 has been replaced with MD2, mostly because that is what the JVM supports “out-of-the-box”.

That’s about it. Please let me know if you have any issues running it on your platform of choice.

Requirements

OS: Windows, Mac OSX or Linux (Gtk+)
Internet connection
Java JRE (targeted at JavaSE-1.6 but might work on the previous version as well)

As before the binary only package contains just the executables, whereas the all package contains the source code as well.

	Binary Only Package	All Package
File name:	hash_verifier_0_3_0_0_binary.zip	hash_verifier_0_3_0_0_all.zip
File hashes:	Download Here
GPG signature:	Download Here	Download Here
Screenshots:
License:	(LGPL) View Here
Version:	0.3.0.0
File size:	68.6KB	107.1KB
File download:	Download Here	Download Here

NOTE: This software was tested on Windows Vista, Mac OS 10.6 and Linux Mint 9. While it may (and should) run on similar platforms I have not been able to test this. Please remember that this software is provided “as is” and without any sort of warranty. Use at your own risk.

Make Java GUIs less ugly (…or how I learned to love SWT)

Tyler Burton — Mon, 23 Aug 2010 02:47:06 +0000

It’s no secret that while Java possess probably the most widely distributed, cross-platform, and common user interface libraries, graphical Java applications on the whole simply stand out for the wrong reasons. Whether the GUI comes in the form of the Abstract Window Toolkit (AWT) or Swing, each can be far from pretty and often do not mesh well with the platform they are being run on. For instance, running an AWT or Swing application can be an almost alien experience, no matter what operating system you are using, because neither uses the native control widgets. Even AWT, being a ‘thin’ layer above the native controls, often looks completely bizarre. On Windows Vista AWT looks more like Windows 3.1 than anything else. Thankfully there is a nice alternative in the IBM created (and now Eclipse maintained) SWT.

The Standard Widget Toolkit, or SWT, passes all GUI rendering responsibilities onto the host operating system. This allows for some interesting advantages like hardware rendered drawing for free (as an example). It also provides for a native look and feel because its actually using the real native widgets. So when run on Windows it looks like a regular Windows application and when run on Linux it looks like a Linux (GTK+) application. It also works on the Mac as well as a few other obscure platforms.

Unfortunately because the application is now creating widgets outside of the JVM you are suddenly responsible for freeing the memory. There is no automatic garbage collection in the world of SWT. It’s not all bad however as freeing a parent object, like a window (referred to as a shell in SWT lingo), automatically frees all of its related child objects as well. Simply call the .dispose() method and 9 times out of 10 you are done.

Another other caveat is that you will still need to package the correct swt.jar file for your target platform. For instance Windows has its own version of swt.jar, as does Linux, and Mac, and so on and so forth. While this is rather annoying it does offer some interesting trade-offs. For instance you do not need to recompile your code just because you want to run it on a different platform; simply swap out the swt.jar file and watch as the exact same code generates completely different native GUIs. I even wrote a simple program that first checks what platform it is being run on and then downloads the correct swt.jar file before launching the GUI. This makes releasing the exact same package very simple.

So how do you start using SWT? Head over to http://www.eclipse.org/swt/ and download the newest stable version for your platform of choice. Depending on how you will be programing, all you have to then do is add the enclosed swt.jar to your class path. If you’re using Eclipse, or a similar IDE, you can simply add the source as either part of you project, or as a separate referenced one, and take full advantage of the auto-complete as well. Perhaps I’ll get around to posting a more thorough how-to guide at some point in the future.

Like most things in software SWT is not perfect. There are still other challenges to overcome, such as creating each individual platforms’ unique user experience to compliment their native GUI toolkits. That said if you’re looking for a way to leverage the widespread nature of Java, while still creating an application that looks like it belongs, SWT might just be what you’re looking for.

Some quick tips to speed up Java and lower it’s memory usage

Tyler Burton — Thu, 19 Aug 2010 02:32:19 +0000

Java is an excellent programming language but too often the JVM seems to slow it down. Yes I know that there have been tremendous speed improvements in recent versions but the fact remains that it can still feel slow. It also tends to use an insane amount of memory to do just about anything (the heap is cheap is the name of the game!). Well thankfully there are ways you can tighten the JVM’s belt and even fine tune its garbage collection process.

Tune for Performance

Tuning the JVM for performance can be as easy as launching your Java application with a few simple command line options tacked on. For instance you can simply specify that you want to use the server JVM (included in the JDK) instead of the client one. The server JVM is tuned to take slightly longer to start but to run faster in the long run. You can enable the server JVM by passing the -server option. You can also tell the JVM to be more aggressive with its optimizations by adding the option -XX:+AggressiveOpts. Or tell the JVM to cache commonly used strings by passing -XX:+StringCache as an option.

Tune for Memory

Tuning for memory can be just as easy. Here are some useful commands that you can throw at the JVM to lower memory usage. You can set the starting heap size by using the command line option -Xmsn where n is the size. For instance -Xms2048k or -Xms2m (each 2MiB in size) are both valid. Alternatively to set the maximum heap size you can use -Xmxn where n is specified as above. This will force the JVM to attempt to keep the program within that heap size (by being far more aggressive with garbage collection). However this can be dangerous because your program will crash if it simply cannot fit within the maximum set size. Additionally you can also set the thread stack size by using -Xssn, again similar to above, but this might be even more dangerous than setting the overall program heap size. Finally you can enable a parallel garbage collector by using the command -XX:+UseParallelGC. This should hopefully speed up reference check searchings and the overall garbage collection rate.

Using the above methods you can really customize Java to run exactly as you wish on your machine. It might not be perfect, but with a little bit of work it can be a lot better than the defaults.