• Tama (unregistered) in reply to far9999
    far9999:
    I don't think you are understanding the constant deal correctly. C++ has const correctness (http://en.wikipedia.org/wiki/Const_correctness) which both Java and C# are missing.

    Basically in Java and C# there is no way to guarantee that a method you call doesn't mess with the internals of your object (unless your object is immutable). This is possible in C++.

    Correct. As explained above, you have to have an immutable object or wrap it in an immutable container.

    Practically, when confronted with this kind of problem, I do something like this:

    private static final Set<String> _CONSTS = new HashSet<String>();
static {
  // Strings are immutable, so we're safe; if we were dealing with non-immutable classes
  // in the collection, we'd have to wrap them too
  _CONSTS.add("foo");
  _CONSTS.add("bar");
}
public static final Set<String> CONSTS = Collections.immutableSet(_CONSTS);

    As for the whole references / value: in Java, primitives are passed by value, and for everything else, a reference to the object is passed by value (meaning the object pointed to can be altered if possible, but not the memory location of the object).

  • Tama (unregistered) in reply to Tama
    Tama:
    public static final Set<String> CONSTS = Collections.immutableSet(_CONSTS);

    I meant Collections.unmodifiableSet(...), but the rest is correct.

  • (cs) in reply to lol
    lol:
    TRWTF is letting the customer establish language platform as a functional requirement.

    If you read it again, FooNorsk designed and was building the system, they needed ACME to develop parts of it. And of course, the platform was already chosen.

  • (cs) in reply to ell0bo
    ell0bo:
    This reminds me of a project from college. I had to design an AI to trade stocks. I wrote the beta in C++, but then so my team could more easily work with me I rewrote the code in Java. It wasn't running very fast, so and I realized I could speed it up if I ran multiple threads. Well, this would be true if Java didn't go from a slight memory hog to a devourer of all memory as soon as you start forking off processes. My prof told me no one ever managed to kill the server before, I was kinda proud (and I had the spawn limit set to only 4 threads. When we got the proof of concept working, I rewrote it in C++, and it brought a tear to my eye.

    I once wrote an application in Java that spawned hundreds of threads to run perform concurrent tasks for several days. Although it was a memory hog, I find it hard to believe your application screwed up so badly. Either you coded it extremely bad, your teacher can't properly configure a server, or you're just trolling.

    What do you mean by forking processes? Are you talking about processes or threads?

  • Dirk Diggler (unregistered) in reply to xtremezone
    xtremezone:
    A compiler will make better optimizations than 99% of us can. So a program written in C or C++ will probably be near equal to or probably even faster than the equivalent program written by the same programmers in assembly.
    The 1% that can beat the compiler intersects nicely with the programmers than CAN program in assembly. The rest of us need to stick with higher level languages.
  • (cs) in reply to xtremezone
    xtremezone:
    Again, you're using C-like syntax to make it appear the same, when in reality there are very different semantics in Java. One of the things I find extremely ugly about Java code is that there are no operator overloads (except for those provided as part of the language, like operator+ for String) which results in lots of verbose, nested method calls with really long lines (or that many more lines if you split it up). 
    // Java
MyNumberClass number = new MyNumberClass(5);
MyNumberClass number2 = new MyNumberClass(6);
number = number.divideBy(number2.multiplyBy(number.add(number2))).subtract(number2);
    // C++
MyNumberClass number(5);
MyNumberClass number2(6);
number = (number / (number2 * (number + number2))) - number2;

    Fair enough with MyNumberClass, but it is a total WTF to assume that non-number classes need the ability to overload these.

    Dog dog = new Dog("Shih Tzu);
Cat cat = new Cat("Persian");
animal = dog + cat;
if (animal == somethingFingUgly) {
  postComment("Obviously");
}

    Far less than 1% of classes are numbers and assuming that these corner cases need a universal feature of the language is a proof by example.

  • (cs) in reply to Franz Kafka
    Franz Kafka:
    If you can't outthink a marketer, then I'm very sorry.
    My job isn't to make assumptions. Assumptions lead to mistakes. I'm also not interested in anything that needs to be falsely advertised.
    Franz Kafka:
    No, strings are not just arrays of chars, they are strings that happen to be stored as an array. Java Strings are an improvement over the mishmash of C++ string classes and I like them a lot better. If you don't like the slightly better abstraction, that's fine, but it isn't Java's problem.
    Perhaps "array" is too low-level for you. Sequences of symbols is how Wikipedia chooses to define it.

    http://en.wikipedia.org/wiki/String_(computer_science)

    Franz Kafka:
    public static final String CONSTANT="Some stuff"
    Does that hold up for a method parameter?
  • (cs) in reply to Franz Kafka
    Franz Kafka:
    Do tell: how do Java constants differ from C# constants? Specifically, why is the Java constant 'fake'?

    If my failing memory serves, the only place in compiled Java bytecode where a static final is referenced is the point where it was defined - every other occurrence would have been replaced by its value; the reference is only kept to maintain the interface. But this is the same behaviour as a C# const. So I'm curious, too.

    It's C#'s static readonly members that are the fakes: the substitution isn't made until runtime (or at least jitting). Why the delay? It's not like the value will change in the meantime, is it?

    A static readonly member might look and behave a lot like a const (except that a const is limited in what it can contain compared with a readonly), but if you change a const you have to recompile every module that references it, while changing the member only requires recompiling the module in which it's defined (all the others would obtain the new value at runtime).

  • shishkabob (unregistered) in reply to d3matt

    A least with Dick & Rod being the protagonists, we can be confident that he didn't mean homophobe.

  • (cs) in reply to dkf
    dkf:
    If you claim operator overloading, then you also have to explain why shift operators make sense for I/O and how it is much easier to look at a bit of code and work out what it is really doing (where the costly activities are) with C++ given that virtually any symbol (and even some places without symbols) can be assigned near-arbitrary semantics.

    Java makes you write out what you mean. This is certainly more bureaucratic, but it makes the life of maintenance programmers much better. That's really important for a lot of software...

    I have two responses to this. Firstly, I was just discussing this on a game programming forum. If you consider UNIX shells, they've been using angle braces to redirect streams for decades (I don't know how old it is, but my impression is that it's about as old as UNIX itself; I could be wrong). For example:

    echo foo 1>>bar

    Which for those that don't know, would redirect stdout (i.e., 1) to append to a file named "bar".

    Further, while you're free to implement operators any way you want in C++, best practice is to obviously not abuse it (documentation should explain what does occur and a reasonable developer should say WTF to something that doesn't make sense and look for an alternative). However, note there's nothing stopping you from implementing this in Java:

    public class MyNumber
{
.
.
.
    public MyNumber Add(MyNumber rhs)
    {
        return new MyNumber(this.getInt() - rhs.getInt());
    }
}

    Basically, common sense always plays a factor. Sure, operators can be abused, but any language feature can be abused. That's where best practices play a role. You wouldn't likely use a framework that did something like this in Java, and similarly you wouldn't likely use something illogical in C++ (or C#, which also supports operator overloading).

    The bitshift operators make excellent stream IO operators, IMHO. Some argue that operator+ (and I assume operator-) would make more sense, but those operators are much more likely to be put to use more often.

    // Existing syntax with potential bitshift:
std::cout << (a << b) << c;

// Alternate syntax 1 with potential arithmetic:
std::cout + (a + b) + c;

// Alternate syntax 2a:
std::cout.append(a << b);
std::cout.append(c);

// Alternate syntax 2b:
std::cout.append(a + b);
std::cout.append(c);

    Honestly, I like the stream IO operators. I think they were the best choice.

  • (cs) in reply to ell0bo
    ell0bo:
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?

    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

    The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

    But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.

    This reminds me of a project from college. I had to design an AI to trade stocks. I wrote the beta in C++, but then so my team could more easily work with me I rewrote the code in Java. It wasn't running very fast, so and I realized I could speed it up if I ran multiple threads. Well, this would be true if Java didn't go from a slight memory hog to a devourer of all memory as soon as you start forking off processes. My prof told me no one ever managed to kill the server before, I was kinda proud (and I had the spawn limit set to only 4 threads. When we got the proof of concept working, I rewrote it in C++, and it brought a tear to my eye.

    Proof that in college you wrote crappy java programs. Bravo, sir. Sounds like you will soon be proud of many achievements noted here.

  • Wayne D. (unregistered) in reply to BoomWav

    Well, it should be. Sometimes flashy new features are WAY WAY more important than performance, which is WAY WAY more important than stability, which is WAY WAY more important than maintainability.

  • Anon (unregistered) in reply to Watson
    Watson:
    Franz Kafka:
    Do tell: how do Java constants differ from C# constants? Specifically, why is the Java constant 'fake'?

    If my failing memory serves, the only place in compiled Java bytecode where a static final is referenced is the point where it was defined - every other occurrence would have been replaced by its value; the reference is only kept to maintain the interface. But this is the same behaviour as a C# const. So I'm curious, too.

    No, Java classloading is far more screwed up than that.

    If you define a static final field of a primitive type, the bytecode for the given class may (at the discretion of the compiler) replace the value in the bytecode. It can do that because the value doesn't have to be determined during linking.

    However, if the final field is referenced outside that class (note that inner classes count as "outside that class"), then the final field is always compiled as a reference, since the value isn't known until runtime.

    The JIT compiler is free to detect that something is a constant and then rewrite the code such that it's constant, but that's an additional process beyond the initial compile step. C#'s constants avoid that extra linkage penalty.

    An even more screwy case is when you have a final primitive field where the value isn't set until runtime. These are always references, since the value isn't set until runtime - which means that even if it's a primitive type, it still has to be referenced.

    Yes, you can make final static fields be determined at runtime, thanks to static initializer blocks. It ensures that the compiler can never inline the value.

  • (cs)

    A lot of interesting comments to read, although there are quite a few that are rather poorly corroborated.

    At our place, we use Java almost exclusively. Why? Because it works best for us. We're a mobile phone company (in a rather small country), so we deal with large amounts of data. But this data is usually stored in a database, in which case a lot of the crunching takes place there.

    If it comes to raw number crunching speed, C or C++ will indeed be faster, but since we don't do aircraft design or simulating nuclear explosions, that is not an issue: Java is fast enough for what we do.

    We develop on Windows, and run on Solaris, Linux or the few Windows servers we have left. The maintenance people don't like Windows very much, because it's a bitch to administer remotely, what with all the limitations you have on number of users, and they're virtualising everything. Quite apart from the operational expenditure of Windows licences.

    But the platform-independence is more a convenience than a deciding factor. Java's strength lies in its large standard library, the number of available third-party libraries, and the nice way it abstracts things from you like database access.

    Yes, JDBC has plenty of weaknesses, but I'm yet to see a standard library for C++ that both compiler suppliers and database engine suppliers use. Oracle gives you ojdbc6.jar and you know it'll work on your system, whether it's Windows, Solaris, Linux or anything else that runs Java.

    Another thing about Java is that it's a resource hog. Netbeans easily gobbles up hundreds of megabytes, and what for? But on the other hand, what's cheaper: a better kitted out computer, or paying a developer? We've found that C++ development takes a lot longer, because whilst you have all this power, it doesn't have a great deal of convenience, and as a result, applications take longer to develop.

    Certain things, though, I wouldn't do in Java if my life depended on it. BER decoding, for example. Not having unsigned integers and not having mmap() is a major headache, so this I do with a combination of C and Perl.

    C++ may be a Formula 1 car compared to Java being a family car, but very few people can drive a Formula 1 car without crashing it.

    All in all, Java gives us the lowest capital and operational expenditure overall. That's what keeps our development section from being outsourced to India.

  • JoJo (unregistered) in reply to Zapp Brannigan
    Zapp Brannigan:
    My mom and dad had their budget in an Excel spreadsheet and they were constantly asking me for help. I re-wrote spreadsheet as a Java application and now they never ask for my help. Java Rules!

    Yeah, I've also written software that bad in order to get people to stop bugging me...

  • Kimbo Slice (unregistered)

    COBOL Rulez

  • Jimmy Jones (unregistered) in reply to BoomWav

    "In a enterprise environment, maintainability is WAY WAY more important than performance most of the time. "

    Does Java have some special magic that makes it easier to maintain...?

  • dude (unregistered)

    Indeed it's slow! Hate when I have to use any of Java software

  • (cs) in reply to Jay
    Jay:
    Anon:
    The reality is that Java remains to this day far slower than an application that gets compiled to native code.

    The Just-in-Time compiler that came out with, what was it, Java 2.4?, really puts Java into a different league from version 1.

    Java 6 so fast that it can execute an infinite loop in 12 seconds.

    I tried to run this benchmark with Haskell but it can't do loops.

  • Bench Marker (unregistered)

    Java vs. C benchmark:

    http://www.stefankrause.net/wp/?p=9

  • Anonymous (unregistered) in reply to dkf
    dkf:
    If you claim operator overloading, then you also have to explain why shift operators make sense for I/O(...)
    Yes, language features can be abused.
    Java makes you write out what you mean.
    No it doesn't. It makes you fall back to the few native types more often than it is useful, or otherwise leaves you with unreadable arithmetic expressions.

    Think of it the other way around: Why should there be a fixed set of "special" types? Java developers should have been honest and abolished every operator except "." if they thought this way lead to more expresiveness. They didn't, because obviously, it's ugly.

    Take a look at Ada, which certainly is the essence of "write out what you mean": Allows operator overloading. Why? Because Ada strongly discourages (ab)using the built-in types for everything. (It allows you to e.g. declare two integer types that behave identical but are incompatible with each other.) So if operators couldn't be overloaded, it would be almost pointless to have them in the first place.

    Operator overloading provides you with a great chance of extensibility and readability in arithmetic expressions. Of course only small parts of most programs deal with arithmetic, but these are usually also the most tricky ones.

  • (cs) in reply to far9999
    far9999:
    I don't think you are understanding the constant deal correctly. C++ has const correctness (http://en.wikipedia.org/wiki/Const_correctness) which both Java and C# are missing.

    Basically in Java and C# there is no way to guarantee that a method you call doesn't mess with the internals of your object (unless your object is immutable). This is possible in C++.

    The existence of const_cast<T> or similar methods to forcibly throw out const, ways to access private class members by using raw memory offsets, etc. all guarantee that C++ can't guarantee const correctness. It's a programmer's aid and that is all it is.

  • (cs) in reply to MichaelWH
    MichaelWH:
    Jay:
    Anon:
    The reality is that Java remains to this day far slower than an application that gets compiled to native code.

    The Just-in-Time compiler that came out with, what was it, Java 2.4?, really puts Java into a different league from version 1.

    Java 6 so fast that it can execute an infinite loop in 12 seconds.

    I tried to run this benchmark with Haskell but it can't do loops.

    Haskell can't do loops but it can do infinite recursion in constant time.

    iterate          :: (a -> a) -> a -> [a]
iterate f x      =  x : iterate f (f x)
  • (cs) in reply to xtremezone
    xtremezone:
    If you consider UNIX shells, they've been using angle braces to redirect streams for decades (I don't know how old it is, but my impression is that it's about as old as UNIX itself; I could be wrong).
    You'd be right; they were in there within the first few months, so they've been there for nigh on forty years now.

    (Dennis Ritchie's first hand account, which specifically mentions the pipeline model.)

  • someguy (unregistered)

    The reason "Java is slow" gets passed around so much is that so many things which display the java logo are so slow. Maybe there's something about the language which is secretly fast, but capabilities mean nothing to what is actually perceived if the end result is: Java logo next to something unusable.

    To give a couple of examples:

    • OpenOffice. Very very very very slow.
    • Eclipse. Very very very very very very very slow.
    • Every "Java Applet" ever: may as well re-write it in flash in the time it takes to respond
  • Foobar (unregistered) in reply to snoofle
    snoofle:
    Re the Java-is-slow debate...

    Good code can be written in any language.

    Wrong! I know of at least one language that makes it impossible to write good code: Fortran 77. Malbolge, Intercal, whitespace, and brainfuck are also contenders.

  • Roy T. (unregistered) in reply to SomeCoder
    SomeCoder:
    Zer0:
    snookerdoodle:
    I once interviewed for a project that would use my experience in both C++ and Java: they wanted to convert a desktop client application from Java to C++ because the application had memory leaks and they heard you had more control over memory allocation in C++.

    I called the headhunter as soon as I walked out and told him I didn't think I'd be a good fit there.

    Hahahaha. That was worth reading through all the crap about managed code being so much slower than native code. Anyone see Quake ported over in C#?

    I've seen the Quake 2 port from C to C++.NET (CLR). It was quite a bit slower but in practice it was at least playable. The framerate suffered more than I would have liked for a video game though

    True, but that's because the .Net platform is optimized for database and backoffice applications, not for games, where as C/C++ is optimized for nothing/everything. Functions on Vectors, Floats and Matricres are therefor not as fast in .Net as in C++, and a game uses allot of those. So yeah, for making full blown games C# and Java are not a good choise, however for (boring) database interacting applications (like say 99% of all the applications written). C#/JAVA/C++ are all valid candidates depending on the requirements.

  • mauhiz (unregistered)

    Now that guy is the real Dick!

  • London Developer (unregistered) in reply to d3matt

    Homophobe???

  • IByte (unregistered) in reply to Jay
    Jay:
    Java 6 so fast that it can execute an infinite loop in 12 seconds.
    ...wait, what?

    (CAPTCHA: Abbas. Is that a political statement?)

  • (cs) in reply to Gerrit
    Gerrit:
    insquinormalc:
    I have *never* met a date library I liked.
    Try dating humans.
    Unfortunately she slapped my face when I asked her how old she was. I doubt carbon-dating would give accurate results . . . what other method is there?
  • (cs) in reply to someguy
    someguy:
    The reason "Java is slow" gets passed around so much is that so many things which display the java logo are so slow. Maybe there's something about the language which is secretly fast, but capabilities mean nothing to what is actually perceived if the end result is: Java logo next to something unusable.

    To give a couple of examples:

    • OpenOffice. Very very very very slow.
    • Eclipse. Very very very very very very very slow.
    • Every "Java Applet" ever: may as well re-write it in flash in the time it takes to respond

    Have you actually looked at a Java desktop application in the last, say, 10 years? Or maybe you still have a Pentium II based computer with 128 MB of memory?

    The computers I use aren't exactly premier league (an AMD Athlon 2.2 GHz and a Core 1 Duo laptop), but to call the Java applications I use (mostly Netbeans) slow? No. Memory hogs, oh yes, but not slow. Just make sure you have 2 GB of memory.

    Anyway, everybody knows that Java on the desktop is as good as dead, but that it's extensively used in back-end server applications for the reasons I pointed out a few posts up.

  • Burp (unregistered) in reply to Jimmy Jones
    Jimmy Jones:
    >"In a enterprise environment, maintainability is WAY WAY more important than performance most of the time. "

    Does Java have some special magic that makes it easier to maintain...?

    The magic of trying to hide this deadly weapon people call pointers manipulation. Let's face it, 2/3 or more of the so called "software professionals" have no idea how to correctly deal with memory. A language with which you can't do anything is a language with which you can't do any harm...

  • (cs) in reply to Severity One
    Severity One:
    Just make sure you have 2 GB of memory.
    Even 1GB is fine when running Eclipse, but 512MB was painfully slow.
  • OldHand (unregistered) in reply to Daniel
    Daniel:
    Why do you keep discussing these outdated languages? Learn Scala and get on with the program.

    Agreed.

  • A Developer (unregistered)

    Java is poo.

  • OldHand (unregistered) in reply to OldHand
    OldHand:
    Daniel:
    Why do you keep discussing these outdated languages? Learn Scala and get on with the program.

    Agreed.

    For those unaware of Scala, it can use alla existing Java libs, compiles into class files and runs on the JVM. Also, it allows operator overloading, including using funny Unicode symbols. Mixed blessing?

    See http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html for a hilarious progression of languages, with Scala at its apex.

  • Delk (unregistered) in reply to Franz Kafka
    Franz Kafka:
    It's cheaper to spend a bit more (50%, say) to make a java web app run well than it is to write it in C++, mainly because C++ sucks from a dev time perspective. Sure, if you're shipping to a million people, 1 second saved is a big deal, but we're talking about web apps and backend processing.

    Exactly, and that's what most people seem to be missing here. We're talking about backend processing, not a direct desktop application, so even if a desktop application such as Eclipse is pretty resource-hungry, that doesn't mean it's relevant for a server application.

    If the application is built to be scalable e.g. for multiple cores, and you add in load-balancing and stuff, you can improve performance simply by adding hardware. You can't really do that with a desktop computer, not for a reasonable price anyway, but for server-side systems you can. If you can save a few man-months of development time by investing a few thousand dollars/euros/whatever more on hardware, it makes sense economically.

  • Tom (unregistered) in reply to dpm
    dpm:
    Gerrit:
    insquinormalc:
    I have *never* met a date library I liked.
    Try dating humans.
    Unfortunately she slapped my face when I asked her how old she was. I doubt carbon-dating would give accurate results . . . what other method is there?

    Of course carbon dating wouldn't give you her age accurately: Carbon dating tells you how long an object has been dead, so unless you were dating a zombie, it would always give 0.

  • bd (unregistered) in reply to Jimmy Jones
    Jimmy Jones:
    >"In a enterprise environment, maintainability is WAY WAY more important than performance most of the time. "

    Does Java have some special magic that makes it easier to maintain...?

    - already mentioned lack of pointers and automated memory management - simplified language (no Obfuscated Java Contests, no template wizardry or Pythic compiler errors) - platform independence that goes beyond basic computation - stack trace with line numbers after a crash - always present remote debugger and a development culture where you don't strip symbols from built applications
  • far9999 (unregistered) in reply to Tama
    Tama:
    Correct. As explained above, you have to have an immutable object or wrap it in an immutable container.

    Practically, when confronted with this kind of problem, I do something like this:

    private static final Set<String> _CONSTS = new HashSet<String>();
static {
  // Strings are immutable, so we're safe; if we were dealing with non-immutable classes
  // in the collection, we'd have to wrap them too
  _CONSTS.add("foo");
  _CONSTS.add("bar");
}
public static final Set<String> CONSTS = Collections.immutableSet(_CONSTS);

    As for the whole references / value: in Java, primitives are passed by value, and for everything else, a reference to the object is passed by value (meaning the object pointed to can be altered if possible, but not the memory location of the object).

    You are right - I got a little bit hung up on the parameter thing... Really it applies everywhere. You can write a getter function that returns a const reference to an object and the caller cannot modify that object. There are ways to approximate this in Java/C# but they aren't anywhere near as clean.

    What is up with the lack of unsigned value types in Java. That's just stupid!

    Not that I have anything against Java - I'm programming in it right now....

  • RandomUser223957 (unregistered) in reply to Jay
    Jay:
    Anon:
    Fedaykin:
    What "special servers" and "special software" do you think is required to run Java?

    Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

    Well, last I checked C++ apps require that you have numerous libraries installed. A decent install program for a Java app will have to install the JVM, just like a decent install program for a C++ app will have to install a bunch of libraries. I don't see that as a truly qualitative difference.

    I'm surprised that Sun hasn't made it easier to install the JVM -- at least as of when I was last working with desktop apps, maybe they've done it better by now. (These days I'm on web apps, where I don't ask the user to install anything besides a browser.) But you write your own installer for it once and re-use it for every app and it doesn't really matter.

    As may or may not have been pointed out by now, C and C++ apps can usually be compiled against static libraries, which does increase the size of the resulting binary, but eliminates those "numerous libraries...[the] app will have to install" that comprise the runtime, et al. So, one file (EXE) versus JVM + Java file(s).

    Of course, the comparison isn't entirely fair, because in any case where common libraries are used, once they are installed for one app, they don't have to be for any additional apps that use them.

  • (cs)

    I would be more open to Java if it was compiled down to native code instead of byte-code. A release build of a particular version of a program is only going to be compiled once. I'm fine with compiling separate programs for each platform if it means I can get rid of the performance penalty of running an extra layer above the OS.

    I mean, to me, JIT means "recompile every time you run the program" whereas it could be done once and you'd have a native build... :-/ Even if the byte-code concept was kept, but instead of JITing byte-code every time, compile the byte-code down to a native binary on the first run and cache it in a secure directory somewhere. Win. From there, re-running the program would consist of hashing it to identify the cache and running the native build.

    Why not?

  • Georgem (unregistered)

    The reality is that Java remains to this day far slower than an application that gets compiled to native code.

    The reality is that that myth was de-bunked years ago. In some circumstances, Java has even been observed to out-perform the equivalent C++ code. It's true that for any trivial snippet of Java code, the equivalent C++ code will be quicker, but software isn't a trivial snippet of code, and the optimisations that, say, HotSpot, provides, blow this long-standing Java myth out out of the water.

    Next

  • Georgem (unregistered)

    TRWTF is letting the customer establish language platform as a functional requirement.

    Not really. Java isn't merely a programming language, it's a platform. If an enterprise has decided on a specific platform, then so be it

  • Blitz (unregistered) in reply to insquinormalc
    insquinormalc:
    You think Java code is "ugly" and the "language semantics are a bitch", but would code in C#? Perhaps there's some other language called C# out there that I'm not aware of, but the one I use looks 95% the same as Java.

    Yeah, you're using C-sharp, and he's using C-pound.

  • Lego (unregistered) in reply to MichaelWH
    MichaelWH:
    Jay:
    Anon:
    The reality is that Java remains to this day far slower than an application that gets compiled to native code.

    The Just-in-Time compiler that came out with, what was it, Java 2.4?, really puts Java into a different league from version 1.

    Java 6 so fast that it can execute an infinite loop in 12 seconds.

    I tried to run this benchmark with Haskell but it can't do loops.

    Brainfuck anyone?

  • (cs) in reply to Gewn
    Gewn:
    sylvic:
    EmperorOfCanada:
    P.S. I use Eclipse for most coding and am regularly reminded that Java apps are almost always twitchy apps. Please find me a multi platform, multi language IDE developed in C++ please.

    emacs

    I believe emacs is developed in LISP not C++

    Actually, I think the core is C, not C++, but the rest is in LISP.

    Still, it meets the spirit of the the request. Fast, multi-language, and doesn't hog resources. I have 40+ buffers open atm (Java, .NET, news, mail, shells, ...) and only using ~25MB of RAM.

  • (cs) in reply to Blingot
    Blingot:
    Errm...I don't think a special runtime needs to be installed before a c++ app can be run (unlike the Java which [I think] needs the JRE installed)
    Lolwut? Take a fresh install of Windows XP, create a test file, Test.cpp, and then try to run "gcc Test.cpp". You won't be able to because the OS has no fucking idea what gcc means, until you do what? That's right: install something. So, install the necessary files to compile and run C code or downloading the Java runtime is, well, about the same.
  • (cs) in reply to amischiefr
    amischiefr:
    Blingot:
    Errm...I don't think a special runtime needs to be installed before a c++ app can be run (unlike the Java which [I think] needs the JRE installed)
    Lolwut? Take a fresh install of Windows XP, create a test file, Test.cpp, and then try to run "gcc Test.cpp". You won't be able to because the OS has no fucking idea what gcc means, until you do what? That's right: install something. So, install the necessary files to compile and run C code or downloading the Java runtime is, well, about the same.
    After installing your toolchain, compile your C++ program and statically link it with all required libraries, then take the resulting executable to a freshly installed OS and try to run it. There you fucking go. Try that with Java. Oh wait, you need extra tools to run Java programs. Right.

    Dynamically linked libraries are not even a C++ thing. They are an executable thing. Everything could be statically linked, but there are advantages to dynamically linking.

    It is in no way the same thing as Java's VM. It's ridiculous to claim that it is. Java programs run a layer above native programs. You can't compare that. It's different. Until that layer is eliminated and you no longer need to run your program through a native program, STFU, KTHX.

Leave a comment on “Java is Slow!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article