null parameter? Hot the hell is the class designed? These question I have often asked when I had was working with a library without sources. But now I have found a really nice Eclipse plugin http://java.decompiler.free.fr/jd-eclipse/. The update site is http://java.decompiler.free.fr/jd-eclipse/update.
od command. But the result was an unusable list of octal numbers. After a minute with playing, I have found a feasible solutionod -A n -v -t d1 image.gif | sed -e 's/^ *//g' -e 's/ */,/g' -e 's/$/,/g'I have copied a result into my Java code as
private static final byte[] MISSING_ICON_BYTES = new byte[] { /* copy result here */ };
public static final ImageIcon MISSING_ICON = new ImageIcon(MISSING_ICON_BYTES);
<zipfileset> resource pattern:<delete file="new.jar">
<zip file="new.jar">
<zipfileset src="old.jar">
<exclude name="META-INF/replace.properties"/>
<exclude name="META-INF/remove.properties"/>
</zipfileset>
<zipfileset file="file-to-replace.properties" fullpath="source-file-to-be-replaced.properties"/>
</zip>
You can use any of Ant resources. I personally like zipfileset, because it allows to specify the fullpath attribute, which is the simple way how to change a name of a source file. The <exclude> element is like "delete file" command in this example.jar task can be used instead of the zip task, too. But then it has to be specified the META-INF/MANIFEST.MF also, otherwise the jar task creates a new one.new.jar, if it is newer (has greater timestamp) than the file old.jar. So, I recommend to delete the new.jar file first.
JOptionPane makes life of a developer much easier when one need to show simple message or input dialogs. However, when a huge String or a String with many line breaks is passed to it's showMessageDialog() method, then the message dialog may the screen. For the user, it's better, when the very large messages are wrapped in an JScrollPane. It is possible to pass JScrollPane as an message parameter into to JOptionPane, so far so good. Unfotunatelly, it's not possible to limit the maximum size of the dialog. Finally, I have finished with this solution:JTextArea textArea = new JTextArea(); textArea.setEditable(false); // better to keep it true, so the user is able to copy the message to the clipboard //textArea.setFocusable(false); textArea.setOpaque(false); textArea.setText(message); textArea.setCaretPosition(0); // jump to the beginning JScrollPane scrollPane = new JScrollPane(textArea); scrollPane.setBorder(null); // no border, please Dimension scrollPaneSize = scrollPane.getPreferredSize(); Dimension screen = Toolkit.getDefaultToolkit().getScreenSize(); scrollPaneSize.width = Math.min(scrollPaneSize.width, Math.max(screen.width / 2, 260)); scrollPaneSize.height = Math.min(scrollPaneSize.height, Math.max(screen.height / 2, 125)); scrollPane.setPreferredSize(scrollPaneSize); JOptionPane jOptionPane = new JOptionPane(scrollPane, JOptionPane.ERROR_MESSAGE); JDialog dialog = jOptionPane.createDialog(parent, "Error"); // it could be nice to let the user resize the dialog, but then the scrollPane always shows the scroll bar //dialog.setResizable(true); dialog.setVisible(true); dialog.dispose();The size of the
scrollPane grows or shrinks. It's maximum is screen size divided by two, or (260, 125) points (just in case the screen is too small :-)). I have found out, that (260, 125) is roughly the size of the empty massage dialog.
myproject_war. When I have deployed it into the JBoss server, then the deployment name was myproject_war.war. I wanted to deploy it as myproject.war only. I could not find any property in the "Properties" dialogue to change the deploument name, so I have searched my filesystem for "myproject_war" string. So, I have discovered the file.settings/org.eclipse.wst.common.component in the project directory. I have changed the attribute name of the wb-module module there, from<wb-module name="myproject_war">to
<wb-module name="myproject">Now, the project is deployed as
myproject.war.
public class MyClass {
private static MyClass instance = null;
public static MyClass getInstance() {
if (instance == null) instance = new MyClass();
return instance;
}
}
public class MyClass {
private static MyClass instance = null;
public static synchronized MyClass getInstance() {
if (instance == null) instance = new MyClass();
return instance;
}
}
public class MyClass {
private static MyClass instance = null;
public static MyClass getInstance() {
if (instance != null) return instance;
synchronized (MyClass.class) {
// yes, one more check in synchronized block
if (instance == null) instance = new MyClass();
}
return instance;
}
}
instance = new MyClass() is not an atomic operation. So a thread can get the instance variable while some other thread is still processing the constructor of the same instance object. You can find some old web pages advising to use double check locking in a wrong way, e.g. http://www.javaworld.com/javaworld/javatips/jw-javatip67.html. Bill Pugh's research has changed the memory model in Java 1.5, so there is a new keyword volatile which solves the hidden snag:public class MyClass {
private static volatile MyClass instance = null;
public static MyClass getInstance() {
if (instance != null) return instance;
synchronized (MyClass.class) {
// yes, one more check in synchronized block
if (instance == null) instance = new MyClass();
}
return instance;
}
}
logging.properties. I do not like, that-Djava.util.logging.config.file=logging.properties to the JRElogging.properties cannot be packed into the JAR of the application.JAVA_HOME/lib/jndi.properties, ...main() method. Then you may pack a default logging.properties file into the JAR with your application (the same JAR where is the class with this code). And the user may still use the -Djava.util.logging.config.file=logging.properties property to use her/his own logging configuration./**
* Should be called before the first use of the JDK logging. The best place is
* in the static initializer of the class, which has the {@code main()} method.
*/
static {
String file = System.getProperty("java.util.logging.config.file");
if (loggingfile == null || loggingfile.isEmpty()) {
URL url = null;
try {
url = MyClass.class.getClassLoader().getResource("logging.properties");
if (url == null) {
System.err.println("Cannot find logging.properties.");
} else {
LogManager.getLogManager().readConfiguration(url.openStream());
}
} catch (Exception e) {
System.err.println("Error reading logging.properties from '" + url + "': " + e);
}
}
}
public static void main(String[] args) { ... }
If you need something more robust, then look into the Java sources for the aforementioned JNDI initialization :-).