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.

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.

Newer Posts

---

Don't change these.

Name:		Email:
Entire Thread Thread List