Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool so your projects have a backup location, and get your project in front of SourceForge's nearly 20 million monthly users. It takes less than a minute. Get new users downloading your project releases today!
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. "
This discussion has been archived.
No new comments can be posted.
I think the best way to get java really doing well would be to have compilers ported to individual platforms, as you could get rid of the speed disadvantage. Until that point, java is too slow for anything i'm using it for.
it's java. if there's one buzzword you gotta know... okay, maybe java isn't it, but it's still pretty useful to know. i'm just glad linux is getting this support for java. it took sun long enough to make a jdk for it.
I haven't downloaded it yet, but I hope native threads can make it in this release. It hurts running my Java apps in Linux while the threads run like they're in Windows 3.1.
It's nice to have a fast java 2 jvm for linux. But what about VAJ 3.02 (enterprise edition) and websphere 3.02. I still used NT because of this two software:-(... I'm waiting for you IBM guys !
Just in time, i've got a java application to deploy on a new linux server i'm building on friday, and this'll be the JDK for me. Previously i would have used SUN/Blackdown 1.2 with the borland JIT compiler. Heres the servers spec (gloat), AMD Athlon 850 (last one with the pluto 2:5 cache), ABit KA7 motherboard, 4*256 PC100 ECC SDRAM (hey Its a server you got to go for reliable memory over fast memory.) IBM 30Gig 7200rpm ATA66 disk drive, 3Com Etherlink 3 100-Base-T networking card, Voodoo 3 3000 (just goes 3dfx does linux drivers). After testing we'll be using it as part of a server farm (with a lot of the same spec machines) for our search engines, at www.remotesearch.com P.S. Got any good keys for freenet.
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.
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.
Java as a compiled, system and arch dependant binary?? Fast, sure. But you're eliminating the main reason to use Java: System independance. If you want fast, use something else!
Yeah, the Sun way of counting, like Solaris 2.7 followed by Solaris 8.
Any guesses what they'll come up with when they feel it's time to change numbering again? The logical next step would be shifting the significant digit further to the left, yielding Java 30 or Solaris 90, wouldn't it?
I have to agree. At the moment I go out of my way to avoid Java. I have a P166, but Java is just too slow by FAR. On a fast computer I think it has it's place, but for people who like to stay back from the technological curve, if only so everything they have is supported in Linux, Java is unusable right now. I regularly have to use a java program (the only one thankfully) and when you click on a button, it can take upward of ten seconds before the action actually does anything.
Of course Java does have the one benefit of being ostensibly platform independent. I mean you can't say everyone should move to C, C++, whatever, because there is nothing to currently compete with Java. Maybe if something appears in competition the way it works may be optimized.
Very cool, very cool... The Blackdown 1.2 JDK runs JBuilder3.5 ass slow (not that I don't appreciate it guys... it's far better then most Mac support I've seen) It will be good to have something all super-quick like IBMs 1.1.8 JDK. Right on, you guys rock!
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 [sun.com] 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..."
Whadaymean off topic. I say what I going use JDK 1.3 for, and where it will be deployed and, you call it off topic. What mores on topic for an application than how and where its going to get used?
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.
are you saying it's not enough of a language to stand for the merits of that? and besides, you don't need to eliminate the ability to run on multiple platforms to be able to compile it on specific ones
Does this release go any way as to bridge the gap between the native GUI and applets which are being run under the JVM? I'm not expecting full support for all the features KDE/Gnome/whatever provide, just the option of using the Widgets from the relavent toolkits, hence inheriting Theme support and the like.
I agree. I use and develop for Debian's Alpha release of Linux and it's getting horribly irritating how many companies claim to support "Linux" when they really only support Intel-based Linux systems. I've even emailed a few to offer porting help, but to date, I've only received probably two responces (both of which were basically "not interested"). Just goes to show that even in their support of Linux, the almighty dollar and market share motivate these companies more than proliferation of their technology.
Yeah, and with all those numbers, it's so easy to forget one and have JDK 1.3, which still is Java 2. What a clever way to show us how meaningless numbers are.
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.
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.
Java on web pages was a stupid, stupid idea. Java as a non-GUI, server side solution is a viable idea. Just because org.lame.StupidApplet is slow in your browser is no reason to count out a nice language.
Well, I'm glad to see they did release a 1.3 compiler, but whatever happened to a 1.2 compiler? I think IBM's getting version-skipping happy. Not that I'm complaining, just curious.
Thanks to IBM, it may one day be reasonable to run Java Servlets/JSP's for a web page;)
This is cool and all, but what I want to know is when Mozilla for Linux will ever get Java support. Apparently nobody's come in with a JVM to drop in, and Sun's been pretty silent about whether they will provide one or not for Linux...
surak_at_my-deja.com, using Mozilla build 2000050308 without a clue about whether it will crash when he attempts to post this comment.
Even though I'm an x86 user (486, more specificly) I'm inclined to agree with you. Can they not pull out a sparc or something and compile, or what?
of course, I'm sure there would be porting or something, I dunno, but anyway, I don't think that the majority should rule _all the time_, even when I'm a part of that majority.
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.
This Agreement will terminate ninety (90) days after the date on which you receive the Software. Upon such termination you will delete or destroy all copies of the Software.
Darn. I'd better delete my copy on day 89... ...just to be safe
Or better yet - maybe I just won't download it at all.
I notice that you've failed to mention the obvious requirements of a _real_ server: - redundant disk drives (ie. RAID) - redundant power supplies - multiple network cards and adapter teaming - multiple processors - tape backup Also, if you're going to deploy this wonderful app of yours on a brand new JVM without testing, you are crazy. It doesn't sound to me like you've ever seen a real server...
Java on web pages was a stupid, stupid idea. Java as a non-GUI, server side solution is a viable idea. Just because org.lame.StupidApplet is slow in your browser is no reason to count out a nice language.
I've still noticed that sites using jsp are still slightly sluggish when compared to other types of server side (insert internet service here) applications. I know, I know it also depends on the programmer and the jre, but I'd say it's usually a good bet that it will suck...
I'm sure there are good java apps, I've just never seen one.
By the time I've posted this, I bet there'll be half a dozen posts saying that Java is crap, Java is slow, moan, groan, Java can't be used for low-level system programming etc. Oh well, if you can't beat them, join them... Java is great, it'll replace C for all high level programs:)
Seriously, I wonder how much of the opposition to Java from many C programmers is due to the amount of experience they've accumulated in C? It's bound to make people resentful [disclaimer: I've spent the last 18 months learning Java in university]
Well, Java is a proprietary and Mozilla is fully open source and Sun is a bit antsy about opensourcing Java. I've heard about some projects to reverse engineer Java, but mozilla is a corp. entity and they tend to get a bit antsy with legal issues...so...:(
Actually, we've got an SUN E450 dual processor machine tith SUN Disk suite RAID 0+1. But for this application we need lots and lots of cheap ECC RAM. The SUN E450 will to all the disk work, while the farm of AMD linux boxes do the in memory and some integer compute work. Plus (and this is the on topic part) theirs no point in multiple processors for linux Java, because their isn't one JDK that supports SMP on linux, and thats with native or green threads.
Here's a chart of the results I used to make my previous assertions. Although I don't have results for #'s of threads below 10, you can see the trend that as the number of threads goes down, IBM's VM gets faster.
I know from experience that IBM's VM wins beats Blackdown+Inprise JIT in single thread competitions. The chart is here [umass.edu] and measures the number of milliseconds response time of a Java servlet.
I this this would be useful, too, but I don't see many people working on Gtk+ or Qt lookalike PLAFs for Swing. A notable exception is the Skin Look & Feel, but it doesn't seem to be progressing very quickly.
The Java Foundation Classes, better known as Swing, are 'lightweight': They don't use the underlying GUIs' widgets.
Swing does however support 'look-n-feel' classes, and Sun ships looks and feels for Windows, Motif, and 'Metal' (which is the most aesthetically pleasing, IMNSHO). O've also seen a decent BeOS LnF. Theoretically, you can write a look-n-feel that knows how to use the same pixmap sources the KDE/Gnome/whatever themes. That exercise is left to the reader:^)
Don't think they'll be "pixel identical". You've no idea how often I see code that hard-codes the layouts to fixed pixel sizes (rather than use layout managers) that look ugly as hell 'cause on a different platform the fonts are different sizes.
And what's "accelerated" in AWT? Nothing can be done in AWT that the hardware can really take advantage of. Graphics cards are unaware of "windows" (in the Windows or X sense) as far as I know. The only exception are 3D cards, and you need Java3D to get acceleration out of them.
As for basic drawing, well the "Graphics" object is the same, regardless of whether you're doing Swing or AWT (its an AWT object), and its a Graphics2D object. If the VM implementation uses hardware acceleration for that, cool. You'll get the benefits regardless. In fact, if it IS accelerated, Swing may be faster than AWT.
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.
No IBM isn't doing any funny business. They actually did skip 1.2.x and have now released a 1.3, a version still officially in Early Release at Sun. Oh and a nit: it's not the compiler really, it's the jvm, associated libraries and the other tools (like javadoc). You can still use jikes (rocks!) with 1.2.x or 1.3 same was with 1.1.x because the byte codes are still the same.
Of course when you do that, you you're stripping away "compile once run everywhere" and revealing Java for what it really is: a C++ wannabe.
Seriously, I think the idea of having platform independant VMs is cool, but why didn't they just write a VM and a C/C++ compiler for it? With stuff like Bochs [bochs.com] out there, who needs Java? All it does is give you yet another codebase in yet another language. Feh!!!.
Well i wouldn't put quake in Java applet, but their is plenty your can do in one. I consider a Java applet as a program running on computer 5 years behind the state of the art. Put thats ok theirs still plenty of stuff you can do with that. The coolest java applet i've seen was a complete ZX Spectrum 48K emulator on a web page. I got quite a way with designing a gaunlet style game in Java, before giving it up for more serious stuff. Its still around at http://194.201.87.84/ if anyone wants a look. Ok the graphics were lame, i'm a programmer not a graphic designer.
Is it just me, or are the only java applications are development tools. Where are the java applications that were supposed to tranform the computer industry it's been five years now.
It would seem that now, with the rate at which things are changing, people would welcome change, but the fact is, no one wants to spend time learning how to do something just to find out that something new has come out which can replace the thing that they already know.
It makes them feel like they have wasted their time learning C. Personally, I would hate to have to start over and learn a new language when I was comfortably entrenched within my knowledge.
One of the big advantages of Java now is that the code is truely mobile. Platforms such as Java/RMI and the more elaborate Java/Jini allow not only data but code to be sent over the wire. The 'recompile for every platform' model just doesn't work when you want to ship code as well as data.
I've still noticed that sites using jsp are still slightly sluggish when compared to other types of server side (insert internet service here) applications. I know, I know it also depends on the programmer and the jre, but I'd say it's usually a good bet that it will suck
JSP/ASP/CFM/PHP - different implementations of a fundamentally flawed concept, embedding logic within presentation. However, putting that complaint away for a minute...
JSP can be slow, yes. This is mainly because of the two-step that happens when you access a JSP file: first the server compiles it as a servlet, then it serves the output of the servlet. Predictably, this tends to suck performance-wise, although the performance of the most popular JSP engines seems worlds better now than a year ago, and hopefully will continue to improve.
On the other hand, I have seen performance from compiled servlets (not jsp) both on big-ass proprietary app servers and on low-end servlet engines that is subjectively at least pretty impressive. I say subjectively because I don't have any benchmarks at hand.
Server-side Java is much wider than JSP, and has been around much longer. Just look at the commercial development/app-server products that use Java as the development language. Hopefully with Jserv, Tomcat, and other projects becoming more mature we will have a good set of options for server-side Java that don't involve paying server tax to a vendor who is trying to lock you in for the life of your project.
Besides performance, there is the benefit of better maintainability using Java, and the benefit of all of those CS/tech school grads who learned Java over the past couple of years. In a recent round of interviews, I was astonished to see no less than 100% of our candidates had learned Java _first_, before being taught C/C++/VB. I'm old - so very old...
Ok, I hadn't read the earlier comment (it was below my threashold) about 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.
It can't accelerate Swing, since Swing is 100% java. Its translated to Graphics object calls, which translate to graphics primitives in Windows or Xlib.
And since when did hardware video cards actually become "Component aware" of things like menus, pushbuttons, etc. X has NEVER had that as far as I know (not in Solaris, not in SGI, certainly not in XFree). Widgets in Xt/Motif are 100% implemented in Xlib calls. The port of X to the platform can take some advantage of hardware for graphics and images, but beyond that, the hardware has no idea what "Xt" or "Motif" are. The X Server doesn't either. Go look at the X11 protocol.
Optimization of GUIs usually involves buffering, particularly of pixmaps and colormaps. Or, it involves improvements like Low Bandwidth X, the Shared Memory extension (where the network aspect of the X protocol is removed, and the client basically sends the protocol to the server through shared memory), or direct x (no relation to microsofts DirectX), where Xlib directly draws onto the screen rather than telling the server to draw.
If graphics cards for the PC platform actually have an awareness of "push button", i would be severely suprised. "Specific calls" for a push button are "fill this rectangle, now draw these 4 lines and this string in this color... ok, now fill the rectangle in a different color, draw these same 4 lines in a different color, and redraw the string." Oh, gee, that can really benefit from hardware acceleration?
Guys, I understand the sentiment, but releasing a product on ANY version of Linux costs $$$$. No matter how "cool" it would be to release a JDK for Linux/Alpha, I doubt the marketshare is there to make it worth their money. Market share and technology "proliferation" are tied to $$$, not the complaints of 5 or 6 people who may really want it on their cool, but relatively little used platform.
If you would be willing to put up the quarter million dollars it takes to port and test a major peice of code like the 1.3 JDK then I am sure a company like IBM would be pleased to do it for you. If you are not willing to put up this money... why should IBM?
Well, Java is a proprietary and Mozilla is fully open source and Sun is a bit antsy about opensourcing Java. I've heard about some projects to reverse engineer Java, but mozilla is a corp. entity and they tend to get a bit antsy with legal issues...so...:(
Not an issue. Mozilla will (and does on Win32) support OJI [mozilla.org], an API for hooking up JVMs; any free (or open source, ick) JVM could be modified to use plug right in. A JVM does not have to have source available for it to use OJI.
In fact, it would be to Sun's advantage for their JVM to support OJI on all platforms, as the presence of Mozilla on those same platform would give it an immediate application.
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.
ACtually, (at least in Windows) java is accelerated in the graphics dept. a bit as I remember reading that it's underlying implementation relied on DirectX calls.
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.
For a good report on how different JVMs scale (the new IBM 1.3 JVM for Linux isn't included, as this report dates from the end of March, 2000), check out: http://www.volano.com/report.html.
Fred Lavigne (http://fred.lavigne.com/) has written a Swing Look And Feel class that uses gtk themes. Its not perfect, but it works.
He also has some code (independent of that) that implements some GTK/Gnome features in java.
Unfortunately, the site isn't coming up in my DNS right now...but look up SkinLF on freshmeat [freshmeat.net]. I wrote some code on top of that which will look at the local.gtkrc file and load up the default gtk theme.
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.
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.
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.:-)
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?
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 [transvirtual.com].
Also take a look at this list of compilers and virtual machines [geocities.com], 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.
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.
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...)
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!
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 [volano.com]. 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 [umass.edu] 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!
. "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++...
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?
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)
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."
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.
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.
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.
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[]. }
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.
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.
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.
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.
You may find this article [ibm.com] 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.
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.
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.
> 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++.
I'm just a love machine... (Score:1)
Java? Close... (Score:1)
Re:Who cares? (Score:1)
Native threads? (Score:1)
Re:Too Late (Score:1)
IBM just released Java 1.3... so they're in step.
What about VAJ and Websphere (Score:1)
I still used NT because of this two software
I'm waiting for you IBM guys !
JDK 1.3 (Score:1)
Non-x86 Linux users in the dust, as usual (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:Native threads? (Score:2)
Java Compiler (Score:3)
Re:Too Late (Score:3)
Re:I don't like Java (Score:1)
Would you feel better if everyone said: "Me too!!!! Java sucks!!!
Re:Java? Close... (Score:1)
Re:Too Late (Score:1)
Any guesses what they'll come up with when they feel it's time to change numbering again? The logical next step would be shifting the significant digit further to the left, yielding Java 30 or Solaris 90, wouldn't it?
Re:I don't like Java (Score:1)
Of course Java does have the one benefit of being ostensibly platform independent. I mean you can't say everyone should move to C, C++, whatever, because there is nothing to currently compete with Java. Maybe if something appears in competition the way it works may be optimized.
SWEET (Score:1)
The Blackdown 1.2 JDK runs JBuilder3.5 ass slow (not that I don't appreciate it guys... it's far better then most Mac support I've seen)
It will be good to have something all super-quick like IBMs 1.1.8 JDK.
Right on, you guys rock!
---
Get clue. (Score:2)
Re:Too Late (Score:2)
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 [sun.com] 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...
Re:Too Late (Score:1)
Java as a user interface (Score:3)
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?
Re:Too Late (Score:1)
No.. like Solaris 2.51, Solaris 2.6, Solaris 7, Solaris 8.
It's now up to SunOS 5.8 if I'm remembering my Sun versioning...
Maybe we need to send some Sun Marketing types back to kindergarden to learn to count!
Re:Too Late (Score:1)
Re:JDK 1.3 (Score:1)
IBM Native Threads implementation inefficient (Score:5)
Re:Java? Close... (Score:1)
Though this be madness... (Score:1)
Solaris 7 == Solaris 2.7
Java 2 == Java 1.2
Re:I don't like Java (Score:1)
I also wanted to see if I should think otherwise or if I wasn't alone in my thoughts about java.
Seemless integration of Java with native Linux GUI (Score:1)
Re:Non-x86 Linux users in the dust, as usual (Score:1)
Re:Though this be madness... (Score:1)
Re:Java as a user interface (Score:2)
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 can only wish I could use this... (Score:1)
Still, it's great news for other Linux Java developers, I'm sure, and it makes me glad to know that Win/Solaris aren't the only ones anymore.
When will Apple catch up? They still don't have a Java 2 JVM yet. MacOS X will bring that, true, but have they even begun work on a 1.3 JDK?
Lightweight vs. Heavyweight components (Score:3)
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.
Client side java isn't the only Java (Score:1)
Version Number happiness? (Score:1)
Thanks to IBM, it may one day be reasonable to run Java Servlets/JSP's for a web page
Java for Mozilla? (Score:1)
surak_at_my-deja.com, using Mozilla build 2000050308 without a clue about whether it will crash when he attempts to post this comment.
Re:Non-x86 Linux users in the dust, as usual (Score:1)
of course, I'm sure there would be porting or something, I dunno, but anyway, I don't think that the majority should rule _all the time_, even when I'm a part of that majority.
Re:Java? Close... (Score:4)
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.
90 Day Trial License Agreement (Score:1)
From the License Agreement:
2. Term and Termination
This Agreement will terminate ninety (90) days after the date on which you receive the Software. Upon such termination you will delete or destroy all copies of the Software.
Darn. I'd better delete my copy on day 89...
...just to be safe
Or better yet - maybe I just won't download it at all.
That's not a server... (Score:1)
Re:Client side java isn't the only Java (Score:1)
I've still noticed that sites using jsp are still slightly sluggish when compared to other types of server side (insert internet service here) applications. I know, I know it also depends on the programmer and the jre, but I'd say it's usually a good bet that it will suck...
I'm sure there are good java apps, I've just never seen one.
How long before the flame wars start? (Score:1)
Seriously, I wonder how much of the opposition to Java from many C programmers is due to the amount of experience they've accumulated in C? It's bound to make people resentful [disclaimer: I've spent the last 18 months learning Java in university]
Java...propritary :( (Score:1)
Re:JDK 1.3 (Score:1)
Re:IBM Native Threads implementation inefficient (Score:1)
I know from experience that IBM's VM wins beats Blackdown+Inprise JIT in single thread competitions. The chart is
here [umass.edu]
and measures the number of milliseconds response time of a Java servlet.
Re:Seemless integration of Java with native Linux (Score:1)
JFC(Swing) does not use native peers. (Score:1)
Swing does however support 'look-n-feel' classes, and Sun ships looks and feels for Windows, Motif, and 'Metal' (which is the most aesthetically pleasing, IMNSHO). O've also seen a decent BeOS LnF. Theoretically, you can write a look-n-feel that knows how to use the same pixmap sources the KDE/Gnome/whatever themes. That exercise is left to the reader :^)
Re:Lightweight vs. Heavyweight components (Score:1)
Don't think they'll be "pixel identical". You've no idea how often I see code that hard-codes the layouts to fixed pixel sizes (rather than use layout managers) that look ugly as hell 'cause on a different platform the fonts are different sizes.
And what's "accelerated" in AWT? Nothing can be done in AWT that the hardware can really take advantage of. Graphics cards are unaware of "windows" (in the Windows or X sense) as far as I know. The only exception are 3D cards, and you need Java3D to get acceleration out of them.
As for basic drawing, well the "Graphics" object is the same, regardless of whether you're doing Swing or AWT (its an AWT object), and its a Graphics2D object. If the VM implementation uses hardware acceleration for that, cool. You'll get the benefits regardless. In fact, if it IS accelerated, Swing may be faster than AWT.
Re:Too Late (Score:1)
I'm voting for Java e^i*Pi
java gets a bad rap (Score:5)
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:java gets a bad rap (Score:1)
http://sunsite.auc.dk/jde/
It rocks (=
Re:Version Number happiness? (Score:1)
Re:Java? Close... (Score:1)
Of course when you do that, you you're stripping away "compile once run everywhere" and revealing Java for what it really is: a C++ wannabe.
Seriously, I think the idea of having platform independant VMs is cool, but why didn't they just write a VM and a C/C++ compiler for it? With stuff like Bochs [bochs.com] out there, who needs Java? All it does is give you yet another codebase in yet another language. Feh!!!.
Sorry. Had to vent somewhere.
Re:Client side java isn't the only Java (Score:1)
Re:I can only wish I could use this... (Score:1)
--hunter
Re:Java...propritary :( (Score:1)
Where are the java applications? (Score:1)
Re:How long before the flame wars start? (Score:1)
It would seem that now, with the rate at which things are changing, people would welcome change, but the fact is, no one wants to spend time learning how to do something just to find out that something new has come out which can replace the thing that they already know.
It makes them feel like they have wasted their time learning C.
Personally, I would hate to have to start over and learn a new language when I was comfortably entrenched within my knowledge.
Re:Java? Close... (Score:1)
Re:Java? Close... (Score:1)
Re:What about VAJ and Websphere (Score:2)
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
Re:Client side java isn't the only Java (Score:1)
JSP/ASP/CFM/PHP - different implementations of a fundamentally flawed concept, embedding logic within presentation. However, putting that complaint away for a minute ...
JSP can be slow, yes. This is mainly because of the two-step that happens when you access a JSP file: first the server compiles it as a servlet, then it serves the output of the servlet. Predictably, this tends to suck performance-wise, although the performance of the most popular JSP engines seems worlds better now than a year ago, and hopefully will continue to improve.
On the other hand, I have seen performance from compiled servlets (not jsp) both on big-ass proprietary app servers and on low-end servlet engines that is subjectively at least pretty impressive. I say subjectively because I don't have any benchmarks at hand.
Server-side Java is much wider than JSP, and has been around much longer. Just look at the commercial development/app-server products that use Java as the development language. Hopefully with Jserv, Tomcat, and other projects becoming more mature we will have a good set of options for server-side Java that don't involve paying server tax to a vendor who is trying to lock you in for the life of your project.
Besides performance, there is the benefit of better maintainability using Java, and the benefit of all of those CS/tech school grads who learned Java over the past couple of years. In a recent round of interviews, I was astonished to see no less than 100% of our candidates had learned Java _first_, before being taught C/C++/VB. I'm old - so very old ...
Re:Lightweight vs. Heavyweight components (Score:1)
It can't accelerate Swing, since Swing is 100% java. Its translated to Graphics object calls, which translate to graphics primitives in Windows or Xlib.
And since when did hardware video cards actually become "Component aware" of things like menus, pushbuttons, etc. X has NEVER had that as far as I know (not in Solaris, not in SGI, certainly not in XFree). Widgets in Xt/Motif are 100% implemented in Xlib calls. The port of X to the platform can take some advantage of hardware for graphics and images, but beyond that, the hardware has no idea what "Xt" or "Motif" are. The X Server doesn't either. Go look at the X11 protocol.
Optimization of GUIs usually involves buffering, particularly of pixmaps and colormaps. Or, it involves improvements like Low Bandwidth X, the Shared Memory extension (where the network aspect of the X protocol is removed, and the client basically sends the protocol to the server through shared memory), or direct x (no relation to microsofts DirectX), where Xlib directly draws onto the screen rather than telling the server to draw.
If graphics cards for the PC platform actually have an awareness of "push button", i would be severely suprised. "Specific calls" for a push button are "fill this rectangle, now draw these 4 lines and this string in this color... ok, now fill the rectangle in a different color, draw these same 4 lines in a different color, and redraw the string." Oh, gee, that can really benefit from hardware acceleration?
Re:Non-x86 Linux users in the dust, as usual (Score:1)
If you would be willing to put up the quarter million dollars it takes to port and test a major peice of code like the 1.3 JDK then I am sure a company like IBM would be pleased to do it for you. If you are not willing to put up this money... why should IBM?
Re:Java...propritary :( (Score:1)
Not an issue. Mozilla will (and does on Win32) support OJI [mozilla.org], an API for hooking up JVMs; any free (or open source, ick) JVM could be modified to use plug right in. A JVM does not have to have source available for it to use OJI.
In fact, it would be to Sun's advantage for their JVM to support OJI on all platforms, as the presence of Mozilla on those same platform would give it an immediate application.
Java = Language + RTL + VM / compiler (Score:2)
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 as a user interface (Score:1)
Very few good C++ programmers out there... (Score:4)
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:IBM Native Threads implementation inefficient (Score:1)
-jon
Re:JFC(Swing) does not use native peers. (Score:1)
written a Swing Look And Feel class that uses
gtk themes. Its not perfect, but it works.
He also has some code (independent of that)
that implements some GTK/Gnome features in java.
Unfortunately, the site isn't coming up in my DNS right now...but look up SkinLF on freshmeat [freshmeat.net]. I wrote some code on top of that which will look at the local .gtkrc file and load up the default gtk theme.
Re:Java? Close... (Score:2)
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).
Slow Java2? (Score:2)
Re:What about VAJ and Websphere (Score:2)
Re:Very few good C++ programmers out there... (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:Java as a user interface (Score:2)
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?
Re:Java = Language + RTL + VM / compiler (Score:2)
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 [transvirtual.com].
Also take a look at this list of compilers and virtual machines [geocities.com], 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.
mini-benchmarks: not as fast as 1.1.8 (Score:3)
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
Re:IBM Native Threads implementation inefficient (Score:2)
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.
Misconceptions (Score:5)
Misconceptions (Score:2)
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:Very few good C++ programmers out there... (Score:2)
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!
Re:IBM Native Threads implementation inefficient (Score:5)
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 [volano.com]. 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 [umass.edu] 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!
Re:How long before the flame wars start? (Score:2)
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) (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++...
Re:Non-x86 Linux users in the dust, as usual (Score:3)
Re:Where are the java applications? (Score:2)
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)
Re:Very few good C++ programmers out there... (Score:2)
-----------
"You can't shake the Devil's hand and say you're only kidding."
Re:Java Compiler (Score:2)
Re:I don't like Java (Score:3)
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.
Re:Non-x86 Linux users in the dust (of course!) (Score:3)
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. (Score:2)
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
}
}
Total BS (Score:4)
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.
Re:Java Compiler (Score:2)
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.
People who like vi like java (Score:4)
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!
Re:Java? Close... (Score:2)
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.
Re:How long before the flame wars start? (Score:2)
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.
Re:IBM Native Threads implementation inefficient (Score:2)
You may find this article [ibm.com] 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
Re:Client side java isn't the only Java (Score:2)
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.
Thank You (Score:2)
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, no, no (Score:2)
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++.