Java is a programming language which results in code compiled into executable (binary) programs, in a manner similar to other languages such as "C". Java-written programs require a Java run-time environment installed on the executing computer. Alternatively, JavaScript is only questionably a language and, if a language, then a scripting-type language; it doesn't require compilation. Applications written in JavaScript operate only in a browser (except to write cookies), and are called "applets". Applets require a run-time environment, and this is either built-in to the browser or is a browser plug-in. The user can enable or disable the JavaScript run-time for their browser. For example, a user might encounter a warning that JavaScript has not been enabled on their browser; this refers not to the applet, but to the JavaScript run-time plug-in not being installed/enabled.
As just noted, JavaScript browser applications ("applets") run via a JavaScript plug-in prepackaged inside most browsers. JavaScript applets are difficult to design for all browsers, since each browser (IE, Firefox, Opera, etc) designs its run-time slightly differently. A variance from what that particular browser needs to run the applet leads to the somewhat common "JavaScript error" messages encountered when browsing. This is expected to change as the ECMA eventually standardizes the approach. Another difficulty with JavaScript applets in browsers is security. Applets written in JavaScript operate in limited parameters ("sandboxes") designed to limit access to the user's system. But they've been proven not to entirely deny this access. A nice thing about the JavaScript browser plug-in is it alerts users to necessary updates.
What about the original Java? Java is a language for writing applications that run on the workstation itself, not merely in a browser. For example, you could write a program in Java that edits photos, or documents, etc. Like other compiled programs, Java programs require a runtime environment, but Java was also designed to be cross-platform. That is, the Java concept is to create programs which run inside various operating systems (Linux, Windows, Mac OSx), and platforms (x86, Mac). The software framework of the runtime is what varies for each machine, and this runtime framework is installed first, prior to the program. Once the virtual framework is installed, the Java application may then be installed - the application is supposed to work regardless of the type of machine or OS, since the underlying runtime layer is handling any OS idiosyncracies.
I've found that Java applications do work on anything if the runtime is properly installed. Unfortunately, in my experience at least, Java runtime framework installation is often problematic, so much so that the original reason for this blog page was to refresh my memory for some typical steps. One other note, framework version updates are not typically automatically displayed so that installers must remember to check for periodic upgrades.
The Java Runtime Environment (JRE) is the primary framework for Java-written applications, in a similar way that the Visual Basic Runtime Environment (VBRE) is the virtual machine for applications written in Microsoft's Visual Basic. The latest version of the JRE appears to be called J2SE (Java2 Software Environment). Sometimes J2SE by itself is enough to run a Java-written application, other times, additional Java frameworks have to be compiled and added to J2SE to provide functionality. Some examples: I have Sun's OpenOffice on my workstation. Without installing the Java Media Framework (JMF), a separately compiled framework which relies upon J2SE already being installed underneath it, there is no way I know of for OpenOffice's Impress application (it's like PowerPoint) to playback sound and video. An mp3 addition to the JMF can also be compiled and added. The Java Database Connectivity (JDBC) software first requires J2SE to be in-place. JDBC supports databases such as Neo4j (a graphing database good for tags). There are additional Java environments/frameworks available. Taking all these Java flavors together, the terminology and installation picture appears complicated, and the best overall description I've seen is here. The remainder of this post is hands-on.
Java Media Framework (JMF)
A fundamental problem is the Java Installation site provides ambiguous information. Of course, mere awareness of its ambiguity isn't going to overcome it. In one forum, a guy complained that he spent so long attempting to configure his JMF installation that he decided to return to M$ Windows. That's extreme, but it seems questionable that the JMF installation appears to require a significant underlying understanding of paths, classpaths, and softlinks for software roughly four years old. Installation should be simpler by this point.
Step One: JRE
I haven't yet installed J2SE, so I use the old Java Runtime Environment. It's important to check that it's installed and that it exists in user's and root's path. I checked both of these to be sure, and then just repeated as root:
$java -versionIf these don't show up, it's best to check and make sure the JRE path has been exported. For example, check that /etc/profile includes somewhere:
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing)
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/games/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/lib/java/bin:/usr/lib/java/jre/bin:
JAVA_HOME="/usr/lib/java/"
export JAVA_HOME
Step Two unpacking and moving
Download the bin file and unpack it:
$ sh ./jmf-2_1_1e-linux-i586.bin.
It makes a directory like any untar. I rooted-up and moved this entire directory to /usr/lib/JMF-2.1.1e
Step Two: user and root paths
JMF needs to be found on occasion by root and on other occasions by the user. These are two different setups:
1) User: Sun recommends creating a /home/~/.profile file with these entries:
# path settings for JMF
export JMFHOME=/usr/lib/JMF-2.1.1e
export CLASSPATH=.:$CLASSPATH:$JMFHOME/lib/jmf.jar
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$JMFHOME/lib
I like things explicit, so I leave out the "JMFHOME" variable and do it this way:
CLASSPATH="/usr/lib/JMF-2.1.1e/lib/jmf.jar"
export CLASSPATH
LD_LIBRARY_PATH="/usr/lib/JMF-2.1.1e/lib
export LD_LIBRARY_PATH
2) Root: add the same lines, but at the top of /etc/profile.
3) User and Root: Echo the path ("echo $PATH") to be sure that it includes paths to the jmf files. If not, add additional paths as the final lines of the "/etc/profile". For example, I also wanted some X11 bin files in my path, so my final two "etc/profile" lines are:
PATH="$PATH:/usr/X11/bin:/usr/lib/JMF-2.1.1e/bin"
export PATH
Following this, JMF was working except
Step Three: activate
Easiest: restart the computer so it sources both profiles.
Step whatever - diagnostics
The one good thing Java has done is make an online diagnostics page with which to check the JMF installation. Just point the browser there and it checks my JMF (and JRE). However, checking via the browser in this was seems to confoundingly generate classpath errors, regardless that there aren't any. See below.
Firefox
Firefox is a separate matter. With JMF properly configured for their workstation, when one visits the online diagnostics page, one will receive an error " classes..".
mp3
JMF also has a download to play MP3's.
No comments:
Post a Comment