THURSDAY, DECEMBER 04, 2008
Running the JavaFX 1.0 SDK on Linux
The JavaFX 1.0 SDK was released today. I've played with the preview SDK, so I was pretty excited to try out the 1.0 SDK. Inexplicably, and this was the case with the preview SDK as well, Sun hasn't released a version of the SDK for Linux. However, this wasn't a problem because it was possible to run the Mac version of the Preview SDK on Linux. The preview SDK came in the form of a zip, but the 1.0 SDK comes in the form of a dmg, so I was initially stumped. But I've figured out how to get the Mac version of the SDK to work on Linux. It's a little more complicated than getting the preview SDK to work, but it works!
The thing about dmg files is that you can easily mount them on Linux since they are essentially stored in the HFS Plus filesystem format. So I immediately set about trying to mount it:
Hmm... ok, that wasn't what I expected, so I tried to see what type of file it was:
Ok, so it look's like it's a bzipped file. All we need to do then, is bunzip it and mount it:
Awesome! So we were able to get the dmg mounted. Now all we need to do is find were the SDK lives. After going through the dmg, I found out that the SDK is stored in a compressed (gzipped) file. You can find it at <mountpoint>/javafx_sdk-1_0.mpkg/Contents/Packages/javafxsdk.pkg/Contents/Archive.pax.gz. Copy this file into another working directory (or wherever you want your SDK to reside. I put mine in /usr/local):
When I gunzipped the file, I got Archive.pax, and I wasn't sure what to do with it. So I ran file on it and discovered that it was a cpio file. Some quick Googling and man-page perusal later:
As you can see, you now have a working JavaFX 1.0 SDK on your Linux box!
The thing about dmg files is that you can easily mount them on Linux since they are essentially stored in the HFS Plus filesystem format. So I immediately set about trying to mount it:
vivin@dauntless ~
$ mkdir javafx
vivin@dauntless ~
$ sudo mount -o loop -t hfsplus javafx_sdk-1_0-macosx-universal.dmg javafx
[sudo] password for vivin:
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
$ mkdir javafx
vivin@dauntless ~
$ sudo mount -o loop -t hfsplus javafx_sdk-1_0-macosx-universal.dmg javafx
[sudo] password for vivin:
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Hmm... ok, that wasn't what I expected, so I tried to see what type of file it was:
vivin@dauntless ~
$ file javafx_sdk-1_0-macosx-universal.dmg
javafx_sdk-1_0-macosx-universal.dmg: bzip2 compressed data, block size = 100k
$ file javafx_sdk-1_0-macosx-universal.dmg
javafx_sdk-1_0-macosx-universal.dmg: bzip2 compressed data, block size = 100k
Ok, so it look's like it's a bzipped file. All we need to do then, is bunzip it and mount it:
vivin@dauntless ~
$ bunzip2 javafx_sdk-1_0-macosx-universal.dmg
bunzip2: Can't guess original name for javafx_sdk-1_0-macosx-universal.dmg -- using javafx_sdk-1_0-macosx-universal.dmg.out
bunzip2: javafx_sdk-1_0-macosx-universal.dmg: trailing garbage after EOF ignored
vivin@dauntless ~
$ sudo mount -o loop -t hfsplus javafx_sdk-1_0-macosx-universal.dmg.out javafx
vivin@dauntless ~
$ ls javafx
javafx_sdk-1_0.mpkg
$ bunzip2 javafx_sdk-1_0-macosx-universal.dmg
bunzip2: Can't guess original name for javafx_sdk-1_0-macosx-universal.dmg -- using javafx_sdk-1_0-macosx-universal.dmg.out
bunzip2: javafx_sdk-1_0-macosx-universal.dmg: trailing garbage after EOF ignored
vivin@dauntless ~
$ sudo mount -o loop -t hfsplus javafx_sdk-1_0-macosx-universal.dmg.out javafx
vivin@dauntless ~
$ ls javafx
javafx_sdk-1_0.mpkg
Awesome! So we were able to get the dmg mounted. Now all we need to do is find were the SDK lives. After going through the dmg, I found out that the SDK is stored in a compressed (gzipped) file. You can find it at <mountpoint>/javafx_sdk-1_0.mpkg/Contents/Packages/javafxsdk.pkg/Contents/Archive.pax.gz. Copy this file into another working directory (or wherever you want your SDK to reside. I put mine in /usr/local):
vivin@dauntless ~/working
$ cp ~/javafx/javafx_sdk-1_0.mpkg/Contents/Packages/javafxsdk.pkg/Contents/Archive.pax.gz .
vivin@dauntless ~/working
$ gunzip Archive.pax.gz
vivin@dauntless ~/working
$ file Archive.pax
Archive.pax: ASCII cpio archive (pre-SVR4 or odc)
$ cp ~/javafx/javafx_sdk-1_0.mpkg/Contents/Packages/javafxsdk.pkg/Contents/Archive.pax.gz .
vivin@dauntless ~/working
$ gunzip Archive.pax.gz
vivin@dauntless ~/working
$ file Archive.pax
Archive.pax: ASCII cpio archive (pre-SVR4 or odc)
When I gunzipped the file, I got Archive.pax, and I wasn't sure what to do with it. So I ran file on it and discovered that it was a cpio file. Some quick Googling and man-page perusal later:
vivin@dauntless ~/working
$ cpio -i <Archive.pax
65687 blocks
vivin@dauntless ~/working
$ ls
Archive.pax COPYRIGHT.html lib profiles samples src.zip timestamp
bin docs LICENSE.txt README.html servicetag THIRDPARTYLICENSEREADME.txt
vivin@dauntless ~/working
$ bin/javafx
Usage: java [-options] class [args...]
(to execute a class)
or java [-options] -jar jarfile [args...]
(to execute a jar file)
where options include:
-d32 use a 32-bit data model if available
-d64 use a 64-bit data model if available
-client to select the "client" VM
-server to select the "server" VM
-hotspot is a synonym for the "client" VM [deprecated]
The default VM is server,
because you are running on a server-class machine.
-cp <class search path of directories and zip/jar files>
-classpath <class search path of directories and zip/jar files>
A : separated list of directories, JAR archives,
and ZIP archives to search for class files.
-D<name>=<value>
set a system property
-verbose[:class|gc|jni]
enable verbose output
-version print product version and exit
-version:<value>
require the specified version to run
-showversion print product version and continue
-jre-restrict-search | -jre-no-restrict-search
include/exclude user private JREs in the version search
-? -help print this help message
-X print help on non-standard options
-ea[:<packagename>...|:<classname>]
-enableassertions[:<packagename>...|:<classname>]
enable assertions
-da[:<packagename>...|:<classname>]
-disableassertions[:<packagename>...|:<classname>]
disable assertions
-esa | -enablesystemassertions
enable system assertions
-dsa | -disablesystemassertions
disable system assertions
-agentlib:<libname>[=<options>]
load native agent library <libname>, e.g. -agentlib:hprof
see also, -agentlib:jdwp=help and -agentlib:hprof=help
-agentpath:<pathname>[=<options>]
load native agent library by full pathname
-javaagent:<jarpath>[=<options>]
load Java programming language agent, see java.lang.instrument
$ cpio -i <Archive.pax
65687 blocks
vivin@dauntless ~/working
$ ls
Archive.pax COPYRIGHT.html lib profiles samples src.zip timestamp
bin docs LICENSE.txt README.html servicetag THIRDPARTYLICENSEREADME.txt
vivin@dauntless ~/working
$ bin/javafx
Usage: java [-options] class [args...]
(to execute a class)
or java [-options] -jar jarfile [args...]
(to execute a jar file)
where options include:
-d32 use a 32-bit data model if available
-d64 use a 64-bit data model if available
-client to select the "client" VM
-server to select the "server" VM
-hotspot is a synonym for the "client" VM [deprecated]
The default VM is server,
because you are running on a server-class machine.
-cp <class search path of directories and zip/jar files>
-classpath <class search path of directories and zip/jar files>
A : separated list of directories, JAR archives,
and ZIP archives to search for class files.
-D<name>=<value>
set a system property
-verbose[:class|gc|jni]
enable verbose output
-version print product version and exit
-version:<value>
require the specified version to run
-showversion print product version and continue
-jre-restrict-search | -jre-no-restrict-search
include/exclude user private JREs in the version search
-? -help print this help message
-X print help on non-standard options
-ea[:<packagename>...|:<classname>]
-enableassertions[:<packagename>...|:<classname>]
enable assertions
-da[:<packagename>...|:<classname>]
-disableassertions[:<packagename>...|:<classname>]
disable assertions
-esa | -enablesystemassertions
enable system assertions
-dsa | -disablesystemassertions
disable system assertions
-agentlib:<libname>[=<options>]
load native agent library <libname>, e.g. -agentlib:hprof
see also, -agentlib:jdwp=help and -agentlib:hprof=help
-agentpath:<pathname>[=<options>]
load native agent library by full pathname
-javaagent:<jarpath>[=<options>]
load Java programming language agent, see java.lang.instrument
As you can see, you now have a working JavaFX 1.0 SDK on your Linux box!
4 comments:
Add a comment:
All images and text on this site: Copyright © Vivin Suresh Paliath. All Rights Reserved.
On thursday, december 04, 2008 at 10:14 PM UTC, Dave said:
On friday, december 05, 2008 at 7:01 AM UTC, Remon Sinnema said:
On wednesday, april 29, 2009 at 1:45 PM UTC, Mike said:
mount -o loop,offset=$((1024*17))
On thursday, april 30, 2009 at 9:10 AM UTC, vivin said:
Thanks a lot for that info! It worked a lot. I was wondering why the dmg didn't mount as before with the 1.1 image.