Industry Leaders Discuss Java Status Quo
prostoalex writes "JavaPro magazine published a wrap-up report on Java discussions at the recent JavaOne. If you missed JavaOne, the video Webcasts of McNealy, Schwartz, Gosling et al. are available from this site. The round table mentioned above gathered people from Sun, Oracle, Borland, Novell, Motorola and others. The discussion topics included: Java vs. NET, integration issues, the impact of open source and top problems that Java is facing today."
Java Script, Java Beans, Java Swing, Java Status Quo!? Enough!
I'm a full time VB programmer who is looking to move away from microsoft tools as well as microsoft platforms.
I started out not knowing anything but ms products- learned VB in school and landed my first job writing database apps. As I learned more, and my employer's needs grew- we started realizing that MS was too expensive and we looked for alternatives.
Now we use linux and open source tools. I am learning to handle a system and use software that has been built by the open source community. I've even tweaked some code here and there for our own purposes.
While all this has been going on- I've been trying to look to the future and work on some projects of my own. I really wanted to learn a language that would be portable, and have good tools I could afford. I've finally opted to go with Java.
Java seems the simplest way to be able to work cross platform and have access to sufficient resources without having to shell out big bucks. In fact my development platform right now is a RedHat box with eclipse and Sun's JDK. I'm about 2 months into what I hope will be a long relationship. I think the article is right in that what is good for Linux is also very good for Java.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
I'm not saying that everybody needs to stop contributing their pet projects to the communal good, but maybe the deal doesn't need to be made sweeter for these scummy companies that are building cheap foreign and selling expensive domestic. I'm starting to think that (L)GPLv3 should involve a clause invokable by the author of a project so covered that it not be used in any commercial application whether source is included or not.
The biggest irony is when movie companies using Free Software turn around and lobby our government to harm users of Free Software. This free ride shit has got to stop, there.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Does anyone else find it a little disconcerting that, "according to a recent Evans Data Corporation survey, developers who are migrating now from Visual Basic are moving to Java and C# in roughly equal numbers." What good is a few years head start and breathless hyperbole from the entire technology industry when Microsoft can simply create a new competitive product and quickly catch up? Java may well continue to be quite successful even though it has under-delivered, but that could mean little with C#, .NET, and whatever else comes out of Redmond. Does Java have enough momentum to thrive?
This is not a troll.
Why does anyone use Java, ever? In what situation does it offer anything that justifies the pain and inconvience that it incurs?
Can you think of even one Java application that you use on your desktop and like?
Can you think of a single language/runtime that feels so out of place no matter what platform you're running on? A platform that makes you deal with CLASSPATH, non-native and slow widgets, and shell scripts to set a thousand environment variables before starting your "portable" application?
Can you think of a single problem domain where Java offers greater portability than the competition? Standard C, C++ or Python (depending on your desired level of abstraction) are just as portable as Java as long as your libraries/toolkits are cross-platform. And programs written in these languages just fit in, they find their libraries without fuss, they start up rapidly (in comparison) instead of seemingly spawning an OS within an OS.
I've felt this way about Java since the moment I first tried it, and I'm still at a loss. I just don't get why so many people decide that Java is the solution for them.
What I'm getting at is that a little goes a long way with display updates. Having a 'silken mouse' under Windows NT+ meant that even under heavy load the interface felt smooth and responsive (well, until you tried to open a window or do something requiring CPU) -- with Win9X/ME the mouse would jerk around under even mediocre load. X-Windows also felt like it was sluggish until I discovered you could 'nice -n -10' it. On the AS/400, heavy priority is given to interactive applications but batch jobs (which only run in the background) and compiles are typically executed at a lower priority.
My point is that they need to optimize the speed with which displays and user interface updates are performed to achieve the effect where the user feels like the application is crisp -- even if it impacts performance in other areas. It's a subtle user interface trick that they've missed out on, although I'll admit that Java 2 is making things a little better.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Maybe Iâ(TM)m ignorant, but I donâ(TM)t think there is an IDE for java that comes close to Visual Studio. While VS.NET might have its problems, it is integrated very tight. As a developer I donâ(TM)t want my time taken up with simple tasks, Iâ(TM)d rather work on the interesting bits.
Java isn't slow; Java is a language.
.NET addresses this by letting you pre-compile CLR code into binaries; that doesn't make the code run faster, but it makes programs start up faster.
No, Java is a platform with multiple implementations of the compiler/JIT and (effectively) a single implementation of the libraries.
Java compilers/JITs achieve very good performance, having little overhead compared to analogous C code.
But the Java platform falls short in several areas.
First, the VM has an enormous memory footprint, and it starts up very slowly. VM sharing is supposed to address this, but it hasn't materialized.
Second, Java's native code interface (JNI) is inefficient and Java cannot efficiently access native data structures. That makes it difficult to reuse existing, mature C/C++ libraries, and to interface efficiently with operating system facilities.
Third, Java's libraries are not designed for speed: their APIs impose a lot of overhead, and the actual implementations aren't very good either. Also, Java's libraries are designed for generality first, and speed and high-quality cross-platform support distant seconds (things like Java2D just don't run very well on all platforms).
Sun JRE is slow. The JVM runs as another layer on top of the OS, so of course it will be slower than if it were native to the OS. All Sun has to do is make a JM (Java Machine) chip that can be put into motherboards to do the processing at the hardware level, not hardware-os-software level.
Raw CPU performance is not the issue. Java code runs very fast in Sun's current implementation. A Java native chip would not help at all (and would be impossible to make succeed in the marketplace anyway). The problems with Sun Java performance are platform design problems. In a sense, Sun's focus on CPU performance has distracted them from addressing the real performance problems.
I see a lot of the usual anti-Java posts on here. "It's slow", "The screen flickers", "The widgets suck."
Just like any other technology, implementation is more key to the quality than the technology itself. I have seen some REALLY bad Java client side applications, but then there are some that are awesome. The GUI installer for Oracle is Java Swing. It looks identical on every OS you install it on (aside from options that may or may not be available to install on a given platform), and it works really well. Another example is Veritas' VMSA software. It is Java Swing, allows you to run it on multiple platforms, and you use it to manage your Veritas volumes on multiple hosts, networks etc. If an organization spends a $100k+ on a storage system, you can bet your ass that they would be mighty pissed if they had some "slow shitty client software" messing things up.
And don't even dis Java on the server side either. Java on the server side does not have to be slow like everyone thinks. One example is the application server Orion. You want to have some fun, go to http://www.orionserver.com, download it, and install it. Then do some apache bench comparisons between it and even a tuned Apache and Orion will serve static HTML pages faster. For even more fun, whip up a JSP with a database call to Postgres or Oracle, and bench that against Apache still serving static content. Orion will actually serve dynamic DB-generated content as fast or faster than Apache can handle static HTML.
I guess the point I am trying to make is don't just make blanket statements and put down a technology because of a bad experience. It is all about the implementation. Best technology with a shitty implementation will suck no matter what.
--Jon
Turns out that Java 1.5 will have these features and more - one thing I am really looking forward to is generics.
The final advantage of C# over Java was that a C# program looked like it belongs on Windows - same widget set, same "feel". This is a bigger deal than most people realize. Windows users grow accustomed to doing things a certain way, and they don't like it when you try to impose something different on them. Swing just doesn't cut it in this regard.
Java is slow if you write a slow program that doesn't respect the platform and language's unique features and quirks, just like any other language (consider the uneven implementations of STL in C++).
.NET's VM, but suspect that they excluded many of the going-forward limitations of java.
See the issue is not really with the JVM, but with the tradeoffs of the language. While it's possible to write somewhat snappy engines like jrocket, or integrate OS features like the windows version, there are certain fundamental issues which can not be handled transparently.
Firstly, hands-off memory management. It's difficult to heuristically discover deterministic memory patterns which would allow inner-loop optimizations. (I'm not even aware of anyone even trying this). The lack of explicit deletions/frees (even if only advisory) is bad in my opinion. It has fostered enormously wasteful memory utilization in enterprise level applications. And when your building blocks aren't efficient, how can you hope to build efficient apps. I use the java-based idea editor, and scrolling or doing a screen refresh requires one or more garbage collections, and I've already given the VM most of the memory on my system.
To a lesser role, the default virtualization of methods is a slow-down. To some degree a JIT can heuristically generate deterministic call-trees to remove the virtualization (e.x. if no subclasses are used/found), but this can be really nasty in the general case. This is much worsened when interfaces are used (method/variable lookups are non-constant in time, to say nothing of the overhead). And lastly, there is a growing trend in using reflection for general processing. This just about throws all optimizations out the window.
While I definately see the value in multiple inheritance (or at least java's interface version), and a language definately needs to dynamically map itself somehow, Sun's particular decisions do not lend themselves to high performance inner-loops; even if hardware accelerated.
Thus the only way to write performant / memory-safe programs is to make all your inner-loops use static/final, and to re-invent the standard libraries where-needed. And this is to say nothing of the libraries that can not be reverse-engineered (GUI, OS-interacting, etc). Though theoretically you could write material using jni, what's the point?
If you need jni to make something usable (in the common case), then the language isn't practical.. jni is for porting or special cases.
See, I agree with you basic point which is that java is a language, and this has little to do with the mapping to the machine-code. Ideally, java can be treated just like c, and written directly to assembly (gjc). However, due to the points above, even gjc has to use wrapper functions for these java-specific idioms, and thus the inner loops are no faster than in a nicely optimized jit.
And as I said above, none of this matters, if the APIs of the language encourage practices which do not scale. SUN learned this about their GUI in 1.0, and I'm seeing more and more performance friendly topics arising. However, much core can't be changed.
I am not completely familiar with
I think java is a wonderful language to program in, but all too often, modern software requires a scale that java just can't seem to comfortably live in. And thus I have my doubts about it's future.
-Michael
(sun won its suit against microsoft that it was unfairly squeezing out the java vm - then promptly sued microsoft for posting the microsoft jvm on windowsupdate.com because the license from sun didn't explicitly allow that. they won the suit and for some time windows users just couldn't get their hands on a vm. and if that doesn't decimate any gains from using java, i don't know what does)
What are you talking about? Windows users have always been able to get their hands on a JVM, just not the Microsoft one because of the lawsuit. Nothing stopping users from downloading one of the many other implementations of the JVM on Windows.
I wear pants.
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
I'm personally a little tired of the argument that Java is bad because its not open source. While Sun's implementation of the JVM is closed, Java as a language is light years from being a closed source, completely under Sun's control kind of thing.
1) JVM is an open specification (how you implement it and whether that is open or closed is up to you) There are many JDK's/JVM's that you can use to run Java programs other than Sun's (IBM, Kaffe, or whatever the open source one is (and I'm sure there are more than just that, etc)
2) You get the source code for all of the classes/libraries that come with java when you download Sun's JDK. These include the core classes like java.lang.String, etc, etc. The only thing missing, as stated above is the source code for the compiler/interpreter and other tools.
3) There are open source JVM's (i.e. kaffe, etc) although I've found them to be lacking, but they'll get there
So the argument that Sun has control of Java is moot, you can build/run/install and entire Java application without ever touching Sun tools.
Is Java/JVM totally free? Depends who you ask. Its free/open enough for me, personally, but I can see how some open source fanatics can get their panties in a bunch over this.
Also, unlike M$ products, I think the design of Java's classes shows insight, and well thought out design, so in a way I for one am for Sun keeping a bit of control over the language and "core" classes, but thats my opinion of course.
-- A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard