This discussion has been archived.
No new comments can be posted.
IBM JDK 1.3 For Linux
Related Links Top of the: day, week, month.
The finest eloquence is that which gets things done.
The finest eloquence is that which gets things done.
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++.