java -version

F

Francesco

Hi
How can I find the version of the java that is invoked by an applet
from browser?
Which is the difference between java -version and the version viewed
in the Java console from browser (they are not the same) ?
Thanks
Bye
 
T

Thomas Kellerer

Francesco, 06.05.2008 13:04:
Hi
How can I find the version of the java that is invoked by an applet
from browser?
System.getProperty("java.version") or
System.getProperty("java.runtime.version") (a bit more detailed)
Which is the difference between java -version and the version viewed
in the Java console from browser (they are not the same) ?

Most probably "java -version" uses a different JDK because it is in the system path.
Check your PATH environment

Thomas
 
T

Thomas Fritsch

Francesco said:
How can I find the version of the java that is invoked by an applet
from browser?
An applet can get it by System.getProperty(....). See
Which is the difference between java -version and the version viewed
in the Java console from browser (they are not the same) ?
I guess you installed more than one Javas.
When calling "java ..." from command-line you get the one found through
your PATH environment variable.
When running an applet in a browser you get the one configured in your
"Java Control Panel".
 
F

Francesco

An applet can get it by System.getProperty(....). See


I guess you installed more than one Javas.
When calling "java ..." from command-line you get the one found through
your PATH environment variable.
When running an applet in a browser you get the one configured in your
"Java Control Panel".

Ok
But I cannot access to Java Control Panel...
Can I access to it from Command prompt?
 
C

Chase Preuninger

In IE got to tools -> Java Sun Console and when it opens it says at
the top.
 
A

Arne Vajhøj

A

Arne Vajhøj

Lew said:
Web-page URLs aren't case sensitive. The first version does not result
in a 404 from here.

They can be. They have to. Imagine a *nix based web server with A.html
and a.html with different content.

Arne
 
A

Arne Vajhøj

Wayne said:
The host name part of a URL isn't case sensitive, but rest is
including the filename. Some web servers will match in a case-
insensitive way if some option is on. (mod_speling in Apache,
MS IIS by default.)

It is completely server specific whether it is case sensitive
or not.

Default (no special options) would likely be case sensitive
on case sensitive file systems and not case sensitive on
non case sensitive file systems. You can always count on
developer laziness.

Arne
 
O

Owen Jacobson

It is completely server specific whether it is case sensitive
or not.

Default (no special options) would likely be case sensitive
on case sensitive file systems and not case sensitive on
non case sensitive file systems. You can always count on
developer laziness.

Arne

Per the semantics defined in RFC 2616, the path part of an HTTP URL is
intended to be case sensitive regardless of server behaviour:

3.2.3 URI Comparison

When comparing two URIs to decide if they match or not, a client
SHOULD use a case-sensitive octet-by-octet comparison of the entire
URIs, with these exceptions:

- A port that is empty or not given is equivalent to the default
port for that URI-reference;

- Comparisons of host names MUST be case-insensitive;

- Comparisons of scheme names MUST be case-insensitive;

- An empty abs_path is equivalent to an abs_path of "/".

Well, okay, it is a "SHOULD" and not a "MUST". However, many
important pieces of software, including caching proxies and most
search engines, will treat URLs that differ by case as being distinct
resources. Google, for example, will assign pagerank to both
resources separately, and squid will cache both separately.

This shows up in other places URLs are used: XML Namespaces that are
identified by a URL are completely case-sensitive, even within the
host portion, for example. In general, unless you have specific
knowledge of the URL scheme in use, it's best to assume that URLs are
case sensitive even if the software that's interpreting them isn't.

-o
 
A

Arne Vajhøj

Owen said:
Per the semantics defined in RFC 2616, the path part of an HTTP URL is
intended to be case sensitive regardless of server behaviour:

3.2.3 URI Comparison

When comparing two URIs to decide if they match or not, a client
SHOULD use a case-sensitive octet-by-octet comparison of the entire
URIs, with these exceptions:
Well, okay, it is a "SHOULD" and not a "MUST".

Even if it had been "MUST" then it had not mattered.

They keyword is *client*.

If it is allowed for a server to have case sensitive path, then the
client should/must consider it case sensitive.

You can not conclude that it should/must or is intended to be
case sensitive on the server.
This shows up in other places URLs are used: XML Namespaces that are
identified by a URL are completely case-sensitive, even within the
host portion, for example.

Which violates the section you just quoted.
In general, unless you have specific
knowledge of the URL scheme in use, it's best to assume that URLs are
case sensitive even if the software that's interpreting them isn't.

That is good advice. But it is still not case sensitive.

Arne
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top