Posted by
Hemos
on from the it's-new-it's-fast dept.
scode writes: "IBM's has finally
released
a preview of their JDK 1.3 for Linux, and it's just as fast as their 1.1.8!
This is great news for Java on Linux, because it's the first Java 2 compliant Linux JVM that's really fast. "
Non-x86 Linux users in the dust, as usual
by
Gepard
·
· Score: 4
Good job, IBM. It's wonderful that support is so forthcoming. Though naturally, when someone says ``available for Linux,'' they really mean ``available for Intel Linux.''
Users of all other Alpha Linux are screwed. PowerPC Linux. UltraSPARC Linux.
Oh well, that's the real world, isn't it? It'd be nice if there at least was some source code to play with on other architectures. But that, naturally, isn't forthcoming.
Re:Non-x86 Linux users in the dust, as usual
by
c_chimelis
·
· Score: 3
The argument about development and testing costs not being justified for little-used port platforms is easily rendered moot by one fact: they're giving this away. Sure, they may base a commercial product on it and, sure, that will cost money to develop and test on every platform/OS combination under the sun, so I could understand limited availability for commercial software. What I object to is that these "freely available" packages (especially JDKs, it seems) are really just a way for companies such as IBM, in this case, to tout their name as "supporting Linux". If they want to save a whole bunch of money on development and testing, give *US* the source and let us do the porting and tinkering that it takes. That's free labour! And would make the "lesser-used" port users happy as well. Also, bear in mind that some of the architectures, while technically in the minority as far as numbers go, are much more powerful and used more as larger scale servers than the often cheesy Intel machines that make up that "large market share". Let's face it, how many Intel-based desktops would it take to run some of the larger sites on the net?
Re:Native threads?
by
Anonymous Coward
·
· Score: 2
blackdown's 1.2 uses --native threads. that cant be more than three or four months old.
GNU GCC currently ships with a pretty decent Java compiler, that can be used with libgcj in order to write native apps. I have no idea how complete libgcj currently is.
GCJ is slower than IBM's JDK. THis is because IBM's JDK is fucking fast. It depends on your application. gcj is faster for some code, but the IBM JDK is still faster for others (but gcj is improving quickly). There is allways less startup overhead with gcj because It is true that some optimizations can only be made at runtime by a dynamic compiler, however others (due to high computational cost) can only be reasonably be done in a traditional, ahead-of-time compiler. The solution to this and other problems with ahead-of-time java compilers (like TowerJ and gcj) lies in providing a mixed-mode environment, where application code is dynamically loaded and compiled against pre-compiled libraries. If the standard java libraries are precompiled, you avoid a large amount of application startup overhead. But with application code running on a JIT, the advantages of dynamic compilation and the platform-independent bytecode format are maintained.
There are many of them. To give one for all imagine this:
if cond then some_code else some_code2 endif
Now, imagine that the some_code2 is executed in 99%. This can't be easily found out but it's relatively easy to do it at runtime. Analogously with types and type checking, loops, and garbage collection.
I have an alter-ego at Red Dwarf. Don't remind me that coward.
The IBM JDK is an implementation of Java Platform 2 version 1.3. This is the absolute latest spec, and is so new that the SUN JDK hasn't been released in FCS format yet.
JDK 1.2 was re-named Java Platform 2 as part of the re-arrangement of the Enterprise, Standard and Micro editions. See SUN's Java site for more information on this, and the differences between the versions.
IBM are definitely at the head of the queue for this one !
I'm looking forward to being able to use some critical Java Platform 2 features, and remember this is the enabling technology for Enterprise Java Beans...
As a programmer, one thing Java is lacking is hardware acceleration of windowing widgets.
In any OS worth mentioning standard windowing calls (such as pulling down a menu or pushing a button) make specific calls to the video hardware. Sun's JVM, however, does not accelerate swing components, relying instead on your CPU to draw them.
There is no reason the VM cannot make calls to specific hardware, as we all know they're written for specific platforms. In fact, I am told that the VMs for Sun's OS ARE accelerated. This is either just plain lazyness on their part, or a ploy to increase the popularity of their OS.
"Hey, buddy. You like that Swing Office Suite? Well, it runs 30% faster on a Sun workstation..."
Re:Java as a user interface
by
Blue+Lang
·
· Score: 2
There is no reason the VM cannot make calls to specific hardware, as we all know they're written for specific platforms.
1) Do it and post the code.
2) No, not all VMs are written for a single platform. Most people, when writing a unix VM, would probably consider adding hw accelleration too much overheard, especially given the fact that java compliance is such a moving target.
3) Sun's optimizing the swing widget compilation for sun boxes is not laziness - are they really supposed to also support non-sun gfx adaptors? That's a massive undertaking.
4) I agree with you, non-optimized gui elements are one of my favorite things to taunt our java monkies with.
-- blue
-- i browse at -1 because they're funnier than you are.
Re:Java as a user interface
by
deander2
·
· Score: 2
To clarify: By hardware accelerated, I did not mean the gfx card knows what a widget is. However, it does know what a rectangle is, what alpha-transparancy is, how to write one graphic over another, how to copy a rectangle from one location to another, etc. It can do manipulations and transformations like these MUCH faster than your CPU, just like it can draw triangles faster too.
Noone has asked Sun to support non-Sun gfx adapters. All I'm asking is that they support standard APIs. When you write an app, you write to the standard APIs, not to the gfx card itself.
Swing is built on AWT, and in Sun's JVM AWT components are drawn without using any of the (much faster) windowing APIs.
If you want a demonstration of the differences hardware accelerated 2D can make (we have had it so long people forget it's there), change your resolution to 640x480 and play around. Then uninstall your video drivers and play around. Pay particular attention to standard window drawing, pulling down menus, etc. See the difference?
IBM Native Threads implementation inefficient
by
Leghk
·
· Score: 5
Although IBM's 1.1.8 JDK was by far the fasted VM available for linux [aside from native compiling towerJ] it's native threads' implementation was not nearly as efficient as Blackdown's. IBM uses a mixed-mode JIT, which ends up ( in my experience) considerably faster then even Inprise's JIT plugged into Blackdown's VM for single thread loads. However, under heavy multi-thread loads, IBM's VM acctually underperforms blackdown's vm considerably. You can tell their threads implementation is a bit "funny" because when a system running the IBM JRE is under heavy load, the entire system becomes unusable, --even if the load average is only nearing 2. The mouse becomes extreemly jerky in X, console commands take 3-5 seconds to execute, all this with 5 active threads. Verses with blackdown's VM I've had 40 active running threads, and the rest of the applications run just as responsivly as you would expect linux to. I suspect IBM did a bit of cheating, and toyed iwth the priority threads were being issued, such that IBM VM threads end up being the highest priority to run. This gives them a bit of an edge when it comes to single threaded benchmarking; but once the IBM VM threads start competing against eachother.. it all falls to bits. I wonder if they'll fix that in 1.3.
The volano report does not include Sun or Blackdown's Native threads JVM. It includes their GREEN threads JVM. I've talked to the person who runs the volano benchmarks; and they don't include native threads on linux [IBM being the exception] because the linux kernel does not support >256 light weight processes.
They have several patches which they used for benchmarking the IBM VM to allow greater then 256 native threads on a linux kernel. Unfortunatly they don't do those patches with any other VM under linux. TowerJ, the highest performer on their benchmark, does not use native threads.
The volano report is not REALLY a good mark of how fast a JVM will perform. -Usually- you're not running 4000 concurrent threads idle threads. Usually you have a few worker threads, and a few idle ones.
It's also quite sad to see that the Microsoft VM whips Linux's JVM's up and down the street, and both sides [on that report]. TowerJ being the exception; but that's not exactly a JVM.
Just ran some benchmarks, looks like some solid progress on the IBM JVM under threadload. IBM's JVM is now runs just short of TowerJ's performance. If you're not familure with TowerJ, it's a commerical piece of software which given a set of java class files, turns them into C++ code. Then runs GCC over them, producing a native binary. TowerJ [specifically on Linux] is currently ranked in the top slot on the Volano Benchmark. TowerJ under linux even beats TowerJ under NT; apparently in the words of the TowerJ engineers, the linux libraries are just more efficient:)
You can view a JVM graph here of the various Linux JVMs under load. As you can see the old IBM JVM didn't fair very well under threadload, regardless that it generally ran faster for single threaded applications. Good work IBM!
You may find this article interesting. IBM's run some tests on the Linux scheduler using their 1.1.8 JVM, and proposed some patches to the kernel so that performance under heavy loads would raise.
-- Marcelo Vanzin
--
Marcelo Vanzin
Lightweight vs. Heavyweight components
by
Wesley+Felter
·
· Score: 3
This whole debate has been gone over again and again. If you want your components implemented in native code and hardware accelerated, use AWT. If you want really flexible components that look pixel-identical on every platform and have all kinds of cool features that your graphics card can't accelerate, use Swing.
And what's wrong with Sun making a fast VM for Solaris? There's nothing stopping you from joining the Blackdown project and doing the same for Linux.
The ability to move a Java program from one platform to the other without having to recompile is overrated. It's not that big a deal to recompile, especially if you know that you don't have to do any system-dependent #defines like you do in C.
I would think that the main reasons to use Java are:
Simplicity
Built-in threading
Garbage collection
A great set of standard libraries
Bounds checking on arrays (really, avoiding the C/C++ pointer overrun problems)
The ability to print a stack trace from an exception (oh how I miss that when I do C++!)
Reflection
I don't see how a compiled, system and arch dependant binary would eliminate any of those reasons.
Kudos to IBM for providing this environment (even if it expires after 90 days). Note: also thanks to the Blackdown team who have done an excellent job in less than excellent conditions to provide excellent tools that I rely on now.
A note on Java: This is actually a huge boon for Linux. Look at it this way...Linux provides an excellent (cheap and stable) platform on which to develop Java applications. I'm not talking about applets here...I'm talking about large / distributed software systems. I'm building one in a research setting right now using CORBA that's up to 40 KLOC.
I develop entirely on Linux using XEmacs, CVS, and make. For everyone who argues that there isn't a good Java development environment for Linux (article seen recently on ZDNet), that talk is for the birds. These are perfectly good tools that have been proven in the trenches writing code for the guts of the internet, UNIX, C/C++, and thousands of other packages / programs. If you want an environment that handles drag & drop JavaBeans, servlets, etc, go buy a fast box with 256 MB memory and JBuilder. The tool works just fine...just put the horsepower behind it. This isn't to say that XEmacs could be useful for the average Joe programmer (VB developers-come-Java programmers). It does take some tinkering, but there are good develoment environments out there. Anyway, what does a good environment provide you that you can't accomplish with a shell, some scripts, and syntax highlighting. Nothing as far as I've seen except bulk, sluggishness, and programmers who don't understand the fundamentals of development and rely on the tools to find their problems (a poor way to program).
Linux provides a great platform for this kind of development, though, and the gains realized are immense. I can run my object servers spread across the network and virtually guarantee that my clients can run on Mac, Solaris, Linux, and even Microsoft as long as the appropriate Java runtime is installed. Remember, this is an application not an applet! The Swing toolkit is slow and has a huge memory footprint, granted, but there are also some fabulous Swing tools out there (NoMagic MagicDraw UML comes to mind).
I'm not getting religious here; I use Perl, Tcl/Tk, and C/C++ when appropriate. All I'm saying is that Java has its place, and a great toolkit like this one from IBM goes a long way to advancing the Java development capabilities of software developers who won't pay for SPARCs or Windows and want a customizable, robust, and fast environment.
So, knock off the hatred of Java, find some good development tools, and use it for what it's good for (use Flash for providing animations in web browsers), as a full featured applications development language with thorough APIs. It's not perfect, but it has its place in a development toolkit.
Kudos to IBM. Keep up the good support.
Re:What about VAJ and Websphere
by
sohp
·
· Score: 2
Huh? Keep up! http://www-4.ibm.com/software/ad/vajava/ "VisualAge for Java runs on AIX, Linux, OS/2, OS/390, Windows 95 & Windows 98 and Windows NT."
Java = Language + RTL + VM / compiler
by
harmonica
·
· Score: 2
As some of the postings throw everything together, there is 1) Java the OOP language, there is 2) the huge runtime library of classes and 3) there is the virtual machine that interprets the byte code OR the compiler that creates a native executable from either bytecode or source code.
So, if speed is a problem, try compiling into a native executable. What's new (compared to C, as an example) is the fact that no platform-dependent problems will arise when programming, so you don't have to do a thousand ifdef checks to see how large an int variable is. If it wasn't for these nasty problems, C would also be a great platform-independent programming language (well, not great:-)).
The RTL is a huge plus IMHO - all basic stuff is already there and it works.
Re:Java = Language + RTL + VM / compiler
by
harmonica
·
· Score: 2
The problem can be overcome, and has been overcome uncountable times, using ISO C.
Of course these problems are avoidable, but practice shows that all errors that a language allows you to be done will be done by someone, even if every good book on software engineering tells you not to.
The example may have been a poor one, but it's something everybody probably has seen in some ugly code snippet.
On the portability issue, I'm not sure how difficult it is to create a new VM / compiler. I guess it depends on how much the new platform differs from the other ones. Is it easier to create a Unix XY port if you already have a VM for Unix YZ? I would say so, but I don't know exactly, maybe one of the Blackdown people can answer this (some of them are reading slashdot comments on Java IIRC).
Sun has defined three different Java editions, including a micro edition, to address the problem of embedded systems and handheld devices. The micro edition only includes a subset of the functionality of the standard or enterprise edition. A description can be found on Sun's website.
On the number of platforms for which there are compilers and virtual machines, there are many. Kaffe alone has more than 30 OS / processor combinations supported.
Also take a look at this list of compilers and virtual machines, there are VM's and compilers for all kinds of systems. But for the older and more exotic systems the porting of a VM / compiler may not be worth the effort. Maybe the Java part of the GNU compiler collection can do something for them -- I don't know much about the status of Java support there.
Very few good C++ programmers out there...
by
rjh
·
· Score: 4
First, your points are spot-on when it comes to C versus Java. When comparing C++ to Java, though, many of your issues go away.
Simplicity: a well-architected C++ solution, which intelligently uses the appropriate features of the language, is just as simple as Java. In fact, Java borrowed most of its simplicity from C++ in the first place.
Threading: Okay, this one is granted.
Garbage collection: Contrary to popular belief, Java's GC isn't exactly the best thing since sliced bread. There's a fairly large industry providing third-party garbage collection tools for Java. Can't remember any of them off the top of my head, but I do know that some of them are wealthy enough to afford full-page ads in Communications of the ACM.
Bjarne Stroustrup has also said that GC will likely be implemented in the next ANSI draft of C++. While that doesn't balance C++ and Java, it does mean that you're comparing no GC in C++ to a somewhat broken GC in Java. Neither one is an optimal solution.
Standard libraries: Are you at all familiar with the STL and free (liberty) C++ libraries? The advantage of Java isn't that it has every function under the sun; it's that the collection which ships with the JDK is very comprehensive. C++'s body of free (liberty) libraries is far superior, but you have to search for them.
I also have a slight objection to your use of the word "standard". There is no Java standard; therefore, there can be no standard library. C++ has been standardized; Java isn't.
Bounds checking on arrays: C++ includes this. It's included this for quite some time. It's not possible to bounds-check a C array, but it's trivial to bounds-check a C++ container (list, vector, etc.).
Printing stack traces from exceptions: Look around the free (liberty) C++ libraries. I'd be extremely surprised if you couldn't find one.
Reflection: C++ includes this. It's called RTTI (run-time type identification).
... I am not trying to denigrate Java or elevate C++. I've used both, and I have no clear favorite between the two. Java borrows very heavily from C++, and it constantly surprises me at just how many Javagrinders say "well, C++ doesn't have features foo and bar!" without realizing that Java borrowed foo and bar from C++.
That said, it is incredibly difficult to become a good C++ programmer. The language is straightforward, but has extremely complex nuances which require years of exposure to fully comprehend. Java is a much more straightforward language, but occasionally the lack of nuance makes it difficult to achieve subtle hackery.
Re:Very few good C++ programmers out there...
by
The+Wookie
·
· Score: 3
I used C++ for many years, although not as much since Java has come out, and since then the standard was finally ratified. Like you, I don't want to get into a Java has foo, C++ has bar kind of argument, I can just state what has made me prefer Java to C++.
Simplicity:While I would agree that on a large scale, a well-designed C++ system can be just as simple, sometimes simpler than a Java system. In the small, though, I find that I can create useful Java classes faster. I don't have to worry about destructors, assignment operators, etc. I know they have their use, I just prefer not having to deal with them. And just from a Me-Whining-About-Something-Insignificant standpoint, I hate the template syntax.
Standard Libraries:Okay, so there's no standard. But look at STL compared to the libraries that come with J2SE. With STL you've got containers, algorithms, strings.. very system-independent things. With Java I can write database code for almost any database and it will work on Linux, Windows, Solaris, etc. Swing is kinda big and slow, but at least I know I can count on it being there. C++ doesn't address areas like this. Again, for good reason. If I had to get that kind of stuff by a standards committee, I'd punt, too.
Garbage Collection:Sure you can do it in C++, but who does? And is it thread-safe? I know it's not the fastest thing in the world, and in some respects indicates a kind of laziness, but at least all the libraries use it. I don't have to worry about which ones do and which ones don't.
Bounds Checking:It's really not bounds checking so much as the whole pointer deal. No one likes to look for bugs caused by invalid pointers or references. It's not just running off the end of an array, it's things like returning a reference to a stack-allocated object. It's not a smart thing to do, but people do it anyway.
Reflection:You need to try Java's reflection. RTTI doesn't come close. You can ask a class what methods and fields it has, get and set field values on the fly, dynamically invoke methods.
Every so often I go back and try to work with C++ and I just find myself missing the Java features I have grown to love. But that's just me.. I love vi, too, having used it for 16 years.:-)
Re:Very few good C++ programmers out there...
by
SuperKendall
·
· Score: 2
Simplicity: a well-architected C++ solution, which intelligently uses the appropriate features of the language, is just as simple as Java. In fact, Java borrowed most of its simplicity from C++ in the first place.
I think the simplicity of Java comes from taking interesting parts of lots of languages - C++, Lisp, Modula 3, and others which together create a simpler system. Packages to cleanly seperate out different modules (really more similar to Modula 3 than C++ namespaces), The "everything's an object [almost]" mentality of Lisp (somewhat diluted by primitive types!) and so on. I'd say that based on a bunch of scheme and elisp programming as well as a lot of C and C++, that Java is closer in nature to Lisp!
Standard libraries: Are you at all familiar with the STL and free (liberty) C++ libraries? The advantage of Java isn't that it has every function under the sun; it's that the collection which ships with the JDK is very comprehensive. C++'s body of free (liberty) libraries is far superior, but you have to search for them.
I would argue that you really couldn't easily consider a library superior if it requires hunting for! A lot of what Java has going for it are very good standard libraries that are also widely known and used, thus there is a lot of free information on how to use them and a lot of examples abound.
There's not only the fine Collections package, but also JDBC for easy database connectivity, a pretty good file IO system, the built in networking support, image handling, compression handling, and many other things. You might be able to find a number of packages that fulfil those needs in C++, but unless you buy a solution like RogueWave it's often tough to find good support materials to help you use them properly.
I've used the STL, and I personally don't like that approach to the kinds of simple, everyday collections you need most often. Sometimes you come across cases where the complexity of the collection needed is much more than a simple set of collections can provide - but the Java collections provide just enough functionality to be useful for 90% of your collection needs and provide easy enough extensibility to account for many of the other cases. In fact one of the greatest boons to Java is that the most commonly used collection by everyone - a collection of characters, or a String - is pretty much a part of the language in Java. No matter how many String support classes you gather for C++ they still are more cumbersome to use than a String in Java.
Bounds checking on arrays: C++ includes this. It's included this for quite some time. It's not possible to bounds-check a C array, but it's trivial to bounds-check a C++ container (list, vector, etc.).
Yes, it's pretty easy to bounds check a collection of any sort but it's the normal C style array checking of Java that's really useful - no memory overruns to corrupt data, just a nice exception with a stack trace if you go wrong. There are packages like Great Circle that can offer runtime protection against these things for C++, but again that's another thing you have to hunt down.
Reflection: C++ includes this. It's called RTTI (run-time type identification).
Please feel free to correct me if I'm wrong as it's been some time since I've used RTTI, but I seem to remember RTTI being very limited compared to Java Reflection. I think RTTI is really closer to the "instanceof" operator in Java than the full Reflection functionality...
For instance, in Java I can get the type of an object, and create a new one - if I can't find a default constructor I could rummage through the constructors that are availiable and create a new instance based on some type I know about (like a String type that I knew could be used to create an object I'm interested in).
Then when an object was constructed, I could compare settable properties of one object vs. the other object and if the types matched use one object's get method and the other object's set method to copy properties with the same name (where compatible in type) from one object to the next.
I think in C++ you would be stymied by being unable to create an instance of an object unless it had a default constructor. I'm not even sure you can obtain a list of methods for a class and call them at will without knowing the type at compile time to cast into a callable object type.
I personally used to be a C++ proponent but now only use C++ for the occasional need to access some native resource or library. I've fully swung over to the support of Java because it has renderd me and the people around me to develop systems of great complexity with ease and stability that remained often elusive in C++_projects - I agree with you that it is truly hard to master C++, and make no claim myself to any mastery of the language (especially now that I've not really used it for so long!).
I disagree though that you cannot achive subtle hackery in Java - I think that between the language features like Reflection and the many packages availiable that you can actually achive things at a higher level as you are not so often bogged down in the mechanics of whatever trickery you are trying to attempt!
-- "There is more worth loving than we have strength to love." - Brian Jay Stanley
Re:Very few good C++ programmers out there...
by
Foogle
·
· Score: 2
Doesn't support exceptions? I think you've either misspoken or misunderstand. G++ itself supports the throwing of exceptions as a part of the language. The C++ standard library just doesn't *use* exceptions as a general rule, because it's a tradeoff or speed versus safety. You're left to do your own checking, but it certainly "supports" exceptions.
-----------
"You can't shake the Devil's hand and say you're only kidding."
Oh, that day is already here. JIT compiling VMs have been around for a while, and processor speeds are at least 4x if not 8x faster than they were when Java was introduced.
But remember Transmeta? Remember that their Crusoe chip, while currently targeted at the x86 market, was also demoed running Java byte code 'natively' (ie doing the code morph thing from Java bytecode to Crusoe internal instructions).
I like Java for apps because its cleaner and easier to debug than C++, and has a whopping great set of (cross platform!) APIs. And for many apps, the speed is already good enough. But I still use C for lower level stuff, and C or C++ if I need to tie in to an existing C library. (Why mess with JNI).
We did some speed comparisons between IBM's 1.1.8 JDK and the 1.2.2 JDK from Blackdown/Sun/Borland and found the 1.2.2 platform to be significantly faster. Now, our tests were centered around using JRun behind Apache, but using the Apache Servlet Killer program, the 1.2.2 JDK held up a lot longer under load than 1.1.8 did. (shrug) We haven't tried the 1.3 JDK yet as it's a flippin' HUGE download (~60 megs) but it'll be interesting to test it out in the same way.
-- James
Re:What about VAJ and Websphere
by
SockPuppet_
·
· Score: 2
VisualAge for Java Professional edition is available for Linux, but not the Enterprise edition. The Professional edition lacks some of IBMs enterprise tools and the ability to connect to a team respository server. That makes it a pain in the ass to use if you're not working alone.
mini-benchmarks: not as fast as 1.1.8
by
caucho
·
· Score: 3
I just did a quick servlet benchmark and it looks like the new JDK is close, but not quite as fast as the 1.1.8 JDK. But it crushes the Blackdown JDK.
The numbers are ops per second for a P-266 running RedHat 6.2 and Resin 1.1 as a standalone HTTP/servlet engine and using 4 clients.
File JSP Loop DB
IBM 1.1.8 907 640 37 317 IBM 1.3 878 615 46 315 JDK 1.2 393 383 6 147
Apache 720
The Apache 1.3.12 number is just for comparison. Scott Ferguson
This whole thread is built on a misconception. Modern Java VMs, such has Sun's HotSpot on Windows or IBM's 1.1.8, produce code that is as fast or faster then that produced by static compilers. Some things to understand: (1) Java code IS compiled. Its just compiled at run-time rather then build-time. The result is the same however-- machine code running on your machine. (2) JITs have a number of advantages over static compilers: (a) A static compiler must compile for a lowest common denominator platform (typicly Pentium). A JIT can determine the processor type at run-time and produce processor-tuned code. (b) A static compiler must "guess safe" in situations where code is ambiguous. A JIT can go ahead and take risky optimizations because it can un-optimize if the need arises. One place this occurs a lot is in in- lining. The static compiler can only safely in-line finals. The JIT can try to in-line anything and adjust by how the code actually gets used. (HotSpot calls this "agressive inlining" and you can read about it at the HotSpot section of java.sun.com) Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.) There are some actual experiemntal numbers and a chapter discussing this and other Java v. native code issues in "Java(tm) Platform performance: Strategies and tctics" coming out at JavaOne. (Its already up for pre-order at amazon...)
Modern Java VMs, such has Sun's HotSpot on Windows or IBM's 1.1.8, produce code that is as fast or faster then that produced by static compilers.
Some things to understand: (1) Java code IS compiled. Its just compiled at run-time rather then build-time. The result is the same however-- machine code running on your machine.
(2) JITs have a number of advantages over static compilers: (a) A static compiler must compile for a lowest common denominator platform (typicly Pentium). A JIT can determine the processor type at run-time and produce processor-tuned code.
(b) A static compiler must "guess safe" in situations where code is ambiguous. A JIT can go ahead and take risky optimizations because it can un-optimize if the need arises.
One place this occurs a lot is in in- lining. The static compiler can only safely in-line finals. The JIT can try to in-line anything and adjust by how the code actually gets used. (HotSpot calls this "agressive inlining" and you can read about it at the HotSpot section of java.sun.com)
Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.)
There are some actual experiemntal numbers and a chapter discussing this and other Java v. native code issues in "Java(tm) Platform performance: Strategies and tactics" coming out at JavaOne. (Its already up for pre-order at amazon...)
Re:How long before the flame wars start?
by
harmonica
·
· Score: 2
. "anywhere" is now defined as Windows and Solaris (note: Windows first!).
True, Sun only releases JDK's for Win32, Solaris and Linux. But there are tons of JDK's by other enterprises, e.g. for HP-UX, Digital's Unix, Irix etc., most of them 1.2. They get used but nobody makes a lot of noise about it.
As I said earlier, I like Java *as a language*. It would be nice if someone (*ghm* Sun?) released a Java-like language that actually compiles to native binaries (i.e. getting rid of this jvm junk). But Sun has a different agenda...
There are Java source/bytecode-to-native code compilers. You'll get the speed there. On JVM, it has other advantages as pointed out by others (dynamically creating machine code that is suitable for the CPU found at startup, the sandbox principle etc.).
So, if you're that much into CS, try doing some background research on what exists and why it exists. You're right about the Java/university thing, though.
Bold assertion there... (Re:Misconceptions)
by
Troy+Baer
·
· Score: 2
(a) A static compiler must compile for a lowest common denominator platform (typicly Pentium). A JIT can determine the processor type at run-time and produce processor-tuned code.
That depends largely on your environment and how widely you plan to disseminate binaries. Where I work, we regularly compile codes where we need good performance with the highest possible optimization targeted to the specific CPU type on the machine, but we're hardly a typical shop.
Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.)
That's a pretty bold assertion. What kind of "raw computation" applications were these: number crunching, DB access, GUI desktop apps, what? Also, what architecture or architectures were these comparisons done on? If you're talking number crunching, will it outperform a good optimizing Fortran 77 or Fortran 90 compiler? (Note: Neither g77 nor the Sun Fortran compilers constitute a "good optimizing Fortran compiler". I'm talking about something like the Portland Group's Fortran compilers for IA32 or the SGI MIPSpro Fortran compilers for MIPS. Compaq's Visual Fortran may or may not qualify; I've never used it.)
The reason I ask is, I work in high performance computing, and I deal with trying to optimize codes all the time. I find it difficult to believe that JIT compiling is the panacea you describe it as, but if you've got numbers to back it up I'd love to see 'em, if for no other reason than to dissuade our physicist users from trying to program in C++...
--Troy
-- "My life's work has been to prompt others... and be
forgotten." --Cyrano de Bergerac
Re:Where are the java applications?
by
catseye_95051
·
· Score: 2
Lots, Im sure if you did a net search you'ld find them.
The "Who wants to be a millionare" computer game I am told is a pure Java application. This is a shipping full featured shrink-wrapped product-- not an applet.
Similarly I just came across a pure Java accounting program today. (Secure-somebody. I have the information at work.)
Ofcourse we have things like WebLogics EJB applciation serevr which is written in Java. In short there are a ton of em.
You just need to look for em. If you really want to fnd them, I'd start by lookign at the archives of the Java Lobby (www.javalobby.com)
So Bruce was trolling. But I get so sick of this crap every time there is a Java story on Slashdot...
I'd like someone to show me an example of real software(i.e word processor, database, game, compiler, OS) that is written in Java.
Yeah, except most lines of code aren't written for apps like that. Try buisiness systems in major companies. Have a look at IBM Websphere, BEA Weblogic or Oracle8i or any of several dozen other similar products. You know - stuff used by real businesses.
Just becuase Java isn't used by 20 dorks a day to write a CD player front end and put it on freshmeat doesn't mean it isn't used.
--
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
Re:Non-x86 Linux users in the dust (of course!)
by
JohnZed
·
· Score: 3
IBM wants to sell more hardware. IBM doesn't sell Sparc or Alpha hardware, so those would clearly be silly ports (they'd just help Sun and Compaq, who are direct competitors). As for PowerPC, maybe IBM would consider a port if they saw a substantial number of serious, enterprise customers buying PPC hardware to run Linux. But, frankly, very few people are doing that right now. It is NOT just an issue of "grab a PPC and compile", because much of a good JVM's performance comes from a good JIT. JITs are, of course, highly architecture-specific. And, as for their failure to distribute source, remember that they license code from Sun (it's not a true "clean room" JVM). Thus, at best, they could consider a SCSL license. Remember how popular the SCSL was? But then Sun (public enemy #1 for IBM right now) would get the benefit of all their JVM enhancements (and IBM has PLENTY). Doesn't sound like a compelling business case. --JRZ
An example of one method for calling arb. proc.
by
SuperKendall
·
· Score: 2
I'll admit that is one of the more unpleasant cases, but I've made an attempt to outline a strategy I'd use - basically to get around your issue with multiple return values from a method call I'd either return a Map or pass in a Map ( or Object[] ) that I could fill with values. This could also be a list but I tend to like the named entries in a Map.
Below, I have some code and some pseudo code in comments outlining one way that you could do something like what you want to do - it relies on database metadata information to pull out parameter types and help map what you are sending into it.
It also takes a connection to build this object, I've found in general it's a pretty good idea to pass connections to JDBC helper objects of this sort as you can easily share one connection across multiple helper objects, you get to manage the commits, and you can close when it's the right time. You can also build up multiple helper objects connected to different data sources which is nice.
int myResult2 = ((Integer)resultMap.get( "Param3Result" )).intValue();
Admittedly, it does not look a lot prettier than the code you already had - it does let you do multiple calls through one wrapper object and I think the call itself is pretty clean [you could even go so far as to add callStatement(name, arg1), callStatement(name, arg1, arg2)... to ProcedureCaller though I don't like the look of it for some reason!] and it lets you get to the results pretty easily.
I think if I were writing this for myself I'd pass in a ordered Map instead of an Object[] so I could provide names for in and out paramaters to get them out of the result map in a more meaningful way.
You could also provide a bit more useful type of Map wrapper that helped in obtaining primitive values by automatically unwrapping primitives from the objects returned in the map. (like an [int getInt()] call in the map).
The code below at the end does not do the type translation bit much at the end - I was assuing calls to getObject() that would stuff the results back into the result map with essentially the same type as the database. One could provide a custom map as well, which might be nice to get back Timestamps instead of Date objects if you want to keep the whole value of your Date object!
I also assumed the use of JDBC 2.0, though I think you could do most of this with just a bit more work in a JDBC 1.1 driver...
Here's the code for the helper object (terribly unoptimized!! Assume a GPL license for the whole post)
public class ProcedureCaller {
public ProcedureCaller( Connection conn ) { // store connection }
public Map callProcedure( String procname, Object[] args ) { // ------- Build call string StringBuffer call = "{" + procname + "( "; // loop through args adding "?," for each arg listed
call.append(" }");
// ------- Register parameters
// Get out list of parameters for this call, this info could be cached String catalog = conn.getCatalog(); ResultSet dbFunction = conn.getMetaData().getProcedureColumns( catalog, ""// Schema procname, ""// Whatever "all" pattern is );
// Build the call to call CallableStatement cs = conn.prepareCall( call );
// Go through the meta info about each function parameter to set parameter // types and values short columnOutness; short columnDataType; int i = 1; while ( dbFunction.next() ) { // gets In, out, in/out, or returnVal columnOutness = dbFunction.getShort( "COLUMN_TYPE" ); columnDataType = dbFunction.getShort( "DATA_TYPE" );
// Based on the parameter flow, do what we need to. Probably remember // return type for out params and return value. switch ( columnOutness ) { case DatabaseMetaData.procedureColumnIn: cs.setObject( i++, params[i] ); break; case DatabaseMetaData.procedureColumnInOut: cs.registerOutParamter( i, columnDataType ); cs.setObject( i++, params[i] ); // add this parameter index to list of OUT params
case DatabaseMetaData.procedureColumnOut: cs.registerOutParamter( i++, columnDataType ); // add this parameter index to list of OUT params
} }
// now that all the parameters are set, call the procedure ResultSet procResults = cs.executeUpdate();
// go through result set adding any results to the map
// Go through each OUT paramater stored in our list of OUT paramindexes { // Add parameter to result map, perhaps by name "Param[i]Result"
// If you want to flow back through objects passed in the object array, //just get them out by index and either set values (if mutable object) or //create new object and put that into the passed Object[]. }
return// map full of results }
}
-- "There is more worth loving than we have strength to love." - Brian Jay Stanley
For anybody listening to this BS, I suggest you actually do some experiments yourself. Java and C++ are close enough that it's quite easy to compile virtually identical code in both. There are too many lies told by both sides and ymmv depending on what you're doing.
I typically find Java runs at 1/5th the speed of C++ (using latest compilers). My own results correlate closely with http://sprout.stanford.edu/uli/java_cpp.html
Listening to what Sun says about Java v C is like listening to what Microsoft says about W2k v Linux.
Your arguments are fine theoretically, they're just false in practise. HotSpot is not nearly that good yet.
-- http://rareformnewmedia.com/
People who like vi like java
by
twdorris
·
· Score: 4
Here's something I thought I'd throw out there. First, a bit of a disclaimer. I'm no MS VB weenie that likes Java because it's simple to use. I prefer coding in assembler and I do so quite often when appropriate (I reprogram the ECU in my car, for example). However, I also happen to really enjoy coding in Java. It's the most "pleasant" coding environment I've ever used in the past 15 years; period.
I'm a big fan of the "learn one thing well and become an expert on it" approach to life. I focus on something that I know is going to be powerful and/or popular in the future and I learn it well. Java is that thing when it comes to coding.
I learned about vi while in college (about 5 years ago). I thought it was weird and awkward to use, but because it was everywhere and because I could focus on honing my skills with that one editor and be proficient on so many different platforms with it all at once, I learned it. Now I know that editor very well and I happily co-develop under Linux, Solaris, HP, AIX, and even windows with it.
Java is the same type of thing. I learned Java, I learned it well, and now I code peacefully on all those same platforms (sans HP and AIX...I just haven't used those in a while). I've written a datalogger in Java using Swing for my car that works in conjunction with the aforementioned ECU reprogramming effort to provide me with real time data gathering while I'm powering around at the track. What's great is that I did ALL my development under Linux. When it was all done, I slapped the exact same jar file under Windows NT for a friend of mine with a similar car (didn't even have to recompile it!) and it ran flawlessly. He prefers Windows, I prefer Linux.
Why on earth would I have ever considered writing that application under anything but Java? If I had used MFC, I would not only still be pulling my hair out trying to figure out what the hell was wrong with it, but I also would be forced to use Windows when I was done. The same is true if I had coded it using Motif or GNOME/Gtk or most any other X-based environment. I could not have shared that application with friends that happen to like Windows.
That's one of the many benefits of Java; and it's one of the benefits of vi. Learn something that's powerful and flexible once, learn it really well, and you end up reaping benefits from it on a variety of different platforms. Java is quite powerful and I'm happy as hell to see IBM doing all the great work they're doing with Java under Linux!
The ability to move a Java program from one platform to the other without having to recompile is overrated I humbly suggest that the reason you think this is that you have not seen the future of computers and networks. In the future, bytecode will be flying around from computer to computer - and it will have to run flawlessly wherever it ends up. You could send around source code, I suppose, but you'd still need a rock-solid standard to ensure that source code would compile and run everywhere.
-- First, make it work, then make it right, then make it fast, then, make it bloated!
Re:How long before the flame wars start?
by
JohnnyCannuk
·
· Score: 2
Wow, somebody has a pickle up their ass about being in CS! (how snobbish).
I "learned" java in the real world by using it almost every day for applications. Your right - Java is not C nor is it C++. But have you ever heard of "the right tool for the right job"?
C/C++ is great for lower level code, device drivers or embedded systems. Java is excellent on the server as a replacement for CGI (ever heard of servlets/JSP? that's where all the action is these days - and its faster and less resource intensive than CGI). Any other software depends on what your creating and for whom.
Your right that Java is slow RIGHT NOW. But the same was said of C++ 10 years ago. I don't hear too many complaints about the speed of C++. Would I write a Word Processor in Java? Hell no, not until the JVM/JIT stuff gets way faster (although 1.3 is very quick, even with Swing). In C? Sure if I had a team of programmers and a couple of years...C++ would probably be a better choice.
Have you actually tried any 1.3 JDK implementations? I have and I find them way faster than anything previously created, almost as fast as C++ (even in GUI apps). Do you realize that written properly (eg NOT like a C/C++ program), with the proper patterns and optimizations, Java can be quite peppy?
Aparently not.
Before you slag a language or platform, try getting more knowledge than " 2 tutorials in the beginning of the semester that covered Java syntax and constructs" from an old CS prof would would rather write in Assembler or Fortran anyway. Follow your own advice and become informed by true experts in the field.
Does java have its problems? Sure..it nees better JVMs/JIT for better speed and STANDARDIZATION!(are you listening SUN?). That doesn't mean its not a viable development platform for the real world...and its getting better all the time.
BTW. In Java, multiple inheritance is done with little things known as interfaces...but I digress.
-- Never by hatred has hatred been appeased, only by kindness - the Buddha
Re:Client side java isn't the only Java
by
JohnnyCannuk
·
· Score: 2
Properly designed JSP/ASP/CFM/PHP should not have program logic in the presentation. But this is a problem of the coder and designer not of the technology. The JSP/ASP/CFM/PHP hold the presentation logic and compoments like servlets/Beans/EJBs/COM components/CORBA Orbs etc do all the aplication specific work. I've done this with both JSP and ASP (I like JSP better). Down on the farm, we call this MVC or even n-tier achetecture. Perhaps you've heard of it?
BTW, JSP performacne hits you speak of only happen on the first instance. All subsequent requests go to the already compiled servlet. I believe in some application servers (IBM WebSphere for instance) you can configure the JSP to be compiled on start up, so the user will neer see the performance hit, even if they are the first to hit the page.
-- Never by hatred has hatred been appeased, only by kindness - the Buddha
I wasn't trying to flame anybody, I just wanted to hear about some examples. I have nothing against Java. Honestly.
I've used Javascript, but my fear of slowness has kept me away from using Java for anything serious. However, I admire Java for its simplicity. I have Eckel's book "Thinking in Java" and the thing that attracts me most to it is his statement that Java would enable people to be "software craftsman" rather than operating system hacks. The language itself seems to have gotten rid of a lot of things that make C++ painful to program in.
So actually, I am interested in trying Java seriously. I just wanted some good examples of what it can do.
--
No, Thursday's out. How about never - is never good for you?
> Your premise is compeltely off. To restate the above: "Java shouls run code tuned for C++ as fast as C++."
You completely mis-respresent what I say, then refute it. What I'm saying is people should not believe your statements wrt performance because they are false , do your own testing.
> In general java today is MUCH better at in-lining then ANY C++ compiler
So why is it only 1/5 the speed ?
> It is at this point I believe an undisputed fact that a Java coder can write correct code faster then a C++ coder.
Totally disagree. I have been coding Java for 5 years and C++ for 9, I have written a commercial application consisting of 30,000 lines of Java. I first learned Java when 0.9 was released. I'm not some fucking novice.
Several people who's opinion I respect insist that they can develop stuff faster with Java than with C++. If they really know C++ I just don't understand this, unless they are comparing old (pre-STL) C++ with modern (post-collections)java. The other possibility is that they have been using MFC, a piece of code so vile, that I can barely speak it's name.
I can see that if you're working on a project where (2 or more apply): threads are important; has to work on multiple platforms; requires functionality that JDK library classes cover well; is deployed over the internet; speed is not an issue; memory useage is not an issue; very precise control is not important; some team members are inexperienced;
then Java may well be the best choice.
However for implementing arbitrary fresh functionality I can develop far faster in C++ than java. For instance a fragment of a C++ program that reads in a file and gets a list of the starting positions for every word in the file:
Writing the equivalent in Java would take 20+ lines.
Now, I admit this is a contrived example, but do it the other way round - give me a nice piece of algorithmic code in Java and I believe the equivalent C++ will almost always be considerably smaller, and thus easier to grasp. Java is good the beginners, there are fewer pitfalls, but as a language it's just almost entirely a subset of C++.
Slashdot Mirror
Good job, IBM. It's wonderful that support is so forthcoming. Though naturally, when someone says ``available for Linux,'' they really mean ``available for Intel Linux.''
Users of all other Alpha Linux are screwed. PowerPC Linux. UltraSPARC Linux.
Oh well, that's the real world, isn't it? It'd be nice if there at least was some source code to play with on other architectures. But that, naturally, isn't forthcoming.
blackdown's 1.2 uses --native threads. that cant be more than three or four months old.
GNU GCC currently ships with a pretty decent Java compiler, that can be used with libgcj in order to write native apps. I have no idea how complete libgcj currently is.
you're thinking of java 2 platform. java 1.2 was java 2 platform. so this 1.3.0 ibm release is also java 2 platform.
jdk 1.2 *IS* java 2 silly.
JDK 1.2 was re-named Java Platform 2 as part of the re-arrangement of the Enterprise, Standard and Micro editions. See SUN's Java site for more information on this, and the differences between the versions.
IBM are definitely at the head of the queue for this one !
I'm looking forward to being able to use some critical Java Platform 2 features, and remember this is the enabling technology for Enterprise Java Beans...
As a programmer, one thing Java is lacking is hardware acceleration of windowing widgets.
In any OS worth mentioning standard windowing calls (such as pulling down a menu or pushing a button) make specific calls to the video hardware. Sun's JVM, however, does not accelerate swing components, relying instead on your CPU to draw them.
There is no reason the VM cannot make calls to specific hardware, as we all know they're written for specific platforms. In fact, I am told that the VMs for Sun's OS ARE accelerated. This is either just plain lazyness on their part, or a ploy to increase the popularity of their OS.
"Hey, buddy. You like that Swing Office Suite? Well, it runs 30% faster on a Sun workstation..."
Does anyone else see this?
http://kered.org
Although IBM's 1.1.8 JDK was by far the fasted VM available for linux [aside from native compiling towerJ] it's native threads' implementation was not nearly as efficient as Blackdown's. IBM uses a mixed-mode JIT, which ends up ( in my experience) considerably faster then even Inprise's JIT plugged into Blackdown's VM for single thread loads. However, under heavy multi-thread loads, IBM's VM acctually underperforms blackdown's vm considerably. You can tell their threads implementation is a bit "funny" because when a system running the IBM JRE is under heavy load, the entire system becomes unusable, --even if the load average is only nearing 2. The mouse becomes extreemly jerky in X, console commands take 3-5 seconds to execute, all this with 5 active threads. Verses with blackdown's VM I've had 40 active running threads, and the rest of the applications run just as responsivly as you would expect linux to. I suspect IBM did a bit of cheating, and toyed iwth the priority threads were being issued, such that IBM VM threads end up being the highest priority to run. This gives them a bit of an edge when it comes to single threaded benchmarking; but once the IBM VM threads start competing against eachother.. it all falls to bits. I wonder if they'll fix that in 1.3.
This whole debate has been gone over again and again. If you want your components implemented in native code and hardware accelerated, use AWT. If you want really flexible components that look pixel-identical on every platform and have all kinds of cool features that your graphics card can't accelerate, use Swing.
And what's wrong with Sun making a fast VM for Solaris? There's nothing stopping you from joining the Blackdown project and doing the same for Linux.
I would think that the main reasons to use Java are:
Simplicity
Built-in threading
Garbage collection
A great set of standard libraries
Bounds checking on arrays (really, avoiding the C/C++ pointer overrun problems)
The ability to print a stack trace from an exception (oh how I miss that when I do C++!)
Reflection
I don't see how a compiled, system and arch dependant binary would eliminate any of those reasons.
Kudos to IBM for providing this environment (even if it expires after 90 days). Note: also thanks to the Blackdown team who have done an excellent job in less than excellent conditions to provide excellent tools that I rely on now.
A note on Java:
This is actually a huge boon for Linux. Look at it this way...Linux provides an excellent (cheap and stable) platform on which to develop Java applications. I'm not talking about applets here...I'm talking about large / distributed software systems. I'm building one in a research setting right now using CORBA that's up to 40 KLOC.
I develop entirely on Linux using XEmacs, CVS, and make. For everyone who argues that there isn't a good Java development environment for Linux (article seen recently on ZDNet), that talk is for the birds. These are perfectly good tools that have been proven in the trenches writing code for the guts of the internet, UNIX, C/C++, and thousands of other packages / programs. If you want an environment that handles drag & drop JavaBeans, servlets, etc, go buy a fast box with 256 MB memory and JBuilder. The tool works just fine...just put the horsepower behind it. This isn't to say that XEmacs could be useful for the average Joe programmer (VB developers-come-Java programmers). It does take some tinkering, but there are good develoment environments out there. Anyway, what does a good environment provide you that you can't accomplish with a shell, some scripts, and syntax highlighting. Nothing as far as I've seen except bulk, sluggishness, and programmers who don't understand the fundamentals of development and rely on the tools to find their problems (a poor way to program).
Linux provides a great platform for this kind of development, though, and the gains realized are immense. I can run my object servers spread across the network and virtually guarantee that my clients can run on Mac, Solaris, Linux, and even Microsoft as long as the appropriate Java runtime is installed. Remember, this is an application not an applet! The Swing toolkit is slow and has a huge memory footprint, granted, but there are also some fabulous Swing tools out there (NoMagic MagicDraw UML comes to mind).
I'm not getting religious here; I use Perl, Tcl/Tk, and C/C++ when appropriate. All I'm saying is that Java has its place, and a great toolkit like this one from IBM goes a long way to advancing the Java development capabilities of software developers who won't pay for SPARCs or Windows and want a customizable, robust, and fast environment.
So, knock off the hatred of Java, find some good development tools, and use it for what it's good for (use Flash for providing animations in web browsers), as a full featured applications development language with thorough APIs. It's not perfect, but it has its place in a development toolkit.
Kudos to IBM. Keep up the good support.
Huh? Keep up!
v /linux_faq.html
http://www-4.ibm.com/software/ad/vajava/
"VisualAge for Java runs on AIX, Linux, OS/2, OS/390, Windows 95 & Windows 98 and Windows NT."
http://www-4.ibm.com/software/webservers/appser
As some of the postings throw everything together, there is 1) Java the OOP language, there is 2) the huge runtime library of classes and 3) there is the virtual machine that interprets the byte code OR the compiler that creates a native executable from either bytecode or source code.
:-)).
So, if speed is a problem, try compiling into a native executable. What's new (compared to C, as an example) is the fact that no platform-dependent problems will arise when programming, so you don't have to do a thousand ifdef checks to see how large an int variable is. If it wasn't for these nasty problems, C would also be a great platform-independent programming language (well, not great
The RTL is a huge plus IMHO - all basic stuff is already there and it works.
First, your points are spot-on when it comes to C versus Java. When comparing C++ to Java, though, many of your issues go away.
Simplicity: a well-architected C++ solution, which intelligently uses the appropriate features of the language, is just as simple as Java. In fact, Java borrowed most of its simplicity from C++ in the first place.
Threading: Okay, this one is granted.
Garbage collection: Contrary to popular belief, Java's GC isn't exactly the best thing since sliced bread. There's a fairly large industry providing third-party garbage collection tools for Java. Can't remember any of them off the top of my head, but I do know that some of them are wealthy enough to afford full-page ads in Communications of the ACM.
Bjarne Stroustrup has also said that GC will likely be implemented in the next ANSI draft of C++. While that doesn't balance C++ and Java, it does mean that you're comparing no GC in C++ to a somewhat broken GC in Java. Neither one is an optimal solution.
Standard libraries: Are you at all familiar with the STL and free (liberty) C++ libraries? The advantage of Java isn't that it has every function under the sun; it's that the collection which ships with the JDK is very comprehensive. C++'s body of free (liberty) libraries is far superior, but you have to search for them.
I also have a slight objection to your use of the word "standard". There is no Java standard; therefore, there can be no standard library. C++ has been standardized; Java isn't.
Bounds checking on arrays: C++ includes this. It's included this for quite some time. It's not possible to bounds-check a C array, but it's trivial to bounds-check a C++ container (list, vector, etc.).
Printing stack traces from exceptions: Look around the free (liberty) C++ libraries. I'd be extremely surprised if you couldn't find one.
Reflection: C++ includes this. It's called RTTI (run-time type identification).
... I am not trying to denigrate Java or elevate C++. I've used both, and I have no clear favorite between the two. Java borrows very heavily from C++, and it constantly surprises me at just how many Javagrinders say "well, C++ doesn't have features foo and bar!" without realizing that Java borrowed foo and bar from C++.
That said, it is incredibly difficult to become a good C++ programmer. The language is straightforward, but has extremely complex nuances which require years of exposure to fully comprehend. Java is a much more straightforward language, but occasionally the lack of nuance makes it difficult to achieve subtle hackery.
Oh, that day is already here. JIT compiling VMs have been around for a while, and processor speeds are at least 4x if not 8x faster than they were when Java was introduced.
But remember Transmeta? Remember that their Crusoe chip, while currently targeted at the x86 market, was also demoed running Java byte code 'natively' (ie doing the code morph thing from Java bytecode to Crusoe internal instructions).
I like Java for apps because its cleaner and easier to debug than C++, and has a whopping great set of (cross platform!) APIs. And for many apps, the speed is already good enough. But I still use C for lower level stuff, and C or C++ if I need to tie in to an existing C library. (Why mess with JNI).
-- Alastair
We did some speed comparisons between IBM's 1.1.8 JDK and the 1.2.2 JDK from Blackdown/Sun/Borland and found the 1.2.2 platform to be significantly faster. Now, our tests were centered around using JRun behind Apache, but using the Apache Servlet Killer program, the 1.2.2 JDK held up a lot longer under load than 1.1.8 did. (shrug) We haven't tried the 1.3 JDK yet as it's a flippin' HUGE download (~60 megs) but it'll be interesting to test it out in the same way.
James
VisualAge for Java Professional edition is available for Linux, but not the Enterprise edition. The Professional edition lacks some of IBMs enterprise tools and the ability to connect to a team respository server. That makes it a pain in the ass to use if you're not working alone.
The numbers are ops per second for a P-266 running RedHat 6.2 and Resin 1.1 as a standalone HTTP/servlet engine and using 4 clients.
The Apache 1.3.12 number is just for comparison.
Scott Ferguson
Scott Ferguson
Caucho Technology
This whole thread is built on a misconception. Modern Java VMs, such has Sun's HotSpot on Windows or IBM's 1.1.8, produce code that is as fast or faster then that produced by static compilers. Some things to understand: (1) Java code IS compiled. Its just compiled at run-time rather then build-time. The result is the same however-- machine code running on your machine. (2) JITs have a number of advantages over static compilers: (a) A static compiler must compile for a lowest common denominator platform (typicly Pentium). A JIT can determine the processor type at run-time and produce processor-tuned code. (b) A static compiler must "guess safe" in situations where code is ambiguous. A JIT can go ahead and take risky optimizations because it can un-optimize if the need arises. One place this occurs a lot is in in- lining. The static compiler can only safely in-line finals. The JIT can try to in-line anything and adjust by how the code actually gets used. (HotSpot calls this "agressive inlining" and you can read about it at the HotSpot section of java.sun.com) Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.) There are some actual experiemntal numbers and a chapter discussing this and other Java v. native code issues in "Java(tm) Platform performance: Strategies and tctics" coming out at JavaOne. (Its already up for pre-order at amazon...)
This whole thread is built on a misconception.
Modern Java VMs, such has Sun's HotSpot on Windows or IBM's 1.1.8, produce code that is as fast or faster then that produced by static compilers.
Some things to understand:
(1) Java code IS compiled. Its just compiled at run-time rather then build-time. The result is the same however-- machine code running on your machine.
(2) JITs have a number of advantages over static compilers:
(a) A static compiler must compile for a lowest
common denominator platform (typicly
Pentium). A JIT can determine the
processor type at run-time and produce
processor-tuned code.
(b) A static compiler must "guess safe" in
situations where code is ambiguous. A
JIT can go ahead and take risky
optimizations because it can un-optimize
if the need arises.
One place this occurs a lot is in in-
lining. The static compiler can only
safely in-line finals. The JIT can
try to in-line anything and adjust by
how the code actually gets used.
(HotSpot calls this
"agressive inlining" and you can read about
it at the HotSpot section of java.sun.com)
Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.)
There are some actual experiemntal numbers and a chapter discussing this and other Java v. native code issues in "Java(tm) Platform performance: Strategies and tactics" coming out at JavaOne. (Its already up for pre-order at amazon...)
. "anywhere" is now defined as Windows and Solaris (note: Windows first!).
True, Sun only releases JDK's for Win32, Solaris and Linux. But there are tons of JDK's by other enterprises, e.g. for HP-UX, Digital's Unix, Irix etc., most of them 1.2. They get used but nobody makes a lot of noise about it.
As I said earlier, I like Java *as a language*. It would be nice if someone (*ghm* Sun?) released a Java-like language that actually compiles to native binaries (i.e. getting rid of this jvm junk). But Sun has a different agenda...
There are Java source/bytecode-to-native code compilers. You'll get the speed there. On JVM, it has other advantages as pointed out by others (dynamically creating machine code that is suitable for the CPU found at startup, the sandbox principle etc.).
So, if you're that much into CS, try doing some background research on what exists and why it exists. You're right about the Java/university thing, though.
(a) A static compiler must compile for a lowest common denominator platform (typicly Pentium). A JIT can determine the processor type at run-time and produce processor-tuned code.
That depends largely on your environment and how widely you plan to disseminate binaries. Where I work, we regularly compile codes where we need good performance with the highest possible optimization targeted to the specific CPU type on the machine, but we're hardly a typical shop.
Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.)
That's a pretty bold assertion. What kind of "raw computation" applications were these: number crunching, DB access, GUI desktop apps, what? Also, what architecture or architectures were these comparisons done on? If you're talking number crunching, will it outperform a good optimizing Fortran 77 or Fortran 90 compiler? (Note: Neither g77 nor the Sun Fortran compilers constitute a "good optimizing Fortran compiler". I'm talking about something like the Portland Group's Fortran compilers for IA32 or the SGI MIPSpro Fortran compilers for MIPS. Compaq's Visual Fortran may or may not qualify; I've never used it.)
The reason I ask is, I work in high performance computing, and I deal with trying to optimize codes all the time. I find it difficult to believe that JIT compiling is the panacea you describe it as, but if you've got numbers to back it up I'd love to see 'em, if for no other reason than to dissuade our physicist users from trying to program in C++...
"My life's work has been to prompt others... and be forgotten." --Cyrano de Bergerac
Lots, Im sure if you did a net search you'ld find them.
The "Who wants to be a millionare" computer game I am told is a pure Java application. This is a shipping full featured shrink-wrapped product-- not an applet.
Similarly I just came across a pure Java accounting program today. (Secure-somebody. I have the information at work.)
Ofcourse we have things like WebLogics EJB applciation serevr which is written in Java. In short there are a ton of em.
You just need to look for em. If you really want to fnd them, I'd start by lookign at the archives of the Java Lobby (www.javalobby.com)
So Bruce was trolling. But I get so sick of this crap every time there is a Java story on Slashdot...
I'd like someone to show me an example of real software(i.e word processor, database, game, compiler, OS) that is written in Java.
Yeah, except most lines of code aren't written for apps like that. Try buisiness systems in major companies. Have a look at IBM Websphere, BEA Weblogic or Oracle8i or any of several dozen other similar products. You know - stuff used by real businesses.
Just becuase Java isn't used by 20 dorks a day to write a CD player front end and put it on freshmeat doesn't mean it isn't used.
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
IBM wants to sell more hardware. IBM doesn't sell Sparc or Alpha hardware, so those would clearly be silly ports (they'd just help Sun and Compaq, who are direct competitors).
As for PowerPC, maybe IBM would consider a port if they saw a substantial number of serious, enterprise customers buying PPC hardware to run Linux. But, frankly, very few people are doing that right now. It is NOT just an issue of "grab a PPC and compile", because much of a good JVM's performance comes from a good JIT. JITs are, of course, highly architecture-specific.
And, as for their failure to distribute source, remember that they license code from Sun (it's not a true "clean room" JVM). Thus, at best, they could consider a SCSL license. Remember how popular the SCSL was? But then Sun (public enemy #1 for IBM right now) would get the benefit of all their JVM enhancements (and IBM has PLENTY). Doesn't sound like a compelling business case.
--JRZ
I'll admit that is one of the more unpleasant cases, but I've made an attempt to outline a strategy I'd use - basically to get around your issue with multiple return values from a method call I'd either return a Map or pass in a Map ( or Object[] ) that I could fill with values. This could also be a list but I tend to like the named entries in a Map.
// store connection
// ------- Build call string
// loop through args adding "? ," for each arg listed
// ------- Register parameters
// Get out list of parameters for this call, this info could be cached // Schema // Whatever "all" pattern is
// Build the call to call
// Go through the meta info about each function parameter to set parameter
// types and values
// gets In, out, in/out, or returnVal
// Based on the parameter flow, do what we need to. Probably remember
// return type for out params and return value.
// add this parameter index to list of OUT params
// add this parameter index to list of OUT params
// now that all the parameters are set, call the procedure
// go through result set adding any results to the map
// Go through each OUT paramater stored in our list of OUT paramindexes
// Add parameter to result map, perhaps by name "Param[i]Result"
// If you want to flow back through objects passed in the object array,
//just get them out by index and either set values (if mutable object) or
//create new object and put that into the passed Object[].
// map full of results
Below, I have some code and some pseudo code in comments outlining one way that you could do something like what you want to do - it relies on database metadata information to pull out parameter types and help map what you are sending into it.
It also takes a connection to build this object, I've found in general it's a pretty good idea to pass connections to JDBC helper objects of this sort as you can easily share one connection across multiple helper objects, you get to manage the commits, and you can close when it's the right time. You can also build up multiple helper objects connected to different data sources which is nice.
Here's an example use of the helper class:
Connection conn = DriverManager.getConnection(...);
ProcedureCaller caller = new ProcedureCaller( conn );
Map resultMap = caller.callProcedure( "myProc", new Object[]{ myArg } );
String myResult = (String)resultMap.get( "Param2Result" );
int myResult2 = ((Integer)resultMap.get( "Param3Result" )).intValue();
Admittedly, it does not look a lot prettier than the code you already had - it does let you do multiple calls through one wrapper object and I think the call itself is pretty clean [you could even go so far as to add callStatement(name, arg1), callStatement(name, arg1, arg2)... to ProcedureCaller though I don't like the look of it for some reason!] and it lets you get to the results pretty easily.
I think if I were writing this for myself I'd pass in a ordered Map instead of an Object[] so I could provide names for in and out paramaters to get them out of the result map in a more meaningful way.
You could also provide a bit more useful type of Map wrapper that helped in obtaining primitive values by automatically unwrapping primitives from the objects returned in the map. (like an [int getInt()] call in the map).
The code below at the end does not do the type translation bit much at the end - I was assuing calls to getObject() that would stuff the results back into the result map with essentially the same type as the database. One could provide a custom map as well, which might be nice to get back Timestamps instead of Date objects if you want to keep the whole value of your Date object!
I also assumed the use of JDBC 2.0, though I think you could do most of this with just a bit more work in a JDBC 1.1 driver...
Here's the code for the helper object (terribly unoptimized!! Assume a GPL license for the whole post)
public class ProcedureCaller
{
public ProcedureCaller( Connection conn )
{
}
public Map callProcedure( String procname, Object[] args )
{
StringBuffer call = "{" + procname + "( ";
call.append(" }");
String catalog = conn.getCatalog();
ResultSet dbFunction =
conn.getMetaData().getProcedureColumns( catalog,
""
procname,
""
);
CallableStatement cs = conn.prepareCall( call );
short columnOutness;
short columnDataType;
int i = 1;
while ( dbFunction.next() )
{
columnOutness = dbFunction.getShort( "COLUMN_TYPE" );
columnDataType = dbFunction.getShort( "DATA_TYPE" );
switch ( columnOutness )
{
case DatabaseMetaData.procedureColumnIn:
cs.setObject( i++, params[i] );
break;
case DatabaseMetaData.procedureColumnInOut:
cs.registerOutParamter( i, columnDataType );
cs.setObject( i++, params[i] );
case DatabaseMetaData.procedureColumnOut:
cs.registerOutParamter( i++, columnDataType );
}
}
ResultSet procResults = cs.executeUpdate();
{
}
return
}
}
"There is more worth loving than we have strength to love." - Brian Jay Stanley
For anybody listening to this BS, I suggest you actually do some experiments yourself. Java and C++ are close enough that it's quite easy to compile virtually identical code in both. There are too many lies told by both sides and ymmv depending on what you're doing.
I typically find Java runs at 1/5th the speed of C++ (using latest compilers). My own results correlate closely with http://sprout.stanford.edu/uli/java_cpp.html
Listening to what Sun says about Java v C is like listening to what Microsoft says about W2k v Linux.
Your arguments are fine theoretically, they're just false in practise. HotSpot is not nearly that good yet.
http://rareformnewmedia.com/
Here's something I thought I'd throw out there. First, a bit of a disclaimer. I'm no MS VB weenie that likes Java because it's simple to use. I prefer coding in assembler and I do so quite often when appropriate (I reprogram the ECU in my car, for example). However, I also happen to really enjoy coding in Java. It's the most "pleasant" coding environment I've ever used in the past 15 years; period.
I'm a big fan of the "learn one thing well and become an expert on it" approach to life. I focus on something that I know is going to be powerful and/or popular in the future and I learn it well. Java is that thing when it comes to coding.
I learned about vi while in college (about 5 years ago). I thought it was weird and awkward to use, but because it was everywhere and because I could focus on honing my skills with that one editor and be proficient on so many different platforms with it all at once, I learned it. Now I know that editor very well and I happily co-develop under Linux, Solaris, HP, AIX, and even windows with it.
Java is the same type of thing. I learned Java, I learned it well, and now I code peacefully on all those same platforms (sans HP and AIX...I just haven't used those in a while). I've written a datalogger in Java using Swing for my car that works in conjunction with the aforementioned ECU reprogramming effort to provide me with real time data gathering while I'm powering around at the track. What's great is that I did ALL my development under Linux. When it was all done, I slapped the exact same jar file under Windows NT for a friend of mine with a similar car (didn't even have to recompile it!) and it ran flawlessly. He prefers Windows, I prefer Linux.
Why on earth would I have ever considered writing that application under anything but Java? If I had used MFC, I would not only still be pulling my hair out trying to figure out what the hell was wrong with it, but I also would be forced to use Windows when I was done. The same is true if I had coded it using Motif or GNOME/Gtk or most any other X-based environment. I could not have shared that application with friends that happen to like Windows.
That's one of the many benefits of Java; and it's one of the benefits of vi. Learn something that's powerful and flexible once, learn it really well, and you end up reaping benefits from it on a variety of different platforms. Java is quite powerful and I'm happy as hell to see IBM doing all the great work they're doing with Java under Linux!
The ability to move a Java program from one platform to the other without having to recompile is overrated
I humbly suggest that the reason you think this is that you have not seen the future of computers and networks. In the future, bytecode will be flying around from computer to computer - and it will have to run flawlessly wherever it ends up. You could send around source code, I suppose, but you'd still need a rock-solid standard to ensure that source code would compile and run everywhere.
First, make it work, then make it right, then make it fast, then, make it bloated!
Wow, somebody has a pickle up their ass about being in CS! (how snobbish).
I "learned" java in the real world by using it almost every day for applications. Your right - Java is not C nor is it C++. But have you ever heard of "the right tool for the right job"?
C/C++ is great for lower level code, device drivers or embedded systems. Java is excellent on the server as a replacement for CGI (ever heard of servlets/JSP? that's where all the action is these days - and its faster and less resource intensive than CGI). Any other software depends on what your creating and for whom.
Your right that Java is slow RIGHT NOW. But the same was said of C++ 10 years ago. I don't hear too many complaints about the speed of C++. Would I write a Word Processor in Java? Hell no, not until the JVM/JIT stuff gets way faster (although 1.3 is very quick, even with Swing). In C? Sure if I had a team of programmers and a couple of years...C++ would probably be a better choice.
Have you actually tried any 1.3 JDK implementations? I have and I find them way faster than anything previously created, almost as fast as C++ (even in GUI apps). Do you realize that written properly (eg NOT like a C/C++ program), with the proper patterns and optimizations, Java can be quite peppy?
Aparently not.
Before you slag a language or platform, try getting more knowledge than " 2 tutorials in the beginning of the semester that covered Java syntax and constructs" from an old CS prof would would rather write in Assembler or Fortran anyway. Follow your own advice and become informed by true experts in the field.
Does java have its problems? Sure..it nees better JVMs/JIT for better speed and STANDARDIZATION!(are you listening SUN?). That doesn't mean its not a viable development platform for the real world...and its getting better all the time.
BTW. In Java, multiple inheritance is done with little things known as interfaces...but I digress.
Never by hatred has hatred been appeased, only by kindness - the Buddha
Properly designed JSP/ASP/CFM/PHP should not have program logic in the presentation. But this is a problem of the coder and designer not of the technology. The JSP/ASP/CFM/PHP hold the presentation logic and compoments like servlets/Beans/EJBs/COM components/CORBA Orbs etc do all the aplication specific work. I've done this with both JSP and ASP (I like JSP better). Down on the farm, we call this MVC or even n-tier achetecture. Perhaps you've heard of it?
BTW, JSP performacne hits you speak of only happen on the first instance. All subsequent requests go to the already compiled servlet. I believe in some application servers (IBM WebSphere for instance) you can configure the JSP to be compiled on start up, so the user will neer see the performance hit, even if they are the first to hit the page.
Never by hatred has hatred been appeased, only by kindness - the Buddha
I've used Javascript, but my fear of slowness has kept me away from using Java for anything serious. However, I admire Java for its simplicity. I have Eckel's book "Thinking in Java" and the thing that attracts me most to it is his statement that Java would enable people to be "software craftsman" rather than operating system hacks. The language itself seems to have gotten rid of a lot of things that make C++ painful to program in.
So actually, I am interested in trying Java seriously. I just wanted some good examples of what it can do.
No, Thursday's out. How about never - is never good for you?
> Your premise is compeltely off. To restate the above: "Java shouls run code tuned for C++ as fast as C++."
You completely mis-respresent what I say, then refute it. What I'm saying is people should not believe your statements wrt performance because they are false , do your own testing.
> In general java today is MUCH better at in-lining then ANY C++ compiler
So why is it only 1/5 the speed ?
> It is at this point I believe an undisputed fact that a Java coder can write correct code faster then a C++ coder.
Totally disagree. I have been coding Java for 5 years and C++ for 9, I have written a commercial application consisting of 30,000 lines of Java. I first learned Java when 0.9 was released. I'm not some fucking novice.
Several people who's opinion I respect insist that they can develop stuff faster with Java than with C++. If they really know C++ I just
don't understand this, unless they are comparing old (pre-STL) C++ with modern (post-collections)java. The other possibility is that they have been using MFC, a piece of code so vile, that I can barely speak it's name.
I can see that if you're working on a project where (2 or more apply):
threads are important;
has to work on multiple platforms;
requires functionality that JDK library classes cover well;
is deployed over the internet;
speed is not an issue;
memory useage is not an issue;
very precise control is not important;
some team members are inexperienced;
then Java may well be the best choice.
However for implementing arbitrary fresh functionality I can develop far faster in C++ than java. For instance a fragment of a C++ program that reads in a file and gets a list of the starting positions for
every word in the file:
map > word_positions;
string word;
while (cin >> word)
word_positions[word].push_back((int)cin.tellg() - word.size());
Writing the equivalent in Java would take 20+ lines.
Now, I admit this is a contrived example, but do it the other way round - give me a nice piece of algorithmic code in Java and I believe the equivalent C++ will almost always be considerably smaller, and thus easier to grasp. Java is good the beginners, there are fewer pitfalls, but as a language it's just almost entirely a subset of C++.
http://rareformnewmedia.com/