On Sunday 09 October 2005 03:50 am, Steve Graegert wrote:

On 10/9/05, B. Stia wrote:

...

Hello SuSE people.

I visited the Sun site tonight and saw a download that was titled AMD64.

http://java.com/en/download/manual.jsp

Could this be the 64 bit java we have been waiting for? Or, am I just mis-interpreting it. I downloaded it tonight, built the rpm and looked inside. Didn't really see anything that looked like 64 bit. ????

How does 64-bit Java look like? You will not be able to destinguish between 32-bit and 64-bit java. If both versions should exist side by side just download the self-extracting version (contains the file jre-1_5_0_04-linux-amd64.bin) and provide a custom installation directory (i.e. /usr/lib/java5_64) during setup.

Welllll.... you are correct. What DOES it look like? Hmmm how do we know? Is this 64 bit or is it not ??? Created a unique /opt/java directory where the source was placed and the rpm was built and resides. (just in case there needed to be two versions) But, the rpm decided to install itself to /usr/java. (which I don't know whether it existed before that, or is new, or if it did exist- overwrote the older version AND then, is it 64 bit or not? And, if it truly is 64 bit, where are the (whatever their names are) .so & .a files which need to be linked to Firefox to make it work??? Frustrating stuff. No better off than when I started this drill. Anybody else get java working in 64 bit mode or am I trying to be a pioneer here? Bob S.

On Monday 10 October 2005 01:47 am, Steve Graegert wrote:

On 10/10/05, B. Stia wrote:

...

On Sunday 09 October 2005 03:50 am, Steve Graegert wrote:

Welllll.... you are correct. What DOES it look like? Hmmm how do we know? Is this 64 bit or is it not ???

What gives 'java -d64 -server -version'? You should see something like

% java -d64 -server -version java version "1.4.2_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04) Java HotSpot(TM) 64-Bit Server VM (build 1.4.2_05-b04, mixed mode)

If you get the "ERROR: no 'server' JVM at..." error, just omit the -server switch. If 64-bit it will not recognize the -d64 switch. Additionally, check your path (to make sure you're running the correct version) and/or try to install the default package, not the RPM. You can then decide where to put the Java binaries.

Steve, I used the rpm.bin because I wanted to keep my rpm database correct. Guess I could do that though.

Hope we get this issue solved soon.

You would be enlightening lots and lots of people, all dealing with the 32 bit stuff for Mozilla/Firefox 64 bit versions Here is my output: bob@EasyStreet:~> java -d64 -server -version Unrecognized option: -d64 Could not create the Java virtual machine. (took out the -d64 option) bob@EasyStreet:~> java -server -version java version "1.4.2_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Server VM (build 1.4.2_08-b03, mixed mode) As previously stated the rpm installed jre1.5.0_04 into /usr/java. No plugins directory in there though. Guess I just need to wait. Bob S.

Hi, On Tuesday 11 October 2005 00:38, Steve Graegert wrote:

...

It seems that you have not invoked the correct version. Java 2 version 1.4.2 is not the same as Java 5 version 1.5. Please check your path or installation and try again. Anyway, if the d64 switch is not understood, this particular version does not support 64-bit applications. The output should be something like the following:

% java -d64 -version -server java version "1.6.0-ea" Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b11) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-ea-b11, mixed mode)

Or, for those of us with 32-bit systems, this: % java -version java version "1.5.0_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07) Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode, sharing) % java -d64 Running a 64-bit JVM is not supported on this platform. Equivalently (for the default /etc/alternatives configuration): % /usr/lib/jvm/java-1.5.0-sun/bin/java -version java version "1.5.0_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07) Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode, sharing) % /usr/lib/jvm/java-1.5.0-sun/bin/java -d64 Running a 64-bit JVM is not supported on this platform. Invoking the earlier 1.4.2 version: % /usr/lib/jvm/java-1.4.2-sun-1.4.2.06/bin/java -version java version "1.4.2_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) % /usr/lib/jvm/java-1.4.2-sun-1.4.2.06/bin/java -d64 Unrecognized option: -d64 Could not create the Java virtual machine.

...

\Steve

Randall Schulz

On 10/16/05, B. Stia wrote:

On Tuesday 11 October 2005 03:58 am, Randall R Schulz wrote:

...

Hi,

On Tuesday 11 October 2005 00:38, Steve Graegert wrote:

...

...

It seems that you have not invoked the correct version. Java 2 version 1.4.2 is not the same as Java 5 version 1.5. Please check your path or installation and try again. Anyway, if the d64 switch is not understood, this particular version does not support 64-bit applications. The output should be something like the following:

% java -d64 -version -server java version "1.6.0-ea" Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b11) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-ea-b11, mixed mode)

Yes Steve, Thank you. That is known and completely understood. Now, please have patience and compassion for your fellow dense unknowlegeable SuSE Linux users. It seems that Suse has installed java in very different places than where the actual java files (from Sun) are installed, otherwise wouldn't the newer version overwrite the older version?

Something I also don't understand. It could be so easy: one Java, one place. Another Java, another place. No need for horrible mixing and linking of files and diretories. (That's why I _always_ replace the Java installation completely.)

I added the PATH to /usr/java (for the new 64 bit version) and it still does not show the newer version. Wouldn't the -version command show either the newer one of at least both? Actually I prefer that both versions exist, the new one only to serve Firefox and the older to continue doing whatever it does.

Unfortunately, there is no 64-bit plugin for Mozilla-based browsers available from Sun. The reason is that there are no official 64-bit distributions of Mozilla and Firefox, although most distributions, namely SuSE and Ubuntu, repackage them (this is what Sun says). The only JDK/JRE with a plugin on board is the Blackdown distribution.

Now, the newer downloaded verion from Sun is actually 64 bit according to the -version command, but, it does not have the plugins for Mozilla/Firefox. So I went and got the Blackdown version. It is also a 64 bit version and does have the plugins for Mozila/Firefox. (which I added to the Firefox plugins section) But, even though it shows as a 64 bit version the -d64 command shows it as unsupported ????? (See below for the actual output of the commands)

I've never used Blackdown Java and my hints were related to Sun's JDK.

...

Or, for those of us with 32-bit systems, this:

Thanks Randall, for your input. You taught me about all of the crazy links in java and showed me how I was able to get the version and options by directly accessing the file. See the results of my commands below.

...

% java -version java version "1.5.0_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07) Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode, sharing)

% java -d64 Running a 64-bit JVM is not supported on this platform.

Equivalently (for the default /etc/alternatives configuration):

% /usr/lib/jvm/java-1.5.0-sun/bin/java -version java version "1.5.0_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07) Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode, sharing)

% /usr/lib/jvm/java-1.5.0-sun/bin/java -d64 Running a 64-bit JVM is not supported on this platform.

Invoking the earlier 1.4.2 version:

% /usr/lib/jvm/java-1.4.2-sun-1.4.2.06/bin/java -version java version "1.4.2_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)

% /usr/lib/jvm/java-1.4.2-sun-1.4.2.06/bin/java -d64 Unrecognized option: -d64 Could not create the Java virtual machine.

Here are the results of my commands of the two new versions that I have installed: ---------------------- bob@EasyStreet:~> /opt/java/j2re1.4.2/bin/java -version java version "1.4.2-02" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-02) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-02, mixed mode)

This is not Sun's Java Runtime.

bob@EasyStreet:~> /opt/java/j2re1.4.2/bin/java -d64 Unrecognized option: -d64 Could not create the Java virtual machine.

As stated above, Blackdown Java obviously does not support selective data models. Sun does.

Question: Now if this a 64 bit version, why does it not recognize the d64 option?? Also, remember now, that this is the only version I have found that has the plugins for Firefox.

This plugin can be used with Firefox (if Firefox is not 32-bit, of course).

EasyStreet:/ # /usr/java/jre1.5.0_04/bin/java -version java version "1.5.0_04" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_04-b05, mixed mode)

Looks good :-)

EasyStreet:/ # /usr/java/jre1.5.0_04/bin/java -d64 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 -server to select the "server" VM The default VM is server.

-cp -classpath 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 EasyStreet:/ # ------------------------------------- Now, this seems like it should work, has all the requisites, except it does NOT have the plugins directory for MozillaFirefox!! Is it that there are now 64 bit versions but no plugins?? (clueless)

Unfortunately, yes: no plugins for 64-bit Java from Sun.

Sigh!! I guess that it is still not possible ! Guess I will just have to wait or revert to a 32 bit Firefox. Getting frustrating.

You should be able to use the 64-bit plugin from Blackdown Java instead.

Question: Flash is a completly separate issue, right?

Don't know, but I suppose you're right. Until now, there does not seem to be a 64-bit version. \Steve

On Sun, Oct 16, 2005 at 06:24:42AM -0700, Randall R Schulz took 40 lines to write:

Ben,

On Saturday 15 October 2005 23:52, B. Stia wrote:

[ Lots and of details about his Java installation elided. ]

I agree the whole Java situation is a bit of a mess, right now. The whole /etc/alternatives "switchboard" concept was probably not its inventor's finest hour, either.

It does seem rather fragile.

What I'm not sure I get is why you place so much importance on the 64-bit plug-ins. Unless you use sites with plug-ins extensively, why don't you just switch to a 32-bit browser for those times when you need to run an applet. I don't think you'll notice much difference in the performance of the Java code between the 32-bit and 64-bit versions.

Because switching back and forth like that would quickly become rather a PITA. My 64-bit system is considerably more responsive than any 32-bit box I've ever used, an experience I want to continue.

My general impression is that 64-bit systems are still not as well supported as desktops as are the fare more mature 32-bit ones. I'm

I've certainly enjoyed mine, niggling issues notwithstanding. Kurt -- After an instrument has been assembled, extra components will be found on the bench.

On Sunday 16 October 2005 09:24 am, Randall R Schulz wrote:

Ben,

On Saturday 15 October 2005 23:52, B. Stia wrote:

[ Lots and of details about his Java installation elided. ]

I agree the whole Java situation is a bit of a mess, right now. The whole /etc/alternatives "switchboard" concept was probably not its inventor's finest hour, either.

What I'm not sure I get is why you place so much importance on the 64-bit plug-ins. Unless you use sites with plug-ins extensively, why don't you just switch to a 32-bit browser for those times when you need to run an applet. I don't think you'll notice much difference in the performance of the Java code between the 32-bit and 64-bit versions.

Randall, Wellll.....you are absolutely correct. No doubt about it. Main reason is that I am pig-headed and stubborn, and once I move forward I do not like to retreat. Guess what I will do is see if the Blackdown plugins work or just wait it out for Sun.

My general impression is that 64-bit systems are still not as well supported as desktops as are the fare more mature 32-bit ones. I'm thinking of getting a 64-bit system, mostly just for experimentation and experience purposes and to see what kind of performance increases they provide for compute-intensive applications like my theorem prover (written in Java, in fact).

I think you will like the performance increase for your basic OS. Most apps work just fine (with the exception of 64 bit Mozilla/Firefox) of course. Thanks Steve and Randall for all or your trouble, insight, expertise, etc. It helps knowing what the guru's on this list think and that it is not just my ineptitude or ignorance. Makes me feel better about these small niggling things. Bob S.