Help me!! Why java is so popular

[raddog58c]

I have seen huge differences for Java just between running with

-client and -server.

Arne

Which has seemed to be better, and do you understand what is making
the difference?

I do wish there were better built-in JVM hooks for extracting what's
going on inside.... aren't "they" (JVM peeps) standardizing on some
such things? It would sure help, because "unit" tuning is fine if
you're wearing blinders, but if you're not careful you can make one
thing run like a bat out of hades and in turn impact everything else
that lives in the same space.

Tuning and better JVM diags/stats is an area of great opportunity,
IMHO.

 

[raddog58c]

Using Unicode whether encoded as UTF-16 or UTF-8 eliminates a whole
world of pain the moment you see a character outside your current
character set. If you never see anything outside traditional ASCII then
you may not appreciate this. I'd be very happy to see all the
traditional character sets disappear (CP-437, etc), leaving only the
Unicode encodings. I've had data sent to me without any declaration of
the character set in use and had to guess on the basis of the words
contained. One case I never did figure out --- it had probably been
mangled by other software that didn't understand the character set.

A simple example here with traditional software is what happens to our
currency symbol (£, pounds sterling) if you mix up code pages.

Earlier you mentioned the doubling of space caused by Unicode (assuming
UTF-16). This is only valid if most of your memory was taken up by text.
The only applications where this is likely to be true (word processors
and the like), ought to be capable of handling a wider range of
characters than ASCII. Even writing in English, I want a generous range
of mathematical symbols available (I am a mathematician).

Mark Thornton

That's completely valid....

....if you need it. It's not valuable if you don't.

I pay a lot of money for cable and HBO television which would be a
waste if I didn't own a TV.

Also, while it is a pain to convert when you have to, it's just as
much of a pain to convert when you don't feel you need to --
getChars() is a pain because I don't need anything by chars 99% of the
time in the particular code I'm writing.

Your mileage may vary, and that's where having an option suits both
needs.

 

[Mark Thornton]

One thing that's different between C++ and Java is memory. I believe
the JVM grabs everything it will ever need at startup

It reserves the address space for the maximum heap size but only
allocates memory for the minimum heap size. The reservation means it can
be sure that the heap will be contiguous which gives performance
advantages to the implementation. One downside to this is that memory
reports by OS utilities can be incredibly confusing (i.e. useless).

Mark Thornton

 

[Mark Thornton]

Any thoughts on this line of thinking? Am I being "old school" in
wanting a primitive String, or do many think the same way? IMO
creating scalar-like base classes in the spirit of String that are
contain everything but the kitchen sink AND are final seems like the
wrong way to factor down and implement that functionality.

Thoughts?

String has to be final and immutable for security reasons. As it is
final it is convenient to have many useful methods as members of the
class (especially as static import is only a very recent addition).

Mark Thornton

 

[Mark Jeffcoat]

Which has seemed to be better, and do you understand what is making
the difference?

I do wish there were better built-in JVM hooks for extracting what's
going on inside.... aren't "they" (JVM peeps) standardizing on some
such things? It would sure help, because "unit" tuning is fine if
you're wearing blinders, but if you're not careful you can make one
thing run like a bat out of hades and in turn impact everything else
that lives in the same space.

Tuning and better JVM diags/stats is an area of great opportunity,
IMHO.

You may be looking for the JVMTI--the "JVM Tool Interface".

It's not something I've looked into, since the simplest
of profiling has so far sufficed for me, but it offers
an extremely detailed look at what's going on under the
hood.

http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html

 

[raddog58c]

It reserves the address space for the maximum heap size but only
allocates memory for the minimum heap size. The reservation means it can
be sure that the heap will be contiguous which gives performance
advantages to the implementation. One downside to this is that memory
reports by OS utilities can be incredibly confusing (i.e. useless).

Mark Thornton

Not really useless. Whatever the JVM has set aside is not available
to processes which run under the auspices of the OS but not the JVM.
Some JVM boosts are misleading because they turbo charge their
applications but impact others running in the same storage space.
That's a point that's missed by applications programmers in some
performance comparisons -- it's not missed by systems programmers,
however, because the OS is managaging all active processes, the JVM
being nothing more than one of them.

Now if your machine runs purely for the sake of the JVM, like a
webserver for instance, then I agree that the JVM's use of memory is
misleading, because what it's done is establish the best-fit operating
environment for itself, and that's what you want on something like a
webserver.

Conversely, on something like your workstation where you'll
(presumably) be using a mix of apps each running in their own process
space, resource hungry processes and threads hurt system performance
because they greedily suck up everything around them.

That's not bad -- it's how it works, and one needs to be consciously
aware of the effects so they don't get burned by them.

 

[raddog58c]

Thoughts?

String has to be final and immutable for security reasons. As it is
final it is convenient to have many useful methods as members of the
class (especially as static import is only a very recent addition).

Mark Thornton

I see -- thanks for explaining that. What about a heirarchy of
progressively more functional String classes? Would you see that as a
good or bad thing? I think it would be good, but I may be missing a
piece of important fundamental understanding about the security issues.

 

[Mark Thornton]

Not really useless. Whatever the JVM has set aside is not available
to processes which run under the auspices of the OS but not the JVM.

A reservation has no effect on other processes. It simply reserves a
range of addresses within the JVM's process. It makes no difference to
the amount of memory available to other processes. Note that what has
been reserved is ADDRESS SPACE, which is not the same thing as memory.
When the heap needs to expand, additional memory will be mapped into
that reserved space.

Mark Thornton

 

[Mark Thornton]

I see -- thanks for explaining that. What about a heirarchy of
progressively more functional String classes? Would you see that as a
good or bad thing? I think it would be good, but I may be missing a
piece of important fundamental understanding about the security issues.

The class that you use for a string in any context that might have
security implications has to be final and immutable. This doesn't leave
much room for a heirarchy. Security is relevant in many places such as
specifying urls and file names. You don't want to have to use some
special string in such cases.

Mark Thornton

 

[raddog58c]

A reservation has no effect on other processes. It simply reserves a
range of addresses within the JVM's process. It makes no difference to
the amount of memory available to other processes. Note that what has
been reserved is ADDRESS SPACE, which is not the same thing as memory.
When the heap needs to expand, additional memory will be mapped into
that reserved space.

Mark Thornton

I used to do capacity planning and performance monitoring of our
webservers. We used IBM's Websphere App Server and HTTP Server. One
thing I noticed was CPU usage would fluctuate greatly, but memory
usage was level. It seemed to me the JVM grabbed all the memory it
was configured to start with at the time it started and never
reliquished it, meaning it was not available to any other processes on
the server.

Is there an option to have the JVM startup with a tiny heap and
dynamically expand and shrink it if needed? I don't know one way or
the other to be honest, but if there is we weren't using it in our
environment. The JVM carved its space and never moved in one direction
or another over its lifetime.

 

[raddog58c]

The class that you use for a string in any context that might have

security implications has to be final and immutable. This doesn't leave
much room for a heirarchy. Security is relevant in many places such as
specifying urls and file names. You don't want to have to use some
special string in such cases.

Mark Thornton

I suppose, but you don't have the same kind of security restraints
with a char array, for instance, but you can basically store the same
kind of data (URLs, passwords, etc) in a char array as you can a
String. (shrug) So at least on the surface it doesn't seem like a
very fool-proof security provision.

 

[Chris Uppal]

My impression of String is that it was a design snafu in a way. It's
used like a scalar, but it's a very PHAT class. My initial (and
continuing) impression with String is that it's too heavyweight for
its place in the Java coding food chain.

I think it would have been a better design for String to have been the
minimum number of features for a string of base characters. In
essence the strcats, strlens, touppers etc that most pre-Java
programmers became intimate with early on.

java.util.String has become a bit confused. I have nothing against fat classes
myself (I think most Java programmers -- and especially Sun's programmers --
tend to create anorexic classes, leading to a loss of OO structure in the
client code), but I don't think String's collection of methods has a sense of
/policy/ about it -- it's just whatever has happened to end up there over the
years.

something, which included other features embedded in what is the
current String class. Upon that could have come a MultiLingualString
or UniString or whatever.

But one thing I definitely don't agree with is that we need (or should even
want) two kinds of Stings where one is Unicode and the other is... well, what
is it ? What would the non-Unicode "string" represent ? Binary data can be
handled just fine with byte[] arrays and binary streams, but what would an
8-bit text class look like ? Would each instance hold some binary data and a
reference to the character-encoding used for that data ?

Or would it be like C's char* -- just a trap for the unwary ?

It's also inconvenient that String is declared final.

I agree. There should have been a split between the abstract concept of a
Sting, and the various plausible physical representations of the data contained
in the String. (E.g. UTF16String, UTF8String, CompressedString, Rope....)
Mark has mentioned that String is final for security reasons -- and he is
correct -- but I think the security requirements could have been met with a
less limited and limiting architecture.

-- chris

 

[Chris Uppal]

The class that you use for a string in any context that might have
security implications has to be final and immutable. This doesn't leave
much room for a heirarchy. Security is relevant in many places such as
specifying urls and file names. You don't want to have to use some
special string in such cases.

Why not ? It seems reasonable to me that an API /might/ specify, say,
ImmutableString as its parameter type. If so then the user would have to use
code like

someAPI(myMutableString.safe());

which doesn't seem like much of a problem when you consider that

(a) There aren't that many APIs which need that level of safety.

(b) Many apps would be working with ImmutableStings anyway
(e.g. string literals, and strings returned from various query APIs,
such as filenames)

(c) If the ImutableString API is too onerous for the users, then the class
can overload the method with both forms:
public boolean
someAPI(String string)
{
return someAPI(string.safe());
}
public boolean
someAPI(ImmutableString string)
{
... real work here...
}


Was it really sensible to hobble the text-handling features of Java just in
order to save the authors of the (relatively few) safety-concious APIs the
effort of making copies of the input strings ?

This is also the point at which I trot out my complaint that the over-rigid
Java String API make it difficult to police the use of "tainted" (assembled
from user-supplied data) strings to create SQL commands and the like.

-- chris

 

[Chris Uppal]

I used to do capacity planning and performance monitoring of our
webservers. We used IBM's Websphere App Server and HTTP Server. One
thing I noticed was CPU usage would fluctuate greatly, but memory
usage was level. It seemed to me the JVM grabbed all the memory it
was configured to start with at the time it started and never
reliquished it, meaning it was not available to any other processes on
the server.

It's quite possible that IBM's server-class JVM implementations use memory in a
very different pattern from how Sun's desktop-class JVM implementations do.
(Especially when you remember that both Sun and IBM are in the business of
selling big iron ;-)

It makes (in my opinion) a lot of sense for a JVM running a server to grab
actual memory at startup. That would make no sense at all for a JVM used for
running desktop applications where (a) the demand is much less predictable, and
(b) there is unlikely to be someone around with the skill and time to tune each
application separately.

That said, I do think Sun's desktop implementations are less flexible in this
respect than they should be.

-- chris

 

[Mark Thornton]

Is there an option to have the JVM startup with a tiny heap and
dynamically expand and shrink it if needed? I don't know one way or

Yes. Although this depends on the JVM in question. For Sun's JVM the
option -Xms is used to specify the minimum heap size. For example -Xms4m
would give a 4MB minimum heap size. Similarly -Xmx specifies the maximum
heap size. The minimum permitted heap size is 1MB. Within the min/max
limits the heap will grow and shrink as required, although it doesn't
always shrink as quickly as might be desirable.

It may be that your web server system configured the JVM with a high
minimum value for the heap (possibly even equal to the maximum value).
It is quite common to do this with server type applications --- e.g. you
can specify a minimum value for SQL Server to grab.

Mark Thornton

 

[Mark Thornton]

I suppose, but you don't have the same kind of security restraints
with a char array, for instance, but you can basically store the same
kind of data (URLs, passwords, etc) in a char array as you can a
String. (shrug) So at least on the surface it doesn't seem like a
very fool-proof security provision.

You can only pass String to security critical methods. If String was
mutable or not final then untrusted code could breach security by
passing a value that was permitted (and thus passed any check) and then,
while the method was still in progress, modify the value (from another
thread) to refer to a resource that should have restricted access.
Obviously this approach depends on timing --- the change has to take
place after the value has been checked but before it is used.

Mark Thornton

 

[Mark Thornton]

Why not ? It seems reasonable to me that an API /might/ specify, say,
ImmutableString as its parameter type. If so then the user would have to use
code like

someAPI(myMutableString.safe());

which doesn't seem like much of a problem when you consider that

(a) There aren't that many APIs which need that level of safety.

There are quite a few more that use String because it is thread safe.
I'd agree that the string classes could have been better, but I don't
think it is quite as simple as it first appears to find that better set.
It would have been better had CharSequence appeared earlier than it did.

Mark Thornton

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Which has seemed to be better, and do you understand what is making
the difference?

-server is optimizing better than -client at the cost of
more time spend JIT compiling.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

So do you suppose this was a case where late binding made the
difference, or do you think Java's implementation of whatever is used
by the aforementioned algorithm is significantly better?

My guess is that it is a case of where the C++ compiler were not
able to effectively optimize a certain language construct.

Sometimes weird effects pop up.

Some people have found that:

x ^= true;

is faster than:

x = !x;

in Java.

WTF

One thing that's different between C++ and Java is memory. I believe
the JVM grabs everything it will ever need at startup,

Not true. It startup with a certain value and expand as needed
up to the maximum allowed.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I used to do capacity planning and performance monitoring of our
webservers. We used IBM's Websphere App Server and HTTP Server. One
thing I noticed was CPU usage would fluctuate greatly, but memory
usage was level. It seemed to me the JVM grabbed all the memory it
was configured to start with at the time it started and never
reliquished it, meaning it was not available to any other processes on
the server.

Is there an option to have the JVM startup with a tiny heap and
dynamically expand and shrink it if needed? I don't know one way or
the other to be honest, but if there is we weren't using it in our
environment. The JVM carved its space and never moved in one direction
or another over its lifetime.

Yes.

-Xms<size> Set initial Java heap size
-Xmx<size> Set maximum Java heap size

But if the machine is dedicated to only run WAS they may
likely have set both to about 3/4 of the total memory.

Arne