This week's book giveaway is in the Agile and Other Processes forum. We're giving away four copies of Software Teaming: A Mob Programming, Whole-Team Approach and have Woody Zuill and Kevin Meadows on-line! See this thread for details.
Q: How can I run executables written in other languages from Java?
This involves the java.lang.Runtime and java.lang.Process classes.
All the details can be found in this article.
The Bean Scripting Framework (BSF) library from Apache does this. It facilitates two-way integration between Java and a growing number of scripting languages.
Java 6 introduces an API that does something comparable; see here for an introduction.
Q: What is the Observable class and and the Observer interface?
Some discussion and an example can be found here.
Q: What are Marker (or Tagging) Interfaces, and why don't they have any methods?
Marker interfaces are a mechanism of asserting a fact about a class, without adding any
functionality to it. As such, they represent metadata about that class. Some examples are:
java.io.Serializable asserts that objects that implement it may be serialized using java.io.ObjectOutputStream.
java.lang.Cloneable indicates that the objects clone method may be called (A different approach to disallow certain calls is taken by Collection.remove: it throws an exception if it is called on an object that does not support it.)
java.rmi.Remote indicates that methods may be called from remote JVMs
java.util.EventListener is used for event listener classes
java.util.RandomAccess indicates to the JVM the most performant way to iterate through a List
javax.ejb.EnterpriseBean serves as parent for the various EJB interfaces that actually do include methods
javax.servlet.SingleThreadModel states that this class should not be called for multiple threads concurrently
From this list it's clear that marker interfaces have been used for widely differing purposes.
Marker interfaces are a misuse of interfaces, and should be avoided. Note that all the above example are rather old, and that no new ones have been added since. Ken Arnold, who was/is behind several Java APIs at Sun, sounds off on marker interfaces here, noting that they should rarely be used.
With the advent of annotations in Java 5 -which are a generic mechanism of adding metadata to a class-, marker interfaces have become obsolete, and no new ones should be defined.
Q: How can I evaluate an expression that a user enters, or create a Java class that includes it as a method?
There are a number of libraries that can take an expression and either compile or interpret it. JEP does interpretation; a newer commercial version is also available. For even more flexibility, check out Javassist, which creates actual Java classes.
Since JNI only works with C/C++, but not the .Net languages, a .Net wrapper in C++ needs to be created as well if the COM/DLL object was written in one of those languages. An RFE (Request for Enhancement) has been filed years ago for letting JNI code access .Net code directly (see this entry in Sun's Java Bug Database), but it doesn't seem to go anywhere.
JNA implements something similar to JNI, but without the need to create or use C headers and files (it's all Java from the developer's perspective); article Q: What's up with integers not being equal to one another? The following code prints "true, true, false, true". Shouldn't it be "true, true, true, true"?
The key to understanding this is that the JVM uses a process called "boxing" (or "auto-boxing") when converting an int (like 127) to an Integer object. This involves calling the Integer.valueOf(127) method. The JavaDoc:java.lang.Integer#valueOf(int) says: "Returns a Integer instance representing the specified int value. If a new Integer instance is not required, this method should generally be used in preference to the constructor Integer(int), as this method is likely to yield significantly better space and time performance by caching frequently requested values." What that means is that the valueOf() method has a cache of Integer objects, and if the primitive being boxed is in that range, the cached object is returned. It just so happens that 127 is in that range, but 128 is not. So i and j are the same object, while i1 and j1 are not. (Also note that you can't rely on the boundary to fall between 127 and 128 - since this is not documented, JRE implementors are free to shrink or enlarge the range of values so cached.)
Q: How can I find out from where my class is loaded?
Q: Where can I download old JDK versions, and other APIs that have been deprecated?