So, why not Java?

Mega Man X · 11-14-2005, 04:09 AM

If possible, I would like peoples to explain why, where and how exactly Java is slow. I kinda got the feeling that, because Java was slow and buggy back in 1996, it's still believed to be that way. Benchmarks out there proves that Java speed is not far from C++, even in games (anyone tried SpecForce or Quake 2 Java ports?).

Another thing is, Java start-up programs can be a bit slower, because the VM has to start first, then the application in question. After that, the speed is the same as all other applications I run for most tasks.

I think Java, unfortunately fell in the same category of popular believe as Linux: "Linux is hard to install, Linux is for hackers, Linux is for computer scientists, Linux is for programmers...", which is no longer true, especially with distros as Mandrake or SuSE, but still believed to be that way.

Again, Java is assumed and believed to be _much_ slower then C++, but never proved with examples. Peoples just stop by and say "it's slow", just like "Linux is difficult". More concrete examples and benchmarks are welcome

tuxdev · 11-14-2005, 11:39 AM

I've been looking into the java's speed and I think that java may be almost as fast as c++ after startup, but the overhead of a VM bothers me a lot. Now if it doesn't really use a VM, I'd be way happier to accept that it has pretty much the same speed. I'm not willing to accept that java is the same speed or faster cause java is farther away from machine language than C/C++. Also, all of the helper stuff like the GC must be using resources not used if you do what they do automatically yourself.

mr_demilord · 11-14-2005, 12:01 PM

I never use Java and don't have it installed, it takes ages to load and is a big resource hog.
Look at openoffice which uses java, it takes ages to load.

azureus for example sucks away to much memory so my system starts to swap.

Web sites that uses Java takes ages to load and scrolling a page which uses java is horrible.

Java is a :no: :no:

tuxdev · 11-14-2005, 12:41 PM

azureus to me is a good example of nice java-based software. openoffice may be somewhat slow by default, but there are lots of settings to improve that. It is definitely way more efficient than MS Office. And you do have a powerful enough computer to handle those apps, right? You can't expect 500Mhz computer to do such resource intensive stuff regardless of what languange it is written in. Applets are a whole other thing almost entirely. And how can you run anything that uses java without java installed?

Mega Man X · 12-06-2005, 10:26 AM

Quote:

Also, all of the helper stuff like the GC must be using resources not used if you do what they do automatically yourself.

True, to a certain point. While it's not possible to get rid of the Garbage collector completely, you can do a lot of optimizations on it. You could always start your application with:

java -verbose:gc MyClass

To get information when a GC occours. It's also possible to increase the heap when starting an application and also possible to control when the gc will do one "collect" (say, every 10s). With all sincerity, it easier to make wrong things with C++ and have loads of mem leaks everywhere.

Quote:

And how can you run anything that uses java without java installed?

You can if you compile it to machine code. But doing that will lose all the portability Java offers. But Java is no different then other applications. Think about Gaim or Gimp for example: In order to run it, you need the gtk runtime libraries installed. Like kedit? Then you need qt libraries installed. Java just happens to have an API with it for graphical applications. In practice, it's the same thing, IMHO. With exception, of course, that Java is easier to program, debug and maintain and harder to make mistakes with it

(It's also portable, but that has already been said)

tuxdev · 12-06-2005, 12:33 PM

Graphical toolkits are beyond the scope of the core languange IMO. I am also pretty sure that Sun's java will not let you compile completely to machine code. C/C++ is also portable too, in the sense that properly designed code will compile and run the same on all platforms with C/C++. I have personally found that Java is no easier to debug. It is harder to make mistakes, but it does that by assuming you are an idiot. This makes it harder to program in for me. It forces me to do things the "Java way".

Having the garbage collector try to collect every ten seconds is a waste of processor and having it wait a while to collect is a waste of memory. Using "free" as early as possible is neither.

Mega Man X · 12-06-2005, 02:59 PM

Quote:

Originally Posted by tuxdev

Graphical toolkits are beyond the scope of the core languange IMO.

I agree with you in this one. However, I believe Java did that so you could write complete applications on multi-platforms, regardless if it is command line or not. If they let the graphical toolkit out, then peoples would be using something else and that could bring the portability down. Some Graphical Toolkits uses a hard-coded pixel value to place components in a frame. That could look good in one Operating System, but not on another. Java has optimized as much as possible for it to look the same on every platform. It still is possible to use a hard-coded pixel to place components in Java.

Quote:

I am also pretty sure that Sun's java will not let you compile completely to machine code.

You can:

http://gcc.gnu.org/java/

Everything is supported, except for AWT, but they are working on it. gcj can not only compile java to machine code, but also, if needed, generate the java byte-code (.class) or convert a byte code into machine language.

Quote:

C/C++ is also portable too, in the sense that properly designed code will compile and run the same on all platforms with C/C++.

Almost true. cout and cin are the same everywhere. By that, I mean the C++ the "language" is the same on every platform. However, C++ relies a lot on the compiler itself in order to work. Creating a 100% portable C++ code would include hard-to-accomplish things as not using static constructors, exceptions... even overloaded methods can be tricky. Heck, you can't even trust iostream. Inlines may or not compile as well, dependending of the compiler:

Code:

  class MyClass {

    int myMethod(char* c) {
      if (c[0] == '\0')
        return -1;

      anotherMethod();
      return 0;
    }

  };

Expect the above to not compile with all compilers around, because of the inline code with multiples return value.

Quote:

I have personally found that Java is no easier to debug. It is harder to make mistakes, but it does that by assuming you are an idiot. This makes it harder to program in for me. It forces me to do things the "Java way".

I would like if you could give some examples here. The only thing that Java has that forces you to do are Exceptions. Java has classes that are signed and unsigned, meaning that some calls MUST be put inside a try-catch block, but that's it.

Quote:

Having the garbage collector try to collect every ten seconds is a waste of processor and having it wait a while to collect is a waste of memory. Using "free" as early as possible is neither.

Not really. Think about a game (sorry, but all I can code are games, so...ghehe), for example. The garbage collector can slow down your frames per second in a game when it should not. You can always force the garbage collector manually by doing a System.gc();. Let's say, you are going to load a new level or a cutscene. In this case, you can make a call to the GC right before that happens. In game, it's good to know when to make a manual call to GB on every screen refresh or in a given amount of time (like 10-13s).

The way I see the whole picture about Java today, is the way C programmers saw C++ (and some still do) when it came out. They have problems to accept it, which is understantable. I do, find Java to be a better C++ and it will grow much larger in the future and become an standard as C++ is today for everything. If it's not Java, something else similar to Java will take C++ in a way or another. C++ is too old and inhiretence from an even older language(C) and the programmer has to deal with things as pointers and mem management that he/she shouldn't. An average Java programmer is most likely to get a good Java application working great ratter then an average C++ programmer, IMHO.

tuxdev · 12-06-2005, 04:53 PM

Man, it deleted my comment TWICE.

I know about GNU java, I was talking about Sun's java. GNU java can compile down cause it is written in C and Sun's java is written in java, so they suffer from the restrictions they put on themselves.

Compiler based problems are do not have anything to do with the languange itself. Ideal compilers on different platforms should act the same.

There are only references, no pointers or objects. Great power comes from pointers. There is no way to access the system without using some tool in java. If java doesn't support accessing a device, you are out of luck.

A GC call is much more expensive than free. Therefore, it uses up memory for storing info on the references and the call uses more processor to do what should be the same work. Also, the memory is freed later, so something that creates and destroys often needs more memory cause something is not freed when it is supposed to so something that is created cannot use that memory.

Java tries to protect the programmer from himself by making everything he does happen in a VM in java's control. Works, but sucks all the power from the languange.

Mega Man X · 12-08-2005, 12:11 PM

Hi again tuxdev. It has been a while since I had so good chat about Java

Quote:

There are only references, no pointers or objects. Great power comes from pointers. There is no way to access the system without using some tool in java. If java doesn't support accessing a device, you are out of luck.

I think you did a typo. Java has objects. In fact, as far as I understand, everything in Java is s subclass of the class Object

Quote:

A GC call is much more expensive than free. Therefore, it uses up memory for storing info on the references and the call uses more processor to do what should be the same work. Also, the memory is freed later, so something that creates and destroys often needs more memory cause something is not freed when it is supposed to so something that is created cannot use that memory.

No info is actually stored in the Garbage Collector. The garbage collector simply pick up things that are no longer referenced to. You could, for example, set an Object no longer in use to null and then make a call to the GB and free that memory:

Code:

public class MyGame {

    public static void main(String[] args) {
    
    Game game1 = new Game(1);
    Game game2 = new Game(2);
    Game game2 = new Game(3);

    // dispose two games
    game2 = game3 = null;
    System.gc(); // call the garbage collector to pick up
    }
}

class Game extends Object {
    int id;

    public Game(int id) {
        this.id = id;
        System.out.println("Game Object " + id + " was created");
    }

    public void finalize() trows java.lang.Throwable {
        System.out.println("Game Object " + id + " was destroyed");
    }
}

Again, nothing is stored in the GC. So, to be more specific, when a method is invoked, parameters and local variables are stored in a place of memory known as Stack. Elements in the Stack are allocated and freed in a last in first out fashion way. Somethings, as arrays, however, are stored in a Dynamic memory location, know as "Heap". Memory in the heap are allocated and freed arbitrarily (is this a word?, ghehe)

As you see, it's possible to make a call to the GB to free objects no longer in use and that memory allocation will be available. It's all a matter of good programming style, I guess.

Quote:

Java tries to protect the programmer from himself by making everything he does happen in a VM in java's control. Works, but sucks all the power from the languange.

I do, realize that pointers and accessing lowers levels are necessary sometimes. It's practically impossible to write a kernel or even device drivers using Sun's Java, but it was never supposed to do that either

. I just think that Java is not so used as much as it could :\

Mega Man X · 12-08-2005, 06:56 PM

You know one thing about Java I actually started to dislike? The portability. So far, I have only had one problem with Java across platforms: I can't run my game in fullscreen mode in Unix. It's not a true fullscreen, however, it's more like a "cheat" to make a JFrame to display in fullscreen. Still, it's not this kind of portability I'm talking about, but where Java runs.

We need to wait for Sun to get interested in a given Operating System so we can develop applications for it. For example, I have Debian installed in a Sparc Ultra. Needless to say, there's no Official Java support for Linux in Ultra Sparc machines (how strange, ghehe). Things don't look very nice to BSD either.

What I mean is, if tomorrow I feel like writing a cool hacked game to Xbox 360, that's never gonna happen :\

Funny that the portability of Java goes actually as far as 3 or 4 Operating Systems

. Still, I love the syntax and the rock solid API. Maybe someday, there will be a good replacement for JVM which is open source and truly portable.

tuxdev · 12-08-2005, 07:02 PM

I didn't make a typo. Java has no directly usable objects. Think about the differences between

Code:

std::string str; // object
std::string &str; // reference
std::string *str; // pointer

How can the garbage collector know when something no longer has a reference to it? It must store a ghost reference to those Objects and check all of those ghost references when it does a collects.

As for internal memory management, I learned that primitives and primitive arrays were sometimes stored in a reserved portion of memory for 8, 16, 32, or 64 bit values. Since all objects are dynamically allocated with new, parameters are already allocated on the heap. References are the only things that I see that get allocated on the stack if primitives are allocated specially.

Code:

int n; // allocated special or on stack
int *n; // allocated on the stack
n=new int; // allocated on the heap
std::string str1; // allocated on the stack, new object created
std::string &str2; // allocated on the stack, nothing created
str2=str1; // nothing allocated
str2=std::string; // allocated on the stack, legal?
std::string *str3; // allocated on the stack, nothing created
str3=new std::string; // allocated on the heap

tuxdev · 12-08-2005, 07:11 PM

Yeah, the two big advantages to java is it is portable almost to a fault and it has a rich , centralized API. C++ has just as rich of an API, but it is less accessable.

Mega Man X · 12-08-2005, 07:23 PM

Great posts tuxdev. Thanks. You are actually making me understand things a little better about Java. Reminds me of my first girlfriend. She was just what I have ever dreamed about. Perfect... for a month. After that I truly started seeing and wondering: WTF am I doing

.

Nah, not that bad. But I really think a replacement for the VM would be a great step forward. Look at python, for example: Runs in a hell lot of platforms, pretty stable, pretty fast and gives you even real pointers. Why did I stop using pygame again? :\

tuxdev · 12-08-2005, 07:40 PM

ghehe, I should think about python. Unfortunately it would be after Lisp and Perl, which I only had a light enough coating of to see the light. Yeah, if java just got rid of the idea of a VM entirely, it might actually do better psychologically than it does. Sort of like the reason why Wine might be faster than real Windows is cause Linux more than compensates for any speed decrease in using a execution layer. It is never argued that the Wine is faster by itself, without the gains Linux adds.

I guess the main thing about my posts is that I am thinking about the stuff for pretty much the first time. Goes nicely with the fact that I finished my finals for the quarter.