10 reasons Java is awesome

1.  Easy to learn.  90% of Java = C-pointers+classes.  You come from pretty much any programming background and hit the ground running with java.
2.  Best and most comprehensive standard libraries.  Wheels of all types and sizes are included in the standard library and they all have pristine documentation.  Not to mention the thousands of external libraries.  In java you never write wheels, you combine wheels to make machines.
3.  Super Fast.    Java is faster than all other garbage collected languages and about 1.5 times slower than C.
4.  Very readable code.   Without things like millions of operators, operator overloading, and first class functions it takes a lot of effort to obfuscate and write unreadable/unmaintainable java code.  Spend less time figuring out what existing code does and more time writing new code.
5-8.  Awesome tool chain.  Eclipse is as fully featured as it gets, from ridiculously good auto-completion and code prediction...to detection of errors before you even compile... to plug ins and version control integration. Did I mention its free?  The only competing tool chain that is even comparable(Visual Studio) costs an arm and a leg.
9.  Application versatility.  There is a JVM for all major platforms sans apple mobile products.  Porting from one platform to the other is easy.
10.  Ridiculously good garbage collection. Competing GCs don't even come close.

tl;dr  Real programmer use java.

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

_{HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA}

testies
testies
one
two
three

It's somewhat plain and lacks many advanced features that are available in other languages, many which came before Java.
You can also claim that some other languages do also fit most of the other points as well, while being a lot more featureful ( well documented, good toolchain, very portable, reasonably fast, ...)

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAH

Too bad you need to install some large hideous shit for it to run.

I feel like adding debate to prove that /prog/ *can* have competent debate but it's 2:29 AM here.

Too bad every Java App that isn't Hello World requires at least 200 MB of RAM to run.

>>1
Thanks OP, I was feeling a little depressed, but that bullshit perked me right up

Plumber Detected...

>>13
Moron Detected...

Cool hyperbole, bro.

I come from a Haskell background and have found Java rather difficult to learn.

I come from a QBasic background and have found that GOTO's are an excellent control structure.

>>17
I know, eh? And all these dumb people saying that they're unscientific and ultimately harmful      .

>>17,18
Java has gotos for nested loops.  labeled continue; and break;

foo: for(;;){
 if(true)
   continue foo;
 else
   break foo;
}

>>19
javac gotoFoo.java
gotoFoo.java:4: unreachable statement

1.  Easy to learn.  90% of Java = C-pointers+classes.  You come from pretty much any programming background and hit the ground running with java.
Sort of true. You still have to learn object-orientation extremely early on, which is a bad thing IMHO; procedural and functional concepts are much more important, and are non-existent in Java.

   2.  Best and most comprehensive standard libraries.  Wheels of all types and sizes are included in the standard library and they all have pristine documentation.  Not to mention the thousands of external libraries.  In java you never write wheels, you combine wheels to make machines.
Arguable... It probably has the best documentation, but the shittiest and most verbose API. Honestly, a StringTokenizer object to split a fucking string? Give me a break. It took them like 7 versions to finally put a split() method on String. These folks have no fucking clue how to design an API, and they think documentation can make up for it.

   3.  Super Fast.    Java is faster than all other garbage collected languages and about 1.5 times slower than C.
Fail. This depends extremely heavily on the data being processed; it can potentially be orders of magnitude slower (especially when a lot of data is being processed, because Java has a ton of overhead that fucks up your cache.) For some problems, compiled GC languages such as Go are a lot faster.

   4.  Very readable code.   Without things like millions of operators, operator overloading, and first class functions it takes a lot of effort to obfuscate and write unreadable/unmaintainable java code.  Spend less time figuring out what existing code does and more time writing new code.
Epic fail. You've never worked with a J2EE application I see. Thousands of lines of code to accomplish menial tasks is not readable, and I don't understand how you think *not* supporting operator overloading and first class functions somehow makes the language readable.

   5-8.  Awesome tool chain.  Eclipse is as fully featured as it gets, from ridiculously good auto-completion and code prediction...to detection of errors before you even compile... to plug ins and version control integration. Did I mention its free?  The only competing tool chain that is even comparable(Visual Studio) costs an arm and a leg.
Epic fail. Eclipse is *awful*. Slow, bloated, shitty, awful. Eclipse folks always act like automatically detecting errors is some magical feature; with a few changes to your makefile you can just run make quieted on a loop for fuck's sake, accomplishes the same damn thing.

   9.  Application versatility.  There is a JVM for all major platforms sans apple mobile products.  Porting from one platform to the other is easy.
Epic fail. Any language with a compiler that compiles to C is inherently more versatile, and even some high-level interpreted languages are more widely ported; for example CPython runs on more platforms than the J2SE VM (though that's largely because CPython is a lot simpler and shittier.) Java is on the very low end as far as portability goes.

   10.  Ridiculously good garbage collection. Competing GCs don't even come close.
This is the only one of these statements that is true, except for the massive caveat that it isn't used for mobile/embedded, which is Java's fastest area of expansion right now. Embedded GCs are still awful.

Why did I bother writing up this reply to an obvious troll? No one is going to read it anyway.

>>17

I come from a QBasic background
I now use C and Python

I do not, however, use OO

No one is going to read it anyway.
I read your post, >>21-dono. Please gambatte! ;_;

>>21
I read it.

>>21
with a few changes to your makefile you can just run make quieted on a loop for fuck's sake, accomplishes the same damn thing
Make quieted gives you context-aware code suggestions and refactoring? IHBT

I really do like Java.

Java helps me work for my rent and rolling papers.

>>21
No one is going to read it anyway.
I'll give you a tip: don't use phrases such as "fail" and "epic fail," your readers won't ragestop reading your post.

>3.  Super Fast.   
>10.  Ridiculously good garbage collection
This is bullshit, Java cannot be compared to compiled and manually managed memory languages. It has inherent speed/memory tradeoff you cannot mask with any program.
JVM isn't magically optimized assembler obsolete.
>5-8.  Awesome tool chain.
stuffing 40% of your 10 reasons with such a bullshit metric, since every popular language has "awesome toolchains"
>Best and most comprehensive standard libraries
Big standard library isn't making Java better, in fact its making it more bloated and slow. You incur all the penalties of a VM plus megabytes of non-essential code which is somehow 'standard'.
All the libraries that are really needed could be imported.

>>29
YHBT

>>25
All decent editors give you context aware code completion; this applies to any popular programming language. Refactoring tools are nice, but they're not specific to Java, and they aren't exclusive to Eclipse.

Refactoring tools are the most overrated misfeature in the history of really shit editors. If you find yourself refactoring often enough to want your editor to help you do it, you need to get the fuck out of the programming field.

>>1.  Easy to learn. 
Easier to learn than C++ because youre not using pointers and memory management. Back in the 90s C++ and VB were the only options for programming anything, and C++ being a systems programming language was overkill for about 70% of what it was being used for, as it is really just a portable assembly language. Java has made things easier definitely while maintaining most of C++'s OOP complexity.

>>2.  Best and most comprehensive standard libraries.
Yes that is nice that Java lives in its own "ecosystem" so you dont have to track down libraries and dll's to do everything.

>>3.  Super Fast.  
Java is faster than most other VM languages like Python because it uses static typing and non-object primitives. An VM interpreted language will never approach the speed of languages compiled to machine code though, Java is about 10 times slower than C meaning that Java will not take the place of compiled apps like video games any time soon.

>>4.  Very readable code.  
I wouldnt say more readable, Java maintains complexity compared to C++. Its just a safer language, so that the programmer spends more time programming rather than fighting the language semantics going on under the hood.

>>5-8. Awesome tool chain.
The fact that Java is a VM language means you dont have to rely on platform toolchains.
 
>>9. Application versatility. 
This is arguable as to your definition of what it means for a language to be crossplatform. Having a language compiler ported to hardware is just as crossplatform as a VM ported to hardware.

>>10. Ridiculously good garbage collection.
All VM languages have "rediculously good garbarge collection" because they dont have to map to hardware, all memory is in bytecode

>>33
Stop trying to help if you're going to be nearly as wrong as a blatant troll.

>>33
In that sense, Java still possesses an ecosystem hunt called "reading the API docs."  The upside to this is that the API is already well-mapped-out.

Is it "possible" to optimize compiled byte code by hand?

>>35
I used to see a SEESHURP program which somehow managed itself through IL. It was so scary, I'm really happy I was able to unsee it really soon. What you want is probably 100500 times worse.

If you need to increase performance in Java, go buy a few more blades.

http://www.deathcade.com/

>>36
I'm not that suicidal yet.

>>1
bawww pointers are hard for me to manage on my own

yes and some of those libraries (I'm looking at you SAX and DOM XML) are incredibly over complicated. Takes a shit ton of documentation reading just to get started with XML shit. However Javadocs are pretty good for the standard library

explicit memory management in c > gc

kind of

good toolchain? ant is a piece of shit and XML overkill. makefiles ftw

sure

ruby gc

>>21,29,39
I hope but honestly can't tell if these people are meta-trolls.

Back in the 90s C++ and VB were the only options for programming anything, and C++ being a systems programming language was overkill for about 70% of what it was being used for, as it is really just a portable assembly language
Just no. There were many other good alternatives, and you already had very nice languages back in the 80's and lower (various Lisps, most had all the goodies Java had, a lot of other advanced features, native compilation, gc, real macros, very well-written docs, portability. The only thing I can't claim it had is "easy to learn" (it takes a week to get proficient), but I wouldn't claim becoming a Java ``architect'' is that easy, as you'll need to read a fair share of "design patterns" book to reach that state - and 90% of the patterns presented in those books manfiest themselves naturally( http://norvig.com/design-patterns/ ) in more advanced languages, without having to coerce a single-dispatch OO language to do what it wasn't intended to be used for).

>>41

comparing java to lisp

>>42
Just saying that there were better alternatives even back then.

>>43

just saying they aren't comparable

>>44
They're both turing complete. You could implement Java in Lisp, and Lisp in Java.

>>45
is a non-argument

>>45
http://xkcd.com/505/

>>33
Java is about 10 times slower than C meaning that Java will not take the place of compiled apps like video games any time soon.
Java is not 10 times slower. It depends heavily on the problem you're working on, but properly optimized, it can be about 1.5x to 3x slower. See the language shootout, left side of the graph: http://shootout.alioth.debian.org/u64q/java.php

That being said, Java will *never* take the place of video games. Mainstream video games will always use technology extremely close to the metal, at least for the rendering and physics engines (which realistically is most of the code), for the simple reason that they need to to remain competitive. If they don't do it someone else will. Mainstream video games also use much higher level languages for game logic (such as Lua) for the simple reason that Java is an incredible pain in the ass to program in.

More important than speed, though, is memory overhead. Java memory overhead is *massive*. Look at the middle part of that graph. Applications like Photoshop and video editing software already use massive amounts of memory, and they are written in C++. Games have always pushed memory capacity to the limit and always will; more memory has a very obvious effect on texture quality. These things will never be written in a managed language.

>>33
All VM languages have "rediculously good garbarge collection" because they dont have to map to hardware, all memory is in bytecode
No. A hundred times no. CPython for example has *incredibly awful* garbage collection. Reference counting with cycle detection (and by consequence the GIL) is an utter nightmare, and it's no longer possible to transition away from it due to the massive body of C code with CPython bindings. Even Google can't fix this (they have tried.)

For some languages like Go or Objective-C, it's not possible to have garbage collection anywhere near as good as Java, simply because they allow raw pointers (Objective-C because it includes C, and Go because of its 'unsafe' package.) You need purely managed pointers to make a copying collector.

As much as I loathe Java, this is one point on which it is truly excellent. You have to give it that much at least. Please don't confuse it with shitty GCs, because I really want high-level languages to get good garbage collectors, and that isn't going to happen with people spewing bullshit like this.

>>48
video games these days are horribly inefficient and bloated monsters.  Many absolutely could be written in java, but the companies that matter have far too much code written in c++ that would take a huge investment to replace and the benefit isn't that clear.  Manually managing memory isn't as a big a deal as people make it out to be when people are experienced with it.  You might save 10% development time. Also vector math is a pain in the ass java because of no operator overloading.  I don't work in the industry just follow it a bit and know people that do, the consensus seems to be that right now everything is c++ because it works and there's no real reason to change. 

A lot of studios hardly do any c++ coding anyway, they licsense the engine and a lot of other middle ware then code game play and logic in a scripting language.

>>49
The benefit is absolutely clear. You are truly crazy if you think a rendering engine in Java, or any managed language, can be as fast as one written in C or C++ (or that it would save development time).

Manually managing memory in games is *extremely* important, far more so today than it was five or ten years ago. There's this neat technology you may have heard of: it's called a processor cache. You kind of need control over it for high-performance games, you know?

You also have no control over how Java is assembled and run. There's a reason people still use inline assembly (especially with SIMD instructions) for stuff like matrix multiplications. There's a reason C++ supports raw pointers, unchecked array access, strict aliasing, __restrict. You can't do these things in Java.

video games these days are horribly inefficient and bloated monsters.

Most video games maybe, but most video games suck. My computer is about 6 or 7 years old, and I find Source games like Left4Dead run better and look better on this hardware than games that came out 5 years ago. That's an example of a really great game engine. Guess what language it's written in?

A lot of studios hardly do any c++ coding anyway, they licsense the engine and a lot of other middle ware then code game play and logic in a scripting language.
Yes, I said this earlier. What is your point exactly? Most of the game is still written in C++, even if it's not written in-house.

Don't change these.

Name:		Email:
Entire Thread Thread List