Declaring Constructors, Methods, and Variables in an enum

NOTE: the order of the line of the code is important for the following:

public enum SORT_ORDER

{

  ACCESSED_ASCENDING("accessed_ascending"),   

  ACCESSED_DESCENDING("accessed_descending");

   

  private SORT_ORDER(String p_value)

  {

   this.m_value = p_value;

  }

  private final String m_value;

  @Override

  public String toString()

  {

    return m_value;

  }

}

Linux: java.io.IOException: Too many open files

http://lj4newbies.blogspot.com/2007/04/too-many-open-files.html
http://www.karakas-online.de/forum/viewtopic.php?t=9834

1. check max file descriptor

cat /proc/sys/fs/file-max

change to higher if needed

2. add to
/etc/security/limits.conf

something like

* soft nofile 65535

* hard nofile 65535

3. log out and log back in  

Singleton, Thread Safety, Volatile, Synchronized

On the singleton 'getter', add 'synchronized' for thread safety

otherwise, findbugs will say something like "Incorrect lazy initialization of static field ..."

More explanation:

http://www.ibm.com/developerworks/java/library/j-dcl/index.html

http://en.wikipedia.org/wiki/Singleton_pattern

Private Constructor

http://www.javapractices.com/topic/TopicAction.do?Id=40

If the programmer does not provide a constructor for a class, then the system will always provide a default, public no-argument constructor. To disable this default constructor, simply add a private no-argument constructor to the class. This private constructor may be empty.

In these cases, the lack of an accessbile constructor says to the caller : "There are no use cases for this class where you need to build an object. You can only use static items. I am preventing you from even trying to build an object of this class."

64bit Ubuntu won't run java

As of  Ubuntu 10.04 LT - the Lucid Lynx

you can't run a 32 bit jre on it, will tell you something like

exec: 1: ../../../bin/java: not found

In fact, 32 bit eclipse won't work either, and imaginable many other 32bit applications

Exception handling

- "Effetive Java" item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors

- http://marxsoftware.blogspot.com/2010/04/i-recently-wrote-that-chapter-in.html

BufferredReader

2 down vote

The Reader.ready() and InputStream.available() rarely work as you might like, and I don't suggest you use them. To read a file you should use String line; while ((line = reader.readLine()) != null)     System.out.println("<"+line+">");

http://stackoverflow.com/questions/5244839/dose-bufferedreader-ready-method-ensure-that-readline-method-does-not-return

BufferedReader reader=null;
    try {
        reader = new BufferedReader(new StringReader("ABCD"));

        while (reader.ready()) {
            final String line = reader.readLine();
            System.out.println("<"+line+">");
        } catch (..)
    {
        ...
    }

So a BufferedReader is considered ready simply if the underlying stream is also ready. Since BufferedReader is a wrapper, this underlying stream could be any Reader implementation; hence the semantics of ready() are those declared on the interface:

Returns true if the next read() is guaranteed not to block for input, false otherwise. Note that returning false does not guarantee that the next read will block.

So you only really get timing guarantees, i.e. that read() will not block. The result of calling ready() tells you absolutely nothing about the content you'll get back from a read() call, and so cannot be used to elide a null check.