Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Help me!! Why java is so popular

Reply
Thread Tools

Help me!! Why java is so popular

 
 
Amali
Guest
Posts: n/a
 
      02-05-2007
On Feb 5, 4:56 pm, "Andy Dingley" <(E-Mail Removed)> wrote:
> On 5 Feb, 03:10, "John W. Kennedy" <(E-Mail Removed)> wrote:
>
> > Microsoft dislikes it, and tried unsuccessfully to poison it.

>
> Every time you ship a JAR, a little fairy in Redmond dies.


Thank u for all of u I learn many things from ur posts.If any one have
more please send.

 
Reply With Quote
 
 
 
 
Tris Orendorff
Guest
Posts: n/a
 
      02-06-2007
"Andy Dingley" <(E-Mail Removed)> burped up warm pablum in

news:(E-Mail Removed) oups.com:

> On 5 Feb, 03:10, "John W. Kennedy" <(E-Mail Removed)>

wrote:
>
>> Microsoft dislikes it, and tried unsuccessfully to poison it.

>
> Every time you ship a JAR, a little fairy in Redmond dies.


I think that should be: "Every time you ship a jar, a big fairy
in Redmond dies." They're pretty big out there in Redmond.

--
Tris Orendorff
[Q: What kind of modem did Jimi Hendrix use?
A: A purple Hayes.]


 
Reply With Quote
 
 
 
 
raddog58c
Guest
Posts: n/a
 
      02-06-2007
On Feb 2, 11:31 am, "Jack Kielsmeier" <(E-Mail Removed)> wrote:
> <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed) ups.com...
>
> > 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.


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://
http://www.microsoft.com/technet/sys...sesAndThreads/
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.

 
Reply With Quote
 
Mark Thornton
Guest
Posts: n/a
 
      02-06-2007
raddog58c wrote:
> 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
 
Reply With Quote
 
raddog58c
Guest
Posts: n/a
 
      02-07-2007
On Feb 6, 4:41 pm, Mark Thornton <(E-Mail Removed)>
wrote:
> raddog58c wrote:
> > 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.
>


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.

>
> > 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.
>


Absolutely. The point in this case was again the tradeoffs.

> > 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.
>


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.

 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      02-07-2007
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.

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


 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      02-07-2007
raddog58c wrote:

> > 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.


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




 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      02-07-2007
raddog58c wrote On 02/06/07 19:03,:
> On Feb 6, 4:41 pm, Mark Thornton <(E-Mail Removed)>
> wrote:
>>[...]
>>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.

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
raddog58c
Guest
Posts: n/a
 
      02-07-2007
On Feb 7, 11:14 am, "Chris Uppal" <(E-Mail Removed)-
THIS.org> wrote:
> raddog58c wrote:
> > > 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.

>
> 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.
>
> > How does one get Java to run faster than a compiled language?

>
> 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.
>
> -- chris



 
Reply With Quote
 
Mark Thornton
Guest
Posts: n/a
 
      02-07-2007
Chris Uppal wrote:
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Why is OO popular? Ian Roberts C++ 5 04-20-2004 05:30 AM
Are Dvd-R more popular then the +? Why? lbbs DVD Video 29 01-11-2004 02:14 PM
Are Dvd-R more popular then the +? Why? lbbs Computer Support 9 01-08-2004 12:24 AM



Advertisments