Personal tools
User menu

Knowledge Base/Java/General

From Thalesians

Jump to: navigation, search

Contents

How to deal with java.lang.OutOfMemoryError: Java heap space

To increase the heap space, pass the following parameters to the JRE:

java -Xms536870912 - Xmx1073741824

-Xms specifies the initial Java heap size. -Xmx specifies the maximum Java heap size. The values supplied are in bytes. If the -Xmx is exceeded, an OutOfMemoryError will be thrown.

It may be more convenient to specify the heap space in kilobytes ("k" or "K"), megabytes ("m" or "M"), or gigabytes ("g" or "G"). The good news is that you can use these suffixes, e.g.

-Xms512m -Xmx1g

Stack trace as a String

The printStackTrace() method of Throwable (a parent of Exception) will send the stack trace to System.err. As of Java 1.4, getStackTrace() will return the stack trace as StackTraceElement[]. But what if a simple String is needed?

The easiest thing to do is to use yet another method, printStackTrace(PrintStream s), and convert its output to a String, as follows:

  1. public static String getStackTrace(Throwable t) {
  2. final Writer result = new StringWriter();
  3. final PrintWriter printWriter = new PrintWriter(result);
  4. t.printStackTrace(printWriter);
  5. return result.toString();
  6. }

Converting a byte ASCII code to a String

String s = Character.toString((char) charCode);

How to close Streams and Readers

Suppose I have something (pretty horrible) like this:

InputStream fileInputStream = fileObject.getContent().getInputStream();
BufferedInputStream bufferedInputStream = new BufferedInputStream(fileInputStream);
GZIPInputStream gzipInputStream = new GZIPInputStream(bufferedInputStream);
InputStreamReader inputStreamReader = new InputStreamReader(gzipInputStream);
BufferedReader bufferedReader = new BufferedReader(inputStreamReader);
 
String line;
while ((line = bufferedReader.readLine()) != null)
{
    // Do something with "line"
}

What happens now?

Whenever we open a stream we allocate resources. These must be deallocated when we are done with them, otherwise we have a resource leak. Thus we need to close the streams / readers. But which one(s) do we need to close? And how do we close them safely?

The answer is we only need to close bufferedReader. If multiple streams are chained together, then closing the one which was the last to be constructed, and is thus at the highest level of abstraction, will automatically close all the underlying streams.

Some java.io classes include a flush method. When a close method is called on such a class, it automatically performs a flush. There is no need to call flush explicitly before calling close.

Since we want to do our best to deallocate resources, we put bufferedReader.close() inside a finally block. If an exception is thrown after the line

BufferedReader bufferedReader = new BufferedReader(inputStreamReader);

we want to ensure the bufferedReader gets closed regardless:

InputStream fileInputStream = fileObject.getContent().getInputStream();
BufferedInputStream bufferedInputStream = new BufferedInputStream(fileInputStream);
GZIPInputStream gzipInputStream = new GZIPInputStream(bufferedInputStream);
InputStreamReader inputStreamReader = new InputStreamReader(gzipInputStream);
BufferedReader bufferedReader = new BufferedReader(inputStreamReader);
 
try
{
    String line;
    while ((line = bufferedReader.readLine()) != null)
    {
        // Do something with "line"
    }
}
finally
{
    bufferedReader.close();
}

See http://www.javapractices.com/topic/TopicAction.do?Id=8 for another example.

Why does ToolProvider.getSystemJavaCompiler() return null?

This may happen if tools.jar is not on the application's build path.

  • This page was last modified on 22 February 2011, at 13:42.
  • This page has been accessed 14,776 times.