[java] about java

quote:

---

Original post by pizzaman

is java really much different than c++. does it support direct x or open gl?and how long would it take to learn if you already knew c++. what is code compiled in? thanks to anyone that can help

---

Java is not that *much* different then c++. A few syntax things and the way the files are organized. I think that there is some development in DX for Java but I am not sure. If you already knew C++ ( especially OOP ) then Java would be a breeze to learn.
Java is compiled in a Java compilier ( check Sun''s webpage for the free one). It is compiled into .class files which the virtual machine then uses to run the app.

Java has a lot of nice stuff already in the language that makes it handy.


--------
Andrew

I''ll try to cover this one, although it''s a big topic....

Java is not much different than C++. In fact, I''m sure the overall syntax of the language was chosen so that c/C++ programmers would be comfortable with it. However, there are several important differences. I''ll cover them from the perspective of someone who knows C++, as your post indicates that you do.

1. No explicit pointers. The designers of java found that explicit pointers were often a cause of bugs in programs that could take a great deal of time to track down, so they decided to eliminate them. Instead, all non-primitive data types are reached through implicit pointers, somewhat similar to C++''s references. Also, you can''t create non-primitive data types on the stack, meaning that the new operator must be used to create instances of all classes in the language.

2. Garbage collection. There is no explicit delete in java. Once all reference to an object have been removed, an object is free to be garbage collected, though garbage collection is not guaranteed to happen at any given time. Once again, this was a change made because the designers of java found that it nearly completely eliminated the time required to track down memory leaks in C++.

3. No templates. That''s something that just hasn''t been implemented yet.... It looks like the next major release of the java language specification may include something similar to C++''s templates. In the mean time, most of what templates do can be done in java due to the fact that all classes have a common superclass, Object, but it requires typecasting at run time, rather than template generation at compile time.

Those are the biggest differences for a C++ programmer to get used to. However, there are several other important differences, which are actually considered to be some of the defining points of the language.

4. Java is designed to be an interpreted language. It compiles to bytecode that is interpreted by a java virtual machine. Since the bytecode is the same for all platforms, any JVM that complies with the specifications should run the bytecode the same, no matter what platform the JVM runs on. Theoretically, this means that java bytecode is instantly portable between languages, although that''s not true 100% of the time, due to some intracacies of the libraries.

As a side effect of the fact that java is designed to be compiled to bytecode and then interpreted, it usually runs slower than equivelant C++ code, although that is highly dependent on the virtual machine used, and java can also be compiled to native code on most platforms. A second issue is that platform dependent features (such as DirectX) can''t be accessed directly, as they are not a part of the standard java libraries. It is still possible to use native code, but that removes the platform independence that java was designed for. In game development, the tradeoff is often worthwhile.

Another effect of the virtual machine is that all code for all classes is loaded dynamically, when needed. That''s useful to know, as it means that if you only change one class, you only need to recompile that class for everything to work. There is no linking process like that in statically linked languages.

There are several existing OpenGL interfaces available for java, many of which are listed in the FAQ for this forum. Magician is the one that seems to be most liked, and is most likely to become the standard java OpenGL interface.

I''m not quite sure by what you mean by "what is code compiled in?" so I''ll treat it as "what compilers/environments are available?" If that''s not what you meant, post again and someone will try to help, I''m sure.

The standard java implementation, without an IDE, is Sun''s free JDK (although they don''t call it that anymore). It''s a command line based compiler, which shouldn''t be that difficult for anyone with gcc or similar experience to figure out. Sun also provides a free IDE, Forte for Java Community Edition, which includes most features you''d want in a modern IDE... However, it''s not the most reliable IDE, and can run extremely slowly with no good reason sometimes. Other IDE''s and compilers are available... Check the FAQ, and I''m sure someone else will add some information on those.

If you have any more questions, ask... I''ve got some spare time on my hands.

That is a pretty accurate description c_wraith, although I would like to comment on one thing.

You write that Java is designed to be interpreted. This is actually not true. According to the standard a Java virtual machine can do anything it wants with the *.class files as long as it gets the job done. If this means compiling the code to machine code and then executing it, it is still legal. The point is that the version that is distributed is in byte code and therefore portable. And for completion there is also Java compilers that is not "standard" in that they compile the class files to machine code at compile time. Such compiled files should of course not be distributed as they are not "Java".

A JIT actually compiles the code and Sun''s Hotspot even recompiles it at run time as needed. Actually, because of hotspot (included in JDK 1.3) it is theoretically possible for programs to run faster than when they are compiled beforehand to machine code. The point is that the hotspot compiler analyses how the code is being used at run-time and then at run-time changes the compiled machine code to optimize for that case. JDK 1.3 isn''t as fast as C/C++, but in theory using this method might actually make it faster.

Jacob Marner

Ok, I knew that.... I just wasn''t clear enough, I suppose.

Anyway, the more info, the better.

thanks alot for all your help guys. can you suggest some books on java?thanks