Slashdot Mirror


Java To Overtake C/C++ in 2002

jarek writes "ZDNET has an article that talks about latest research data. It talks about how Java is overtaking C/C++ next year. The article also talks about developers adopting linux and putting linux to use in mission critical tasks." It's evidently taking developers from the C/C++, but also the Visual Basic camps, with strong growth overseas.

9 of 605 comments (clear)

  1. Re:really? by WolfWithoutAClause · · Score: 3, Informative

    Um. AltiVec's C API is presumably coded in assembler. So you can't do really fast DVD in pure C either.

    Anyway, you can call C APIs from Java. So, yes you can write a DVD in Java, as much as you can write it in C! All the hardwork is done in assembler anyway...

    There's probably nothing that C compilers do that can't be done by a Java VM. Some of the VMs use C backends anyway.

    (Not that I'm claiming that current Java VMs are optimising for vector stuff, they may very well not be).

    >I'm having trouble imagining a Java tool that could automatically
    >vectorize code where Java has no way to express vector operations.

    Well, Fortran can optimise vector stuff fairly well. If the VM spots similar structure in a Java program it may be able to implement the same optimisations. I'm sure the devil's in the details, but it's not impossible.

    --

    -WolfWithoutAClause

    "Gravity is only a theory, not a fact!"
  2. True, to an certain extent by roguerez · · Score: 5, Informative

    With JIT compilers becoming faster and faster, and the paradigm shift of user applications from autonomous programs to web applications, Java is becoming more important.

    However, C and C++ will remain very important, for example for system programming. A lot of Unices, MacOS and Windows are built on these two languages. Component, object and application frameworks like MFC, KDE, QT are written in them. A very large application base is written in them and it will not be replaced overnight.

    I don't think Java will ever completely take over C/C++, simply because the hardware accessibility just isn't in Java and you need it when programming an OS.

    But when building a new application, Java is more often than not a better choice than C/C++, simple because it was build with networking in mind.

  3. Re:C vs C++/Java by scruffy · · Score: 3, Informative
    I look forward to taking the plunge into Java. I'll skip C++.
    I can agree with that. I have been hoping for some time that I wouldn't have to learn C++ very deeply.

    Both C and Java are nice languages because they are small and are appropriate for particular tasks, roughly "low-level" and "high-level" applications. As a language, it seems that there is too much in C++ to be able to learn it well, and C++ tries to have it both ways. Garbage collection in particular is very nice to have for "high-level" programming because it removes one large set of "low-level" details to worry about (or at least, worry a lot less about it). Two more messy low-level details missing from Java are include files and make files. I think we can live without them for many programming tasks.

  4. FUD alert by Anonymous+Brave+Guy · · Score: 4, Informative
    I recently read an article where Bjarne outlined many of the things he had on the C++ wishlist, which more or less were the steps to make C++ into Java.

    Stroustrup's presentation notes can be found here (PDF format). I invite anyone interested in knowing what he actually said to take a look. It certainly doesn't sound much like Java to me.

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  5. But what is "speed"? by e2d2 · · Score: 3, Informative

    Well I guess it depends on how you measure "speed". Do you mean perfomance time related to the application itself or do you mean time to market? Which is more expensive for a company - hardware or humans? The human cost is often overlooked when we speak of how "speed is of the essence".

    I know plenty of developers that like Java simply because it's easy to program and you can roll out applications relatively quickly when compared to C++. Now I know that statement is opinion and everyone has an opinion, but saying that Java is slow is misinfomed. Given that applications are so network-centric these days, Java can truly shine in a server environment where the resources are plenty.

    But to be honest, comparing these two languages is not fair. Here is a good article on why they are apples an oranges

  6. office suite by Misha · · Score: 3, Informative

    I don't know about CD-R or DVD (though I suspect most limitations consist of the lack of a hardware speaking interface in Java), but with the Office suite comment, you are refering to the lack of a fast windowing toolkit for Java.

    Believe it or not, that's about to change. If you've ever seen IBM VisualAge environment, you should know that's written in Java. The window speed is just as fast as any office suite. I was surprised just how fast it was.

    The people who wrote VA work for a company called OTI. The windowing kit they used was something proprietary and closed called JFace, but from what I understand, they are ready to release and open-source it to the public in the next few months, although the website is password protected right now.

    Don't sell Java short. it's not system level programming, but it's hardly something to be dismissed as 'too slow'.

    --



    I was thinking of how to intentionally fail my drug test... It would make a good memoir story someday.
  7. Re:Other languages and bytecode? by skullY · · Score: 3, Informative
    The bytecode idea is a really good one, especially with the large (although shrinking) number of platforms you have to support these days, and the possible rise of VLIW processors on the horizon. I don't really like coding in Java all that much, though. Is anyone working on a compiler for another language that compiles to bytecode that will run on a JVM (rather than a internet-c or c# vm)?
    Jython (Used to be JPython) does exactly that. Jython is a python intrepreter written in Java, that can compile your script into Java bytecode if you want. And, according to the preface of Programming Python, there's a company that's building yet another python compiler for the .NET framework.

    Not to meantion that python is OO, and being Free Software will probably overtake Java in a couple years anyway. ;=)

    --
    When I was able to do my own spam-armoring, you got a chance to email me. Now you can only hope I see your reply.
  8. Re:really? by Jeffrey+Baker · · Score: 3, Informative
    You wouldn't be able to write a software DVD player in pure Java on today's CPUs and today's Java runtimes. Software DVD players rely on the CPU's vector or SIMD processing facilities, like MMX, SSE, and SSE2 on Intel, or AltiVec on PowerPC. Last I looked, there wasn't any way to access this stuff from Java. To take advantage of the hardware, the Java runtime would need to recognize computation loops, unroll them a bit, stuff the operands into right registers, and execute the desired operation. Even then, the C or assembly routines in use today are so fast because they get the instruction scheduling just exactly right. Without precise control over instruction scheduling, you'll stall the CPU and that's the last thing you want in a software DVD player.

    AltiVec's C API is the highest-level vector API I've used. It has unambiguous and standard C syntax extensions for vector operations. Yet, we still don't have C compilers that can automatically vectorize code. I'm having trouble imagining a Java tool that could automatically vectorize code where Java has no way to express vector operations.

    Maybe you could write a Java DVD player that was the equivalent of cat /dev/dvd /dev/hardware-mpeg2-decoder-device, but that's about the extent of what you could do in today's Java.

  9. Re:Java Portable Apps? by siegesama · · Score: 3, Informative


    Processor power is up, and cheap. Architecture isn't standard. Write a VM once for an architecture, then you can run all your pretty PDA Java applications irregardless of what you're running them on. You're suggesting that every portable-item have all of its applications coded specifically for it. Even if the only games in the world were solitaire and nibbles, that's a lot of applications to re-write everytime a new device comes out with a slightly different architecture/instruction-set/whatever.

    Oh yeah, and Java is a buzz-word. Makes people happy when they have a buzzword-compliant item. The toys just seem so much COOLER then.

    --
    what the hell is a 'junk character', anyway?