Help me!! Why java is so popular

  • Thread starter amalikarunanayake
  • Start date
A

amalikarunanayake

java has become an important language in very short time. What are
some of the things that have made it so popular?
 
E

Eric Sosman

java has become an important language in very short time. What are
some of the things that have made it so popular?

One point in Java's favor is that it's a pretty good
teaching language. It protects the still-inept student from
many kinds of beginners' mistakes, but doesn't coddle him to
the point of cocooning. You can test this claim for yourself
by taking a Java-based class and doing the homewo--

Oh. Wait; I get it.
 
A

Alex Hunsley

java has become an important language in very short time. What are
some of the things that have made it so popular?


Java is important because lazy/cheating students can take classes in
this language and not have to look far for someone to do their homework
for them.
 
J

Jack Kielsmeier

java has become an important language in very short time. What are
some of the things that have made it so popular?

One of the biggest reasons JAVA has taken off, is its ease of portability.
When an application is written in a language like C or C++, it must be
compiled separately for each platform that will run your application.



Java has a virtual machine that is able to take JAVA code information and
translate it to the specific machine running the application on the fly. It
makes it so you do not have to re-compile the application for every
platform.



There are some downsides to this; JAVA is generally slower than a language
like C++ because of the extra time needed by the Virtual Machine. With how
fast computers are today, most people do not care about the performance
penalty in their applications (the penalty is usually pretty small now).
 
D

Daniel Pitts

java has become an important language in very short time. What are
some of the things that have made it so popular?

Mostly because of the large community that surrounds it, and all of
the easily-used-but-powerful libraries available for it.
 
A

Alex Hunsley

Jack said:
One of the biggest reasons JAVA has taken off, is its ease of portability.
When an application is written in a language like C or C++, it must be
compiled separately for each platform that will run your application.



Java has a virtual machine that is able to take JAVA code information and
translate it to the specific machine running the application on the fly. It
makes it so you do not have to re-compile the application for every
platform.



There are some downsides to this; JAVA is generally slower than a language
like C++ because of the extra time needed by the Virtual Machine. With how
fast computers are today, most people do not care about the performance
penalty in their applications (the penalty is usually pretty small now).

Whoo! That's him got off without having to do his homework!
lex
 
R

Randolf Richardson

java has become an important language in very short time. What are
some of the things that have made it so popular?

Because Scott McNealy mooned a picture of Bill Gates.
 
J

John W. Kennedy

java has become an important language in very short time. What are
some of the things that have made it so popular?

Over against compiled languages:

Less occult than C++.

Portable in the language itself.

Portable in the library.

Portable GUI with native look-and-feel.

Comprehensive library off the shelf.

Threading well defined in the language.

Decimal arithmetic available.

Over against interpreted and bytecoded languages:

Performance (after startup).

Threading well defined in the language.

Really cool IDEs, such as Eclipse, available in part as a result of
comprehensive introspection features.

JavaDoc.

JARs.

Microsoft dislikes it, and tried unsuccessfully to poison it.
 
R

Randolf Richardson

On Sun, 04 Feb 2007 19:10:23 -0800, John W. Kennedy

[sNip]
Microsoft dislikes it, and tried unsuccessfully to poison it.

That's one of my favourite reasons, which demonstrates how strong Java's
position in the marketplace really is.
 
R

raddog58c

One of the biggest reasons JAVA has taken off, is its ease of portability.
When an application is written in a language like C or C++, it must be
compiled separately for each platform that will run your application.

I think a big reason Java took off initially was the fact it's a C-
language derivative without pointers. Most of the Java programmers I
knew 10 years ago were disillusioned C/C++ people who found the memory
management tedious and error prone. The fact they could instantiate
and code and never clean up after themselves freed them to concentrate
on the problems they really wanted to expend their energy solving.

The reason people would get into Java coding today probably has little
to do with this and is due more to the language's large base of highly
functional classes that plug-n-play easily, so programmers can slam
dunk applications a lot easier. It's all about what's easy for us
(programmers), eh?
Java has a virtual machine that is able to take JAVA code information and
translate it to the specific machine running the application on the fly. It
makes it so you do not have to re-compile the application for every
platform.

Certainly true, though the same can be said for Perl and while it's
pretty popular, it's not as popular as Java. Partly that's due to Perl
being totally interpreted versus half-ways compiled (ie, byte code),
and let's face it, Perl isn't really a full-fledged programming
language.

The other thing that's perhaps a side effect from this paradigm is
that Java provides mostly least-common-denominator system services.
For instance, someone was asking me about checking for an already-
running instance of a program on a Windows workstation. That's a
really easy thing to implement in any language that can talk directly
to the OS -- about 15 lines of code invoking EnumWindows.

You can't do that in Java, however, unless you go JNI. That's not
necessarily a bad thing, however. You lose some OS-locale-based fine-
tuned features, but on the flip side when you grab someone's class
libs off a web site you have almost no work to do to use them,
regardless of what OS you're using. That's a pretty compelling
attraction for agile programming.
There are some downsides to this; JAVA is generally slower than a language
like C++ because of the extra time needed by the Virtual Machine. With how
fast computers are today, most people do not care about the performance
penalty in their applications (the penalty is usually pretty small now).

I would say "the penalty is usually pretty small now" is very context
sensitive. Not to pick on you personally, but the general embracing
of the "memory is cheap" or "performance is good enough" is popular in
the Java community, and it's wrong to me. Maybe that's because I use
everything from MASM to IBM 370 BASM to C, C++, Java, VB and Perl, not
sure...

But I would never, or at least rarely, use Java for desktop utilities
I create for myself because the startup time is dreadfully slow, and
the impact on other applications is large. If you're running a system
with a GIG or less of RAM, firing up a memory-hungry JVM isn't
something you do hastily. Run something like Process Explorer (http://
www.microsoft.com/technet/sysinternals/ProcessesAndThreads/
ProcessExplorer.mspx) and look at the responsiveness of the UI. You
can tune Java apps all day and you simply can't get that without ultra
high-speed hardware.

I can start Java apps on my 3GHz Pentium and the drain on the system
is highly noticable. I'll have periods where the system is completely
unresponsive to mouse clicks, or the mouse pointer icon lumbers across
the screen. Shut down those apps and the system returns to the
standard Windows response (which is still barely tolerable, but at
least it's better). I could probably do some tuning to counteract
that, but that defeats the purpose of writing quick-n-dirty utilities
to rapidly perform some function.

I think of Java programs like driving a Winnebago. For comfort and
ease of travel it's hard to beat, especially on long trips where you
want lots of room and comfort and not have to deal with meticulous
details like where to set your full coffee cup or worrying about where
to toss your trash -- most of these are taken care of you by the
environment.

For quick trips around town, negotiating road space during rush hour,
or for parallel parking on crowded city streets it's overkill and
difficult to maneuver.

I always have felt the Java language is superlative, but the Java
runtime model is gluttonous, and that two things would greatly help
Java, IMO:

1) Optional override on storing data as unicode: why pay for something
if you don't need it? Unicode is great if you need multinational
support, but in 27 years of programming I've maybe needed that in two
applications. Converting data back and forth when I don't need it is
like paying for a cable TV subscription for your home when you are a
traveling salesman who's on the road 7 days a week. Wasing
computational energy degrades responsiveness of programs running in
the JVM as well as programs running in the system outside of the
JVM.

2) Optional override on garbage collection: If I don't want garbage
collection, or I want to decide when it is going to run, then I want
to control it. Garbage collection makes things "safe," but not all of
us need that safety. I've written OS's from the ground up, so I'm
totally comfortable in my memory mgmt skills. When I'm trying to
streamline processing, spurious threads I didn't start are problematic
and get in the way. I like having control when I program, and there
are times I don't want GC and it'd be nice to shut if off.

These things degrade the Java footprint, IMO. Many purist Java-only
programmers will say things like "memory is cheap" or "with the
current speed of CPUs" etc. But that's a really bad philosophy and a
cop out. It's insensitive to optimization, basically pretending
response time and memory footprints are of little importance.
Memory's cheap if you already bought it and it's installed right now
-- it's neither cheap nor convenient if, for example, you just ran out
in the middle of some long running process, or when the system's so
lethargic that mouse clicks seem to be running across an RS-232 port
at 4800 BAUD.

Software engineers don't have to get bogged down with making every
nanosecond count, but we shouldn't ignore the fact that systems are
never fast enough, never responsive enough, never have enough memory,
never enough disk space, and that the faster and bigger the HW folks
make'm, no matter how fast and big, the faster we bog'm down with OS's
that require multiple DVDs to load and multiple GIGs of memory to
work.

Java is a beautiful language with a rich, expressive syntax and a vast
array of easy-to-use classes in the community. Those are a couple of
big reasons its popularity has grown. The more SW engineers can do to
shrink the performance gap between Java and natively-compiled
languages like C/C++ and the more we take memory footprints and CPU
cycles seriously, the better off Java will be.

Performance is the biggest drawback to using Java, maybe its only big
drawback, and that's why I'm such a huge opponent against blanket
statements that ignore this side of the Java tradeoff.

Again, this is more of a spew in all directions in an attempt to get
all J-programmers thining, than a direct response to your note.
Didn't want it to come across as a flame, cuz it's not.
 
M

Mark Thornton

raddog58c said:
For instance, someone was asking me about checking for an already-
running instance of a program on a Windows workstation. That's a
really easy thing to implement in any language that can talk directly
to the OS -- about 15 lines of code invoking EnumWindows.
If we are talking about arbitrary applications then that only works for
applications that actually have a window.
You can't do that in Java, however, unless you go JNI.
On the other hand if we are talking about testing for an instance of
your own application (written in Java) then that is possible without
resorting to JNI.

I would say "the penalty is usually pretty small now" is very context
sensitive. Not to pick on you personally, but the general embracing
of the "memory is cheap" or "performance is good enough" is popular in
the Java community, and it's wrong to me. Maybe that's because I use
everything from MASM to IBM 370 BASM to C, C++, Java, VB and Perl, not
sure...

Sometimes the penalty can be zero or even negative, particularly for
applications which run long enough to eliminate the startup effects of
JIT compiling.
But I would never, or at least rarely, use Java for desktop utilities
I create for myself because the startup time is dreadfully slow, and
the impact on other applications is large. If you're running a system
with a GIG or less of RAM, firing up a memory-hungry JVM isn't
Rubbish. You can do quite a lot of useful work with the JVM 'using' only
8MB or less which is trivial in the context of 1GB memory. I've been
running a service, written in Java, which has no noticeable effect on
the responsiveness of my normal applications. It sits there all day
doing its stuff and I can easily forget that it is still running. My
machine is a 4 year old 3.06GHz Pentium with 1GB of RAM.
Performance is the biggest drawback to using Java, maybe its only big
drawback, and that's why I'm such a huge opponent against blanket
statements that ignore this side of the Java tradeoff.
Look who is making blanket statements. I care a lot about performance,
but I don't have a problem in this respect with Java. Java isn't
perfect. For some applications it can be slower than say C++, but in
other cases it can be just as fast (or even faster).

Mark Thornton
 
R

raddog58c

If we are talking about arbitrary applications then that only works for
applications that actually have a window.

Sure enuff, but point being the tradeoff between getting to the OS
layer or stopping at the language layer. Java stops you at the
implementation, unless you go JNI -- that prevents some things, but
that prevention faciliates more portability. It's a tradeoff.
On the other hand if we are talking about testing for an instance of
your own application (written in Java) then that is possible without
resorting to JNI.

Absolutely. The point in this case was again the tradeoffs.
Sometimes the penalty can be zero or even negative, particularly for
applications which run long enough to eliminate the startup effects of
JIT compiling.

How can it negative? I'm not saying you're wrong, but how can any
byte-coded language outperform a binary language if they are doing the
same thing? It can't, because you have to convert the byte code to
the native binary stream before you can execute it. So I'm thinking
you mean certain algorithms are more efficiently handled by the JVM?
Please elucidate -- I heard someone say Java memory management now
exceeds C and I thought it was an interesting notion and probably
related to some ingenius optimizations in memory mgt algorithms,
though I honestly don't know.
Rubbish. You can do quite a lot of useful work with the JVM 'using' only
8MB or less which is trivial in the context of 1GB memory. I've been
running a service, written in Java, which has no noticeable effect on
the responsiveness of my normal applications. It sits there all day
doing its stuff and I can easily forget that it is still running. My
machine is a 4 year old 3.06GHz Pentium with 1GB of RAM.

No doubt, and Java's fine messaging implementation and rich set of
protocol support, eg, makes it a good vehicle for such things. A
service I'm fine with -- a utility I need to fire up over and over,
not so fine with that. I wouldn't write that in Java.

At one time there was a Java compiler that let you go from Java
to .EXE. I used it quite a bit, although the .EXEs it generated were
pretty fat for the functionalit they implemented. Then again Java's
not about creating .EXEs, so that didn't surprise me.

Languages have strengths and weaknesses. When it comes to my tools I
want as close to subsecond response time as possible, so I'm looking
for .EXE based apps. If I'm parsing huge chunks of random text, I'm
all for Perl. If it's XML or a large messaging paradigm, Java's
great.
Look who is making blanket statements. I care a lot about performance,
but I don't have a problem in this respect with Java. Java isn't
perfect. For some applications it can be slower than say C++, but in
other cases it can be just as fast (or even faster).

What would be an example where it's faster? I write a lot of Java
these days, as well as a lot of C++ and even some C and ASM. I know a
decent bit about Java best practices, but I'm not in Java 7x24 -- so
if there's a way to make my Java scream, I'd like to know. At best
I'm looking at avoiding fat objects with features I don't need, such
as synchronized collections like Vectors where a single thread is
using the object.

How does one get Java to run faster than a compiled language? It
would seem there has to be a catch or specific circumstances for that
to occur, because it's hard to fathom how that could be the case.

Thanks for the comments, by the way.
 
C

Chris Uppal

Mark said:
You can do quite a lot of useful work with the JVM 'using' only
8MB or less [...]

How do you configure it to use so little memory ? Presumably you are not
counting the space taken by the JVM's own code in that figure.

Also, is 8MB the amount of memory /reserved/ or the amount actually /used/ ?
(I'm assuming a Windows host, not sure if the same distinction makes sense on
Unixy OSes).


-- chris
 
C

Chris Uppal

raddog58c said:
How can it negative? I'm not saying you're wrong, but how can any
byte-coded language outperform a binary language if they are doing the
same thing? It can't, because you have to convert the byte code to
the native binary stream before you can execute it.

At least in theory, the JVM's JITer has more information available to it than a
compiler producing a statically pre-compiled binary would have. Some
theoretical examples:

Is the machine /actually/ a multiprocessor ? If not then some synchronisation
primitives can be replaced by no-ops.

Is a (virtual) method /actually/ overridden by any class loaded at runtime ?
If not then optimisations like static linking or even inlining become possible.

Does the processor have an extended instruction set ? If so then the JITer can
generate code which uses those instructions. (A statically precompiled binary
could include both sets of code, of course, with dynamic switching between
them, but that is not often deemed worth the extra bother).

As far as I know, all of those possibilities are implemented (if only in
limited ways) in current Sun JVMs.

How does one get Java to run faster than a compiled language?

Simple: compare it with a compiled language with a bad optimiser ;-)

FWIW, I think it is /highly/ application dependent, and there is no simple set
of rules you can follow to make Java run as fast as possible. My impression is
that the optimiser in the server JVM, from 1.5 (and presumably later) generates
code which is comparable with GCC -o3 or MS's C++ compiler with all obvious
optimisations turned on -- however that is a useless observation unless the
code in the two languages is trying to do the same thing (e.g. 2-D arrays have
different layouts in C and Java, or a calculation might create many
intermediate objects in carefully-written Java whereas the "same" code in
well-crafted C++ might not).

-- chris
 
E

Eric Sosman

raddog58c wrote On 02/06/07 19:03,:
[...]
Rubbish. You can do quite a lot of useful work with the JVM 'using' only
8MB or less which is trivial in the context of 1GB memory. I've been
running a service, written in Java, which has no noticeable effect on
the responsiveness of my normal applications. It sits there all day
doing its stuff and I can easily forget that it is still running. My
machine is a 4 year old 3.06GHz Pentium with 1GB of RAM.


No doubt, and Java's fine messaging implementation and rich set of
protocol support, eg, makes it a good vehicle for such things. A
service I'm fine with -- a utility I need to fire up over and over,
not so fine with that. I wouldn't write that in Java.

One point you're missing (and it doesn't seem you're
alone) is that there is no need to shut down the JVM after
your "utility" is finished. You can just leave the JVM
sitting there, already warmed up and ready to go, just
waiting to be told to load another class.

As a concrete example of this approach, consider a
browser running a sequence of applets, one after another.
How does one get Java to run faster than a compiled language? It
would seem there has to be a catch or specific circumstances for that
to occur, because it's hard to fathom how that could be the case.

The only actual data I've seen on this topic is now
quite old, dating from the first few years of Java. IIRC
it was an article in CACM, describing an experiment in
which several dozen computer science students wrote programs
using various languages: Java and C++ and C (I think). The
programs were then assessed for correctness and performance.
The average performance of the Java programs (I forget how
they defined "average" and "performance") was poorer than
that of programs in the other languages, *but* the variation
between languages was much smaller than the variation between
individual programmers. That is, performance depended much
more on programmer skill than on language choice. So the
answer to your question "How does one get Java to run faster"
may simply be "Write better code."

I believe the article was from an age before JIT, back
when Java really was a purely interpreted language. I don't
know whether the experiment has been repeated with more
recent implementations.
 
R

raddog58c

At least in theory, the JVM's JITer has more information available to it than a
compiler producing a statically pre-compiled binary would have. Some
theoretical examples:

Is the machine /actually/ a multiprocessor ? If not then some synchronisation
primitives can be replaced by no-ops.

Is a (virtual) method /actually/ overridden by any class loaded at runtime ?
If not then optimisations like static linking or even inlining become possible.

Does the processor have an extended instruction set ? If so then the JITer can
generate code which uses those instructions. (A statically precompiled binary
could include both sets of code, of course, with dynamic switching between
them, but that is not often deemed worth the extra bother).

As far as I know, all of those possibilities are implemented (if only in
limited ways) in current Sun JVMs.

These are good... thanks. It would depend on the nature of the
application, as some of the optimizations, unless significant,
wouldn't make up the difference in the time it took to compile the
byte code into machine code.
Simple: compare it with a compiled language with a bad optimiser ;-)

That'd be one of several ways... touche!
FWIW, I think it is /highly/ application dependent, and there is no simple set
of rules you can follow to make Java run as fast as possible. My impression is
that the optimiser in the server JVM, from 1.5 (and presumably later) generates
code which is comparable with GCC -o3 or MS's C++ compiler with all obvious
optimisations turned on -- however that is a useless observation unless the
code in the two languages is trying to do the same thing (e.g. 2-D arrays have
different layouts in C and Java, or a calculation might create many
intermediate objects in carefully-written Java whereas the "same" code in
well-crafted C++ might not).

This does presume that we're comparing the post-compiled byte code
against the precompiled code in the runtime binary (.EXE, .COM, etc).
The fact the conversion is done at run time and would have to be done
every time the code is run (unless it's cached) puts it at a
disadvantage out of the gate. The late binding to environment could
help close the gap, but that's not guaranteed because the .EXE can be
precompiled for the target deployment environment and if so the race
is over.

I'm nonetheless impressed with the computer scientists building
optimizations into the JVM -- they've a lot of clever techniques up
their respective sleeves.
 
M

Mark Thornton

Chris said:
Mark Thornton wrote:

You can do quite a lot of useful work with the JVM 'using' only
8MB or less [...]


How do you configure it to use so little memory ? Presumably you are not
counting the space taken by the JVM's own code in that figure.

That was the total working set for the process.
Also, is 8MB the amount of memory /reserved/ or the amount actually /used/ ?
(I'm assuming a Windows host, not sure if the same distinction makes sense on
Unixy OSes).

The amount actually used. If you don't have a gui, then you can do quite
alot with just a few MB of heap, and the code actually in memory doesn't
take up that much space either. One example of such an application that
I ran for weeks at a time a few years back would act as an SMTP relay,
accepting mail and then forwarding it when the destination machine was
online.

Mark Thornton
 

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,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top