Is Java a good language to learn Besides C++ ??

Pages: 12345
As of today, I'm having a go at java for real (as I want to play with Android).
Moschops wrote:
Which means its only a matter of time until someone gets around to a decent C and C++ compiler for [the mobile domain] platforms. :)


You wont see a decent C or C++ compiler for the bulk of mobile platforms until you see a decent C or C++ compiler that can output code that runs on any/all/the-majority of the hardware a mobile device can have.

Luc Lieber wrote:
Java's a good language, but the crowd that uses it will likely lynch you if you go against any of the standard conventions.


I have surprisingly gone completely UN-lynched.


@OP: If you want to learn something new and exciting, I DEFINITELY agree a FP language is the way to go. I've only been attempting functional programming languages for a short while it's been oodles of challenges for me to wrap my head around.

That said, if C++ is your first language and you've only been at it a few months then I'm not sure if making such a drastic switch is a good idea. I'm sure it would be better to start looking into FP earlier rather than later, but so early on might not be a good idea O:
> Which means its only a matter of time until someone gets around to a decent C and C++ compiler for [the mobile domain] platforms.

Hasn't Google already done that with the Android NDK? Or is it that my ignorance in these matters is showing yet again?
http://developer.android.com/sdk/ndk/overview.html
There is the NDK, but they highly advice against using it as an alternative to the android sdk in java. It's only there to build portions of your apps that are very performance critical.
Last edited on
Completely agree with LB, java is such a terrible language when you come from c++...
I would say the only benefit is its platform independant system and reflexion.

C++ take years to master so i my advice is to stick with it and maybe learn something different like LISP in the same time to widen your programming style.

C# is also good as you will learn it very fast if you know c++ and it have a lots of nice features (if you can sacrify performances) like functional programming much easier than in c++.
You wont see a decent C or C++ compiler for the bulk of mobile platforms until you see a decent C or C++ compiler that can output code that runs on any/all/the-majority of the hardware a mobile device can have.


And the final answer was, "you won't be able to eat until you open your mouth" :) Thanks for playing "things that happen before other things"!
Java is cool. I'd say learn it.

The pros are the JRE and comprehensive set of included libraries. You can develop applications very fast in Java. Just don't think it's C++ because it isn't, wasn't meant to be, and never will be.
@moorecm: Good job. The very first post on this thread that isn't ridiculously wrong! I thought I stumbled into the children's forum when I read this thread ;-)
Last edited on
@Moschops

My point was that's not going to happen. One of the reasons Java is so widely used in the mobile market is because you won't need to recompile your code if you want to target another piece of hardware running the same virtual machine. Creating any sort of library or executable that is both cross-platform in terms of hardware and software AND compiled in native code just isn't practical.

closed account (1yR4jE8b)
The Java platform also gives you access to a variety of other JVM languages: Scala, JRuby, Jython, Groovy. With Scala and Ruby being standouts for me.
I haven't even looked at Groovy yet. I'm enjoying scala enough to have it replace java for me. Also Clojure if you want a lisp dialect on the JVM. But for all intents and purposes you'd be better off with Scala for FP on the JVM.

... I just really like prefix notation...
Creating any sort of library or executable that is both cross-platform in terms of hardware and software AND compiled in native code just isn't practical.


I do it regularly writing straight C and C++, compiling on the target hardware or with a dedicated cross-compiler. Here, for example, is a list of hardware targeted by the GCC. http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Architectures
Last edited on
Well Guys &ladies (if there are) , Thanks all but I think my question raised problems So Please it's not a war here !!
& Finally I will stick with C++ Until I get in-depth knowledge about it :)
Cross compilation != cross platform binary.


You still have to recompile and you usually need extra code for the platform dependent headers.
1. Java is pass-by-value (sometimes in the form of pass-reference-by-value, but it is still pass-by-value).

2. Immutable types are a good thing (tm) and if used correctly they lead to better performance (e.g. Java strings are generally faster than C++ strings).

3. Java generics are not syntactic sugar, they are part of the type system. I guess someone here doesn't know the difference between syntactic sugar and type systems.

4. Yesterday I met with a friend who was a very hardcore C++ programmer and Java hater some time ago. Guess what. He's programming Java right now and he said he likes it after working on several big C++ projects which were utter mess and segfaulted more often than worked correctly. Ok, there are many Java projects that are also utter mess, but at least they don't segfault (and crappy Java code is easier to fix than to fix crappy c++ code) :D

5. Most of people writing about Java in this thread don't have any significant hand-on Java experience. This is the same class of people criticizing Lisp for too many brackets or Python for meaningful whitespace or Scala for being too complex. You can't tell if language is good without writing at least one *big* project in it.

6. Java has some real problems, but they are not the things you've written in this thread.

7. Some of the fastest and best-scaling shared-nothing database systems are written in pure Java: DataStax Enterprise and Amazon Dynamo. I haven't heard of any C++ database that would provide similar level of scalability, reliability and performance. Even Google's BigTable feels like a toy compared with it.
Last edited on
Cross compilation != cross platform binary.


Ah. I misunderstood. I thought your whinge was targeting more than one platform; I did not grasp that you wanted a cross-platform binary.

You still have to recompile and you usually need extra code for the platform dependent headers.


As they say, "cry me a river" :) Compiling for each target platform is pretty standard for multi-platform software.
1. Java is pass-by-value (sometimes in the form of pass-reference-by-value, but it is still pass-by-value).


Are you sure about this? It's been a few years, but I have the distinct memory of the Class copy operator being by-reference, in the sense that the following:
1
2
Matrix a, b;
b = a;

would lead to a and b being the same object, not copies.

Officially, I think the explanation was that there are no Stack variables [aside from primitive types], thus any object is automatically a pointer. This is the same behaviour as in C++ when copying heap-allocated objects, except that in C++ you'll have the "oh, it's a pointer!" realization at some point. In Java, you have all the misery of pointers without the benefits (and knowledge).
closed account (z05DSL3A)
Gaminic wrote:
Are you sure about this?
I'm fairly sure that java is pass-by-value...{looking for docs}

http://docs.oracle.com/javase/tutorial/java/javaOO/arguments.html
Last edited on

Officially, I think the explanation was that there are no Stack variables [aside from primitive types], thus any object is automatically a pointer. This is the same behaviour as in C++ when copying heap-allocated objects, except that in C++ you'll have the "oh, it's a pointer!" realization at some point. In Java, you have all the misery of pointers without the benefits (and knowledge).


You can think of it as Java is "always pass-reference-by-value". It is technically not true for primitive types, but actually there would be no semantic difference. So you can treat Java as pass-reference-by-value, regardless of what kind of object you pass. Can't be simpler. This is the reason Integer and int in Java bahave identically in terms of passing them as arguments. Therefore it was easy to unite them into one type in Scala, and you won't notice a semantic difference between BigInt (object) and Int (primitive type).


would lead to a and b being the same object, not copies.


This saves us from all the madness with copy constructors, moving constructors, deep-copying vs shallow-copying etc.
Last edited on
Made a small test project in Java (forgive me for the horrible, horrible coding. I haven't done any Java in years. It took me five minutes to remember the 'public' keyword that has to preceed everything.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// Point.java
package test;
public class Point {
    int x;
    int y;
    Point(int X, int Y)  {
        x = X;
        y = Y;        
    }   
}
// Test. java
package test;

public class Test {
    static public int add(int a, int b) { return a+b; }
    static public int increase(int a) { a = a+1; return a; }
    static public void increase(Point p) {
        p.x = p.x+1;
        p.y = p.y+1;
        return;           
    }
    public static void main(String[] args) {
        int myA = 6;
        int myB = increase(myA);
        Point p = new Point(myA, myB);
        increase(p);
        System.out.print(p.x + p.y);
    }
}


Theory:
If Java passes by value, then myA should be 6, myB 7, p (6, 7) and the output 13.
If Java passes by pointer, then myA should be 7, myB 7, p (8, 8) and the output 16.
If Java passes primitives by value and the rest by pointer, then myA should be 6, myB 7, p(7, 8) and the output 15.

Result: I get 15 as output.

Now, to test my memory (I messed up a piece of code I had to hand it because I didn't realize class copies were not deep copies), I added the line:
1
2
        Point q = p;
        increase(q);

The output changes to 17, confirming my memories of copy-by-reference/pointer.


[I don't know if this even remotely relates to what was being discussed, but it confirms what I remember; the way I understood rapidcoder's statement, this example disproves it.)
Pages: 12345