Slashdot Mirror
Java Success Stories
gark writes "The Java Lobby has a
weblog on Java success stories. Many of the successful applications are servlet based, and several use Apache JServ. Perhaps WORA [write once, run anywhere] really has been achieved, at least for server apps."
TAKE MY KARMA PLEASE!!!
Java *successes* eh?
What about all those Java failures that no one ever talks about. The charred, smoking wreckage. The orphans.
Wake up people, there's a side of Java that the industrio-trilateral commission regulated media doesn't tell you about.
Viva la revolucion!
_.......................__
||.....__...._._||_..||-\\..._...._._||_
||......_\\.(/_'..||....||-//.//.\\.(/_'..||
||__((_||_,_/).||_..||....\\_//.,_/).\\_
The final word; anything following is redundant.
Where the guy shouts all sorts of admonishing remarks at his dog; and all the dog hears is...
"Blah blah Java blah blah blah Java".
Java was a good try - but it's time to move on to a better (and open) solution.
Kwanzaa......Happy holydays & Kooky Kwanzaa everyone. Chappy Channukah Chaps.
Although there are certain well known problems with using Java on the client side (speed issues, GUI issues, etc...) the company where I am am doing some work at currently has had some great success doing work with Java servlets. We were able to take some code written and tested on WinNT and Solaris and get it up and running on a Linux box in less than two hours from the time we took a completely bare box, install the OS, and have the app up and running, with absolutely no changes to the code. I don't care how portable your ANSI C code is, but that is almost unheard of.
Now if only we had a spare IBM mainframe sitting around to try it under that environment...
DrLunch.com The site that tells you what's for lunch!
I guess not everybody has given up on client-side Java.
RP
I work at Webstakes.com ( http://www.webstakes.com ) - we're a very popular site, on the Media Metrix 500 and so forth...our entire operation runs on Apache JServ and we're very happy with it. We actually migrated from a Java-based application server and this is much better. I'm the UNIX system administrator, and in the past I have worked with many commercial application servers, from Broadvision to NetDynamics, and I have to say Apache JServ blows everything else away...I love how flexible Apache is and how JServ fits into it...it makes me wonder why so many financial companies have such a love for Netscape Enterprise server or IIS
Open source application servers are the best - I can tell you from personal experience over the past couple of years...they really blow away commercial application servers. My friend has mod_perl on Elance.com and I'm curious as to how that's working out...I know PERL is a very web-friendly language, maybe even a little more than Java.
A major part of the game in introducing any new
technology to the MIS-managers is producing a
panoply of success stories in the "trade press".
If you read back issues of "Information Week"
"Datamation" etc. you will find endless gushing
stories of successful implementations of
(pick the fad of the last 10 years).
What is *never* covered are the projects that
got abandoned, canceled, or crashed and burned
in some other way... these are politely buried
and not talked about... the programmers fired,
and the memory traces remain only in the minds
of the survivors - again never talked about, and
never included in survey tabulations...
The only way to find about project failures is to
talk to seasoned survivors over a beer, or
to read anti-patterns books or occasionally
the halloween issue of Datamation - and even
then they never give names and places...
Which is precisely why Sun is pulling stupid stunts like pulling Java out of ECMA stadardization and trying to charge royalties for the use of the J2EE logo. Sun realizes that Java is A Big Thing now, so they want to get their cut, one way or another.
It's the same old bait-n-switch we've grown to know and loathe from Microsoft, only with a different brand underneath.
These little shenanigans, along with the way Sun is milking the Open Source cow with their so-called SCSL and their treatment of the Blackdown fiasco has got them on my sh*t list but good. They had better realize pretty quickly that the industry isn't going to stand anymore for the same old tricks that Microsoft's been pulling all these years and that Sun isn't anywhere near as powerful and influential as Microsoft to be able to pull them off.
It's enough to want to make me give up Java and learn Perl... Well, ok, maybe Python...
Who woulda thunk it a couple of years ago that a die-hard Linux fan who does a lot of Java and database work would today be saying, "At least there's IBM to look to for real support of Java on Linux without trying to screw us over."
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
People who say that there are no Java apps miss the point. For the non-server applications, they're pretty much right: there are very few end-user, shrink-wrap apps written in Java. Why? Because portability is not an issue for most software companies. If it runs on Win95 and NT, then it's good to go.
However, a large number of server-side applications use Java servlets or the related JSP technology. Bought a computer on line? If it was from Compaq, HP, or a host of others (such as those listed at http://corporate.pcorder.com/customers/), then you benefited from the speed and robustness of the Java platform. Even the Ford e-commerce site, which Bill Gates so lovingly demonstrated in his Comdex keynote, is based on Java (and runs on NT).
And don't count corporate software, either. Lotus Notes web mail runs through a Java applet, and companies like Oracle are increasing their use of Java everyday.
The fact is, whenever you need fast development, good networking capabilites, and (I hate to say it) 'enterprise' support, Java is a good candidate. WORA is just a small part of it.
One last thing. With the advent of GCJ, it is possible that more native software will be written in Java. This will be a huge boon because it will allow GUI apps to run natively on a large numeber of platforms without changing a line of code. Java, I think, is a good argument for having a large, all-encompassing library (GUI, networking, database, ORB, etc). If only it was so easy with everything else...
~~~~~~~~~
auntfloyd
a sound card.
is your computer on?
My question is this:
Java is supposedly slow. Is this a matter of the speed of the computer? Will Java's ponderous pace become irrelevant as processors become faster? Is it something more inherent in the language???
hoser: Slashdot reader since 1987.
Here's how to properly install Linux:
Go to http://www.openbsd.org/ and order your 2.6 CD. Wait for it to arrive, pop it into your CD drive, set your PC to boot of the CD, reboot, and follow the incredibly easy install instructions, and *BAM*, you'll have a secure, powerful, functional system much cooler than Windows ever was. And those stickers kick ass, too.
3 hours, wow you did the quick install. You have to do the extended install (69 hrs) to get sound.
We are ZEALOTS, we don't need no stnking sound!!!!
Java is usable in the servlet arena, however Java has two things that cause people like me to choose other solutions (C/C++ is what I am using, perl is another good choice, as well as Python, and plenty of other tools which I forgot to name.)
The first problem with it is its lack of speed. On a server answering a ton of transactions, the JVM needs to have some sort of native machine code cache where Java bytecodes are stored as native code for sake of speed. What would make this a nonissue for servers would be a PCI card (preferably two models -- one 32-bit, one 64-bit wide, both able to select 33/66 Mhz depending on the main bus speed) with a good Java bytecode processor. If these were made inexpensive enough, and put on the motherboards on new SPARC boxes as coprocessers, this would solve the slowness problem.
The second problem is the bad perception of Java. Two big whammies -- Blackdown, and the pulling out of the standards committee hit Java quite close together.
Not to say that Java is a lost cause. When Java was the hot thing amongst computer groups, every vendor with something that runs a CPU got some sort of JVM out for it. So, the write-once, run anywhere thing does still apply. Java 1.0 was, for the most part, a toy, but with the latest iteration, it really has matured into something usable.
Personally, I really don't know as much as I should about Java, but I have seen some very cool things done with it (www.jars.com has a good amount of examples of this, and the main application that drives www.hushmail.com is another good example.) to write it off as a toy language.
As for Sun, its a mixed bag. They come up with some good things, and then trip on themselves. I don't want to write them off just yet.
Searching FRESHMEAT for JAVA returns 378 links, and they're almost all GPL. That's more impressive to me
anyway... I think the most impressive java app I've used is NetBeans (now owned by Sun). That was the first java app that made me really believe that significant java apps were on the way.
Here's a list of related topics I'd like more slashdot stories on:
ZOPE success stories
comparison of slashdot-alike web-based discussion apps like squishdot, etc.
compare and contrast of OPENSOURCE application servers
Who needs sound when you have 'THE VOICES' inside your head. They are all you need to hear.
Finally an article on the server-side successes of Java. IMHO, Java servlets are the best thing that has happened to Java since its inception, but for reasons completely unknown to me, Java-bashing has taken its place next to Microsoft bashing as an official Slashdot sport. Perhaps the reason is the early failure of Java when Sun touted it as the single platform that will replace everything. Anybody else remember the Java ring and the Java OS?
Dear fellow Java-basher Slashdotters: I know most of you have very little free time on your hands, but please set aside a couple of days to take a look at this exciting server side technology, Java servlets. It is truly write-once, run anywhere; it's a widely accepted industry standard, almost all popular databases and application servers support it, and Java is a very good OO language after all. Take a look at some nice servlet tutorials or better, O'Reilly's servlets book, download the awesome Tomcat or Apache JServ to run with your Apache Web server, get the latest JDK from Blackdown or even better, IBM's JDK, add Jikes for good measure, and explore the beautiful world of Java servlets. Sun's site completely relies on Java servlets, Yahoo uses servlets for some portions of the site, a host of smaller Web sites and e-commerce companies completely rely on servlets and/or JSP (which is based on servlet technology), (epinions.com, mercata.com come to my mind; there are lots of others)
Whatever server-side programming technology you're using, you will like servlets. Most likely you will want to forget about CGI.pm, sell your books about Netscape's proprietary server-side JavaScript on Ebay, erase memories of hours of fiddling with ISAPI/NSAPI extensions, shred your printouts of ASP error message explanations from the Microsoft knowledge base, and lament about the time you spent posting aimlessly on every bulletin board about those pesky, undocumented Oracle functions of PHP. You will easily have time for all these when you start to use servlets.
--
BluetoothCentral.com
A site for everything Bluetooth. Coming in January 2000.
Zigbee Central: A Zigbee weblog
I developed and wrote WebMacro which is a free (GPL) Java servlet framework.
I use Java for about half my web projects. The other half of the time I use perl. In my opinion, here are the strengths of Java for server side development:
1-- It allows clean and clear design. Since you can declare compiler-enforced interfaces, you can easily separate out functionality in well defined chunks. This allows you to plan for the long term, hand different parts of the project to different people, and so on. This tends to be what makes me choose Java over Perl: If I want to enforce a long term design (such as re-usable constraints on busisness logic), or break the project up into several different segments, then I choose Java over Perl.
2-- It's fast and scalable. Java is often criticized as being slow, but on the server, it's not. It's fairly fast compared to things like perl (which are usually fast enough to begin with), and add to that the threaded nature of servlets, plus the built in scalability, and you have a big performance gain over other scripted solutions. In particular the ability to automatically distribute a single servlet across multiple webservers, without modifying the servlet itself at all, is a big win. You can be sure that whatever you do will scale.
3-- You do need to make an effort to keep your HTML and your SQL and your Java program code separate form one another. The whole reason for using Java was to get clean, well designed code, and you don't have that when you have HTML obscuring your servlet. This is what prompted me to write WebMacro, which is an HTML template system, but you could also do this with FreeMarker, or XSLT, or if you are very careful, with JSP.
4-- Write once, run anywhere is fairly real on the servlet. I routinely develop under FreeBSD, deploy on FreeBSD, Solaris, and Linux, and I have about half the users of WebMacro running it under NT, even though I myself hardly ever use NT. And it all works.
5-- On the downside, the free Java solutions don't appear to work very well for servlets. I have had lots of trouble with kaffe, and the free JVM's are not as fast as the non-open ones. This is too bad, and it's something I expect will change over the next while. I always try kaffe every time it comes out, but it hasn't yet been stable enough for me.
6-- You do need an experienced designer around if you are going to use Java. Unlike perl, where your goal is to hack out something working ASAP, in Java the point of the language is to allow you to do clean design. Well you won't get clean design without an experienced designer. Without a good designer you are probably better off with "write-once" perl-code that you throw out and rewrite whenever you need to fix it. While Java allows you to do really good design, I have seen some really nasty Java code. If you aren't going to use it right.. don't use it.
I also got to do some server side Java. It is fast and works great. Using JSP's is much better than ASP's because of the language -- Java is a full language while the ASP stuff is for scripting. VB is just full of inconsistant syntax. Furthermore, the Java Servlet API is very well done. There are a few things that ASPs make difficult to code and JSPs make almost trivial, like a file upload over HTTP (I don't why they were insistant about not using FTP).
Java has other nice & cool things, too, like the communications API. It works with serial and parallel ports. Like most Java API's it is very well written an easy to use.
For a poorly done Java API, look at the InfoBus. It sucks! I made a better one, but its more basic in function (part of the reason I think its better). Its on my web page, if you're interested. I call it the dataBus. All free with LGPL, of course.
"Luncheon meats make the sawdust in your stomach explode."
i've done some work with jserv and servlets and it is likely the best way to handle database requests over the net, now how do you hook up mm.mysql to StarOIffice jdbc thing. this could be real usefull to me
I mean does people change OS of their web server that often? Why would people need that feature?
Apart from that, what is the advantage of Java over more traditionnal languages like Perl or PHP? What is that craziness all about?
Je t'aime Stéphanie
and god forbid you want to keep a legacy windows partition. Then you get to wrestle with disklabels and bizzare fdisks. I think Corel's Linux is probably the best choice for newbies, OpenBSD is most certainly not, despite being an excellent system.
And the stickers really do kick ass.
Why?
0x or or snor perron?!
Somebody should add Enhydra to the list (I would, but I don't remember my login information for the JavaLobby). Enhydra is a very rockin' application server written in Java. It's open source too, which is always a plus.
-----
Free P2P Backup, Windows & Linux
!!
Why not.
The company I work for recently programmed an SMS (cellular phone text-messages) server complete with a fancy web based user interface and a vCal integration that allows you to synchronize your cellular phone calendar with your desktop calendar automatically with SMS's as the carrier protocol. One team had worked on this for months and months using C/C++ and Perl. The deadline came closer and the app was still packed with bugs. So a hail-Mary manouver was performed only days before the deployment date and the whole thing was re-engineered in Java with parts of the vCal integration being Visual Basic. On the deployment date, we had a ready package which was actually FAR better than the C/C++ & Perl version. It had more features, was more easily integratable with other systems, featured a pluggable SMSC (short message system center) driver architecture, had a fancy self-repairing system which did self-monitoring of the whole thing. We had a home-brew RMI based distributed debugging service that allowed us to receive stack-traces and exceptions that occured at run time, from several servers at once and view them on the web. We had about a million other equally cool things, all put together in less than one week by a handful of programmers.
A few weeks later, there are still no major bugs reported and everything seems to be running perfectly smoothly.
What does this prove? Absolute nothing. However, it does raise some questions about how it's idiotic to just do everything with C/C++ because it's traditionally "the right thing to do". By using "traditional" programming languages, you will often be forced to spend so much time thinking about language issues, memory allocation & leaks, complex threading issues etc. that the application logic will suffer and become a secondary priority.
Pick the right tool for the right job. If you develop a web browser, you would probably be insane if you did it in Java (I would love to be proved wrong) because it would be so much slower. If you develop a complex server side application in C/C++ or Perl, you're nuts because there's NO WAY you will achieve the same quality in the amount of time you can achieve it in Java.
If you diss Java because of some stupid web applets programmed by some 13 year olds who know nothing about programming, it's just very sad because Java can do so much more. Unfortunately we see lots of "write once debug everywhere" statements by people who have little or no first hand experience with Java. The experience I have with Java tells me that while the Win32 platform still has the best virtual machines, Linux is gaining FAST, mostly thanks to IBM. Linux users: don't just use Kaffe because you've heard it's the right thing. Try running Java on a Win32 platform so you see what it CAN be like. I'm quite sure you will be amazed of the speed.
There are not many platform inconsistencies left, and if you know what you're doing, you can easily move a Java app from one platform to another without having to change any code or recompile anything. I've done this several times, even for very large and complex applications.
If you read the Java 2 Enterprise Edition Application Programming Model specification which now has an even more complex name which escapes me at the moment, you will see how SUN has worked hard in the EJB specification to define a great component architecture that is scalable, clusterable and avoids many common causes for platform specific bugs. Please read it!
A friend and I have just released a Java application. We use encryption to password protect web pages securely (plug: www.guardbot.com). The software comes in 2 parts, a Java applet decoder which performs the on-the-fly decryption of web pages, and a Java encoder which performs the encryption.
Without the Java's write once run anywhere capability, the decoder would have been impossible to deliver succesfully (without resorting to platform specific browser plugins, which would have put off a lot of users). Writing the encoder portion of the software let us deliver the software simultaneously to any Java supporting platform - without Java, we would probably have limited our software to Windows (at least initially).
Client side Java is not worthless, and I'd say that write once run anywhere is an extremely worthwhile goal - I'd very much like to see Sun deliver on this. As it stands, only Solaris and Windows have working Java 2 implementations, which is extremely disappointing.
- 300 AMD K6
- 128M RAM
- IDE HDD
and running- blackdown jdk 1.1.7
- Apache + JServ
- Webmacro
- MySQL
I was getting a maximum sustainable hit-rate of 25/second with a complete data output of around 250-300 K/s. Considering the low-end spec of the machine, the fact that all the components are running on a single machine and that there are now considerably faster JVM's floating around, I reckon that it should be relatively easy to double this speed without much investment. Either way it is still definately up in the usable range.Interesting, but irrelevant fact: On profiling the servlets I found that the major time overhead for the complete process was in the jdbc driver (mmmysql) when it was converting byte[] --> String. Memory allocation. Booo. Anyone done any work on getting a mysql/jdbc/webmacro integration that: caches used data buffers and reuses them if possible in the jdbc driver and/or permits direct use of data[] blocks into webmacro without the String overhead?
The only Good System is a Sound System
The parts of Java that are slowest, from my experiance, are:
- GUI
- Object creation
- Poor programming
And yes, as computers get faster Java's speed will be less relavent. But that is true of anything. You probably don't care how long it takes for your email client to do anything, nor do you care how long your computer takes to deal with number crunching for your undergraduate college classes. That is because your computer can do these things so fast that you don't wait long, if at all. Thus, if those actions became twice as fast, you probably wouldn't care becasue you wouldn't notice.It still needs work, and I'm not sure that JFC will improve it much. Java software that doesn't use a GUI usually isn't very slow.
Making a new object takes time. A bit much time. Minimize usage of the new operatator to maximize performance.
Admit it -- this is the cause of most problems for almost anything.
"Luncheon meats make the sawdust in your stomach explode."
99% of all the posts are concerning corporate projects and every business I've ever seen is doing all their work in Java/Corba so you can satisfy yourself that Java/Corba is required if you want to be employed. At the same time in the non-business world, take a look at Freshmeat and you'll see almost everything done in C and Python. So we have the corporate world using Java almost strictly and the private world using C. Why is the corporate world so allied with Java and the private world so focused on C?
...except for all your hardware that BSDers decided was unworth of support. (Though they're finally improving, having grudgingly admitted a distro that runs would be handy.)
Can someone comment on Corel Java WP and Lotus Java eSuite?
Most things aren't ready till then. And Java looks like that too. It was changing like crazy in 1.0. It's only just stabilised with 1.2 (and they dare call it Java 2).
What can you do with server side Java which Python , Perl, PHP can't?
How easy is it to split a string in Java? e.g. array=split ,
As far as I know, Java still lags behind. Don't see much point in enduring the pain dealing with a adolescent solution yet.
Plus, another thing - when a colleague was looking at Java for database and web stuff, what put him off was every other step was "pay pay pay". e.g. database connectivity, which you can get free for Perl, Python, PHP etc. He's now doing his stuff on Perl.
I prefer spending time actually doing stuff, rather than looking for tools, or filling out forms to buy tools. And I prefer not to have to make my own nuts and bolts, or look all over the place for decent ones.
Cheerio,
Link.
I've done a bit of Java programming myself, and I sure can't say that it strikes me as particularly fast in terms of development time. Perhaps for something relatively large it's faster than C. But I have never found an app which can be more quickly developed in Java than it could with say... Perl. Java is so strongly typed that it takes forever to parse data (which is a big deal for making web content draw from databases). Also, I've found that not only C, but even purely interpreted languages such as Sed or Perl yield better execution speeds as well.
Don't take my word for it, though. In Kernigan and Pike's classic, The Practice of Programming (C 1999), there's a pretty decent comparison. In the design and implimentation chapter they implement a Markov Chain algorithm as a decent test of perfomance/speed of development comparison between several languages. Here are the results:
PentiumII400MHz ----- Lines of source code
C ----- 0.30sec --------------- 150
Java --- 9.2 ------------------ 105
C++ --- 1.5 ------------------- 70
Awk ---2.1 ------------------- 20
Perl --- 1.0 ------------------- 18
Looking at the results above, Java doesn't look like much of a winner at anything. It comes in dead last in execution speed, and edges out only C (the performance winner) in development speed (based upon lines of code). Perl on the other hand, is a contender. As I see it, Java's only true strength is its propaganda machine.
I'm a gnu world man.
Because Java is not Open Source you can only run the servlet on whatever platform sun deems you to have. So even if you had a JVM that could with a recompile run on any of the Linux hardware platforms, tough because Sun deem that Linux is x86 and nothing more.
As for those of you that say making Java a GPL product would fork it to death, then why has this not happened for example with the Linux kernel? Think about it. If Java was GPL it might have been using CORBA from the start instead of RMI and it might bind to OpenGL instead of it's own Java3D. In fact you might have Open OS's intigrating Java into themselves in such a way that the VM becomes part of the kernel.
A GPL Java with Sun acting as it's Linus would probably be more in goal with the actual language design criteria than it's closed source form is now. There are many platforms which would be excellent for servlets, which could have become the glue for exchanging data from platform to platform but unfortunatly this is not the case right now as the limited JVM ports impeed this.
"Because we are not employing at entry level, offshoring will kill our industry stone dead."
Now, the Linux guys are stingy, because Java was never a big thing on Linux, no vendor would support it! The pure-C guys are stingy, because they would rather toil over hours of code in order to be one level above direct control of the machine.
And furthermore, Sun is doing great making Java as proprietary as possible. Sun has the speed, and enough hatred of Microsoft, to keep pushing Java to become a very full-featured platform, and even maintain their write-once-run-anywhere promise. A standards body is the death of any technology, because they're slow! Sun ofcourse has the perfect model for letting Java grow, it controls how, everybody else suggests... Consumers demand, Sun listens and decides.
I don't think that I will ever go back to anything else. I -love- JSP/Servletes. I have been able to increase my development time significantly and the performance is not (in my perception) lower than Perl or PHP.
Oracle has made a HUGE commitment to the java world with its Oracle8i server and Java Stored Procedure integration. (Hell of a lot better than PL/SQL!!).
With big players like IBM/Oracle pushing the backend, I would hardly say that Java is DEAD. Even if sun doesn't release the API to a standards commitie, someone will standardize it. I don't *fully* understand the problem with sun being a steward over the API _for now_?
I agree that what they did to Blackdown was a bit lame, but welcome to the corporate world.
In the end, I can use Tomcat or Jrun (at no cost) and it allows me to do my job quickly and very low cost. I am working on a large and complex side project, and right now the development machine is sitting on a Compaq Pentium 90 with 96 megs of ram. After the JSP Pages are compiled and sitting in Ram, the thing goes surprisingly zippy.
If performance is an upper end issue, you can load balance the application server in a cluster.
You can start development on a compaq pentium 90 running linux, and move it to a 64 cpu SGI machine if that tickles your fancy!
I believe that Java offers the most flexible solution for my needs, but I do have a choice. I don't understand the Java bashing on Slashdot, I really enjoy the stability and managability that it gives me.
I think java on the server is so successful in Unix land because it solves a serious flaw in OS design: the availability of Binairy Objects on OS level. When you build an e-commerce system you can choose between (besides the HTML :)): a) writing it all in C/C++ or other binairy compiling language (not many do that) b)a scripting language or c)Java. Choosing a) has the drawback that however you probably can use objects within C++ or object pascal, it's hard to share these objects between pages in your e-commerce system. Choosing the scripting language gives you the sharable objects (if you use PHP for example) but these objects are living in an interpreted language environment. When your system needs speed because of the high load, it's not that recommended. Choosing Java on the server brings you an optimized binairy world, with binairy objects using CORBA. Because of the usage of a JIT it's faster than scripting languages plus the binairy objects available with CORBA bring more advantages than the scripting languages do: the sharable objects are binairy and optimized for execution by the JIT. Advantages, it's hard to say, people at NT with IIS are having for years: binairy, speedy COM objects used in ASP scripts on the server. Java on the server bridges this gap, but only with CORBA.
Never underestimate the relief of true separation of Religion and State.
i wonder what would happen if somebody tried to catalog all of the C success stories on the javalobby sight? probably crash the thing :P...
i'm getting a bit sick of all this deer-in-the-headlights hype over java. first java was the great applet language. once that failed, people took the write-once run-anywhere philosophy and decided that java was going to take over the client. now that java has been proved fairly useless on the client (how many applications that we use are written in java?), people start the java-on-the-server (?!) bandwagon. *please*, if we are running it on a *server* we know the architecture, we can use something called a "compiler" (btw, C code compiles on a hell of a lot more platforms than java ever will). if we are writing a server app, we better know when the memory gets allocated and freed, and we better have good design and methodology. java will never replace good engineering and sound design. give me my faster C / C++ / Perl / Python "servlets" anyday over Sun's proprietary hyped java garbage.
3% branding fee anyone?
Let me know how many lines of code that takes you.
Or in C. Add a third column called "Core dumps".
I'd love to have a go with this, though I don't know if Kaffe/Classpath/Apache currently does it. Have you had a play with Apache's mod_perl, though? That's the technology that drives Slashdot itself - integration of a Perl interpreter with the webserver, that allows damn fine perfomance and scads of flexibility.
--
Xenu loves you!
It looks to me like he made a pretty clear argument... even if he can't spell 'implement' the same way twice. ;)
I've seen the implementations of the Markov Chains, too. What's your bitch with them? Both C and Perl have been used for much larger "multi-threaded, distributed pieces of code." Perl still beats Java hands down in both areas (though Java's execution time has improved 2%-3% since the writing of The Practice of Programming). C of course cleans up in execution speed, but is hell to develop. But what in the name of all things rational are you talking about with a column for core dumps!? Kernigan and Pike write better code than that. The core dumps column would just be 0's.
Are you implying that C and Perl are useless for anything big? Why do you have to make an inflamitory post just because you don't like what you hear!!? You're argument's senseless, you're a dickhead, and you're wrong!!!
Perl's socket implementation is crap. It's doesn't recover very well from network interruptions.
C, while extremely fast, is a bear to code threads and tedious for networking.
Don't get me wrong. I love perl. At my last job, that's about all I used for projects large and small.
Now I'm doing tons of disributed multithreaded code. Java has really cut down on dev time.
Okay. Go ahead and call me some more names. It makes your posts more convincing.
Didn't microsoft and symantec each create one for win32? I heard that there is going to be a gnu one in the future. Java would gain more respect if the JVM would give the user the option to compile to native code so it runs almost like a native app the next go around
Let's look at any discussion of frames, graphics, the Opera Browser, or other aspect of web design. People code for their perceived top 95% (Netscape & IE 5.0+ running on Windows). We're used to everyone who uses Opera, Linus, Mac, or NoFrames just getting the shaft. We don't like and and we protest, but we are no longer surprised.
Java is only accepted as a serious application choice when there is a need to run on more (not all) machine types. (Let's be real, if you claim Java is viewed by everyone you've just screwed over those Lynx users on dumb terminals. They're still out there.)
With the new processors coming out (Alpha vs Intel) it will be interesting to see if the compiler market supports both processors equally. If they do not it will either mean a death for one of the processors or an increased demand for Java.
Currently, in my opinion, the forgotten market of choice would be education. Since schools and universities tend to have a wide spectrum of machine types available and since speed is not normally a factor in educational software, then Java fit's the bill perfectly.
Currently I'm working on two alife (artificial life) applets. Java is fast enough for alife (where speed is desireable) on Windows and portable enough that I can be sure other people will be able to use and study these applets. If I was to do this work in C, it would make a decent thesis, but it would be limited to people who A: like to download unknown .exe files, and b: like to read college papers. (Wait. that would be nobody...)
No Zen is good zen
I suppose the only meaningful comparisons would be those that speak the glory of java hmm?
My companies servlets run mostly without incident on both Solaris and Windows. We mostly run into problem with JDK classes that make native calls. Often one will work properly on Windows but not on Solaris. I have been told that weird as it sounds the reference JVM is developed on NT so the work to port it to Solaris introduces bugs. You think they would develop on Solaris.
This guy makes a decent point, but geez! Not only does he personally attack one guy but he even has to nit-pick at the spelling of the one he's defending. Sigh. Free speech is ugly sometimes.
It that it is easier to hide sloppy algorithms in C. Not that I have anything against C.
-- Make 7 - Up Yours
gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70
Actually Java support has extended past just solaris and Windows. Sun has released the JDK1.2.2 for Linux, get it here! And when you're done, snag the new JBuilder Foundation! They're both really stable, and really good. I've benchmarked a chess program on them, and it's comperable with the Windows version. The compiled code is identical, Jbuilder has all the same features, and the JRE is actually executing about 5% faster than it does when I boot to Windows. Not that it's particularly fast compared to native binaries... but still it's good to see.
-enjoy!
I'm a gnu world man.
I've worked extensively in C, C++, and Java. Given my choice I will take Java virtually every time.
The reason why comes down to pure productivity. On average (we're talking about over the course of years) I'm 300% more productive in Java than C++. In some cases (particularly networking code) that number is more like 1500%.
Just think of what things you can do if you can write your application three or more times as fast as the other guy. You have time to write it, rewrite it, and optimize it before he's even done the first time.
And that, my friends, translates into huge market advantage.
Now, lots of people say that the reason Java is more productive is because you don't spend your time tracking down memory issues. That's not the case for me, at least not in large part; it's really not that hard to write a clean program in C++, and memory leak issues still exist in Java (which sells a lot of Optimize-It licenses, lemme tell you). Rather, Java is a lot more stringent in enforcing interfaces than is C++, to say nothing of C.
Consider, for instance, that Java enforces handling or passing of exceptions. In C++ you can silently ignore them, usually resulting in bugs or reliability problems that don't show up until late in the development cycle (or, worse, in the field). In Java you have to explicitly deal with exceptions; you are forced to make a conscious decision as to what to do every time you use an interface that throws an exception. What that means In The Real World is much more robust code on the first effort -- if it fails, it usually fails gracefully.
There are actually some problems related to this. In beta test programs, for instance, it is a lot harder to get people to report problems because they usually manifest themselves as a feature that doesn't always seem to work rather than a complete application crash. On the other hand the application can notice the problem and report it nicely rather than just disappearing or dumping core. These kinds of problems I can live with.
There are other development advantages. Java is dynamically linked at runtime. This makes it slower to start up than a C or C++ application but it means that there is no link phase to deal with at each compile/edit/debug cycle. On a large C++ project I used to wait as much as fifteen minutes per link; with Java that time is always zero. That translates into many more cycles in the same timeframe, and that translates into product going out the door faster. (I must note that I used to work on a C/C++ debugger with an incremental linker and it had many of these same advantages. It was, however, rather expensive.)
So: we have a case here were random heap crashes can't happen, where interface enforcement is stringent enough that you get more reliable stuff together on the first try, and where you can run through a compile/edit/debug cycle a lot faster. There is a hell of a lot to like there.
There are some downsides though.
The compilers still suck -- at least all of the common ones. Oh, projects like Jikes are yielding compilers that build code fast, but none of them build good code. They don't even do simple peephole optimizations, to say nothing of what you get in your typical C++ compiler. It's like going back and looking at code produced by 70s C compilers. Apparently the idea is that the JIT system takes care of that -- but JIT systems are severely limited in how much time they can spend compiling the code, plus they don't have anywhere near as much semantic information. The end result is worse code. This was true of C++ for quite some time too, of course, and is expected to get better, but for the moment you get to optimize a lot of things by hand.
JVM stability has been something of an issue. Big programs that push the environment hard (like, say, a web application that's handling tens of millions of hits per day, which is what I do with Java) tend to find the dirty corners that don't show up in your typical "hello world" applet. Things like limitations on the number of classes and methods you can have in your application (low tens of thousands prior to JDK 1.2), heap lock contention overhead as the thread count scales beyond a hundred or so, and other things have pushed us towards designs that are less convenient to build (although arguably much more scalable and fault tolerant).
Some people speak of JDBC being really nice. It's a good idea, but practically speaking very few of the JDBC drivers are particularly reliable, cross-compatibility leaves a lot to be desired, and performance is often not so hot. You have to spend more time on optimization. Luckily you have more time to spend on optimization.
So Java has its problems, but in my experience everything has its problems. Java's problems can be worked around with architecture and optimization and productivity improvements are so good that you have the time to do it. The end result is often a better product out the door faster.
Now, for all you guys who say that Java just isn't fast enough, several of the largest sites on the web run Java-based applications (you almost certainly have used some of them without even knowing it). And they do it on a lot less hardware, and less expensive hardware, than any of the competition manages with C/C++. This is in direct contract to the popular opinion that Java is slow.
There's nothing stopping someone from writing the same kind of thing in C/C++ other than time. We've had the time to write, optimize, rewrite, and optimize again several times over in the time span it has taken most of the competition to just make their product stable. Unsurprisingly this results in a faster and more stable product even when we've had to work around problems that the other guy wouldn't have had to deal with.
Java isn't for everything. You'd be insane to write drivers or operating systems in it, and runtime environments are really way too big for most embedded applications today. But when it works it's great, and it is working on a whole lot of servers out there on the 'net. You don't hear about them because nobody talks about the stuff that works, only the stuff that doesn't (like, say, eBay).
jim frost
jimf@frostbytes.com
jim frost
jimf@frostbytes.com
Well, first of all Smalltalk should not be
:))) How much of the best will java
written with capitalil `T'.
Second, Java has nothing to do to Smalltalk. The differences are very important not to be confused:
1. Smalltalk uses symbols and this makes it very
close to Lisp and Scheme.
2. Smalltalk calls methods my their `name', not their index in some kind of method tables.
This also makes it closer to Scheme and Lisp,
and also to Objective C. Well Objective C was
made after Smalltalk.
3. Smalltalk resolves types at runtime. Again, like Lisp, Scheme and Objective C (I mean,
object part of Objective C)
4. Smalltalk uses REAL CLOSURES. This is very rare
feature. I know only Scheme supports them
truly. Nevetherless, Java do not support them
So, I would change word SmallTalk in your message
to C++
have after that? HAHA
Anyway, I suppose my point is that Netscape made applets way less pretty than they should have been, and I hope Mozilla's default setup does better. (I'm quite the Mozilla hopeful, actually.)
Well I haven't seen anything for which Java can run within that factor of C++'s speed. Actually the C++ implementations (for that specific benchmark) have improved more than the Java ones! Java made great strides between version 1.1 and 1.2, and I'm sure it's compilers will continue to improve for much longer than C++. But I doubt it will ever catch up. If you do know of anything for which Java gets even 1/3 of C's performance, I'd be interested to see. Everything I've ever seen has been painfully slower, even simple networking things like ICQ! Have you seen how sluggish the java version is? It's unusable on my PII-300!
Here are my guesses as to what makes Java so much slower:
First off, there's quite a bit more overhead- we all knew that.
Second, the compilers have a bit tougher task, and they aren't as mature.
Third, Java is interpreted. You compile it, but just as with say... Perl, you need an interpreter.
Now the fourth reason I've thought of took a bit more digging. I've found that the performance of Java gets much closer to that of a lower level language when its apps are run on a system with a huge cache. Why? I'd bet that with everything done in OO, the inheritance is thrashing the ever living hell out of the cache. For every "generation" of inheritance, that's one more jump to an arbitrarily far spot in memory. That's actually the same problem that has kept game developers from using C++ for playstation games. C++ doesn't have nearly the problem that Java has with this, but the PSX only has a 4k cache! Perhaps as our computers become an order of magnitude more capable, this problem will abate somewhat.
As for lines of code being a poor measure of development speed, I agree. However, in my own personal experience (working on a BIG web based system for an ISP's billing software) most things can be developed more quickly with Perl. It seemed pretty cryptic for a while, but I don't think that it's that much less readable once you're familiar with the common idioms for whatever task is being done (it seems they're always similar). I guess the main difficulty with Perl might be that you can choose to make unmaintainable code, ie don't #use strict, etc... Right now Apache/Mod Perl/CGI/Oracle seems to be working pretty well, but who knows? Java servlets are certainly much more appealing than Perl would be were it not for Mod Perl. But I think it'll be a long time before C/C++ is no longer rules the realms of gaming, and operating systems.
I'm a gnu world man.
You said you expected java would be at least 2 or 3 x slower than C++. It only came out about 4 times slower. Why does that make you suspicious?
Wow, I've helped set up from scratch a system with FreeBSD, Apache, Perl, Java, JServ, GNUJSP, PostgreSQL, JOnAS, and Cocoon.
In terms of Java, that means a Java VM, a servlet engine, a JSP engine, database connectivity, XSL processing, and even Enterprise JavaBeans.
And I paid $0 out of pocket.
Java is just like any other tool out there on the market. You have to look at its merits and its flaws and decide wether it fits into the solution you are trying to provide. Granted Sun has touted that Java is the end all be all for programming which it is not.
As for its use as a server-side scripting language, I think it is a very powerful tool. I've been doing e-commerce applications for almost 3 years now. Perl is awesome. Personally, I find the variety of libraries and regex capabilities that come with it make the task of designing web applications extremely easy. The problem that I have found is that Perl is loosely structured (which does have its benefits) and as applications get really big the language can become difficult to work with as you add more and more features to your applications. Java, as far as a language goes, is very structured and IMO very solid in design (remember I'm talking language not AWT + Swing, et. al. libraries) Not to mention the added capabilities that are built into the servlet interface like the session management coupled with things like JDBC (yes, I know you can do the same with Perl DBI lib's) and the GNU regex library and you have a pretty solid e-commerce application development tool.
Drawbacks (for some) are that to run servlets you need to be running Apache JServ, Sun's JavaWebServer (bad idea), or Netscape Commerce server. I don't think there are any others, but if somebody knows different, please enlighten me.
But as I stated at the top, servlets aren't the solution for everyone, see if it fits what you are doing and if it doesn't find an alternative, don't necessarilly label the product as crap.
I have been to SOOO many pages where I get the happy little window that says, "Error: X is undefined" or some other JAVA-based error. Does anyone else get bothered by this? What is to be done? guaranteed no JAVA errors.
...being as I'm spending my entire Christmas-New Year break beginning to learn it.
The only thing I like about Java, is the incredibly nice Swing widgets. Every time I look at the SwingSet demo, I fall in love with them. Unfortunately, they are so slow.
Further, I resent the rest of the Java language. Slow like Basic and as complex as C++, it combines every reason not to use it.
Nonetheless, there should be a way to save the Swing set out of the Java cesspool. Does anybody know of a way to use the Swing widgets with python?
WTF are you talking about?
Yes, Andover acquired Slashdot, but where have you seen them barring links exiting the site? THAT'S WHAT THE WHOLE FREAKING SITE **IS**. Have the story links gone away? Have the Slashboxes gone away?
Besides, what does Andover care whether you use the Slash system or not? As for Slash being closed-source, I think that's a it unfair. CmdrTaco is lazy:
Someday I'll post a new version, but honestly its a lower priority to me than it ought to be.
I'm to busy ironing out kinks and adding features to take a couple days and create a distributable tar ball. It'll happen, but
not tomorrow. I'm already working pretty much every waking second of the day.
But SlashDot is neither completely closed source nor open source. ANd I think that's because it's tough running a site like this and running a collaborative open source project all at once.
I'm just sick and tired of people slamming companies who make money.
If you develop a web browser, you would probably be insane if you did it in Java (I would love to be proved wrong) because it would be so much slower.
;-)) and there is constant flickering when pages are rendered. If they could remove that... The pages I visit most often look good.
Well, there is HotJava, a web browser developed by Sun completely in Java (1.1). Get it here.
However, I never got it to run as non-admin under NT (but I don't really care
In my current contract capacity, we use Java exclusively in the middle tier. From database access to the translation of EDI to XML, we use Java and CORBA. My project brings in MILLIONS of $$$$$$$$. We have a budget in the 10-MILLION $ range. And we use Java. We are a SUCCESS. Most of the developers are mainframers converted to Java programmers and they have produced excellent code. Some growing problems, of course, like threading etc, but overall Java is an easy language to pick up and learn. Myself I come from C++ and C and Perl and LOVE JAVA more than any of the previous languages.
Those that claim java is dead or can't scale or isn't successful are just talking out of the close-minded ass.
Always worked pretty well for me under Solaris. I especially liked the little colored "threads" that showed the multiple connections: if a data connection was still open, I would wait, but once enough of the page was loaded that all the remaining connections were the "image" color, then I could safely click "Stop". No bigass images sucking down my bandwidth, and I know that all the HTML/Java/Javascript/etc has arrived.
I gave it up because it can't do forms and pop-up boxes worth CRAP -- even when communicating with Sun's own site to download security reports! As a Sun sysadmin, I
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
My gripe about Java isn't speed. It isn't the platform. These are implementation details.
My gripe about Java is that the language is *awkward*. It has all the B&D of C++. For a *really* large project this might be of use, but for my money I'll take consensus over language limitations every time.
Python strikes me as the current best of breed for general purpose programming languages. It has the necessary features for writing both large and small apps in a *very* unobtrusive package. The language just plain gets the hell out of your way and lets you get on with solving the problem.
It also seems to be near the top for WORA. I've written apps that run unchanged on Linux, Win95/98/NT, Solaris and AIX.
The only issue is WORA GUI, and I don't think that problem has been solved for *any* language yet. Tk comes close, though, and Python's interface to Tk rocks.
If Java would just get the hell out of my way it wouldn't be so bad.
--
If your map and the terrain differ,
trust the terrain.
Pick the right tool for the right job.
I agree completely! I beat my co-developers over the head with this saying all the time. But...
If you develop a web browser, you would probably be insane if you did it in Java (I would love to be proved wrong) because it would be so much slower. If you develop a complex server side application in C/C++ or Perl, you're nuts because there's NO WAY you will achieve the same quality in the amount of time you can achieve it in Java.
This is kind of funny...
My approach is to use, say, C++ as the server-side language, because of the richer feature space and the quality of code. I use Java as the client-side GUI because it's trivial to build GUIs in Java, and because the code speed is not as important -- most of the time the human is still the slowest thing in the loop.
I should add, however, that I don't use Java to write web applets (it's not that I use other languages for that, it's that I don't write web applets at all). I use Java to generate a complete GUI application, and then use an ahead-of-time compiler to create optimized binaries for the platforms that I know are going to use it. (See, for example, Per Bothner's paper on treating Java as just another language.)
This just goes to show how programmers can have exactly opposing views, and both be right. :-)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Ironically, I found this article today that discusses Java from a, uhm, different perspective ;)
And if the Win32 performance still doesn't impress you and you want to see the most extreme case, run your Java app under OS/2.
"java is slow" Not really. Downloading an applet into possibly the worst JVM (Netscape's) is slow. Try using a network platform like Speiros (www.cyrusintersoft.com) to run your client side java. Your opinion will probably change. (and you'll probably be really pissed at netscape for ruining everyones perception of java) "Java is only good for Server side applications (servlets)" Again, I disagree. I've been working with hundreds of java applications (and applets) from many sources (commercial, GPL, private), and have found that in nearly all cases, slowness results from bad code, not "java" or the jvm. I don't mean that there are bad coders, simply that many java programmers have really never had any decent guidance how to code properly with JAVA. That is Sun's fault IMHO. "WORA is limited to servlets" Client side java is very alive and well, and despite many developers lack of multi-platform development experience, JAVA itself is the ultimate for great client side portability. For example I run the same editor (Jedit) on 3 platforms: Solaris, NT, Linux (RH6.1) using Speiros as the delivery vehicle. In addition to Jedit, I also have a spreadsheet, FTP, IRC, SSH, MAIL, and a handful of other useful tools. None of these applications suffer from the maladys that JAVA proportedly inflicts. Many of the problems that people find with JAVA are simply a result of Sun's mishandling of the platform. Why do people think that servlets are the only success with Java? Simple. That's how people are making money off Java today, including Sun. To see what else is possible check out: http://www.GJT.org http://www.cyrusintersoft.com
There are other, productive, yet FREE programming languages out there. Take the platform independent MOZART for example: www.mozart-oz.org Mozart-OZ is the most powerful high level programming language around. Of course, it is also the youngest.
http://www.re search.digital.com/SRC/mercator/papers/Java99/fina l.html
I recently ported a Perl based Order Manager server app, consisting of 2.7k LOC, from a UNIX to a win98 machine.
I installed Apache on the Win98 machine and several required modules such as Time::HiRes, and CGI.pm. Then changed 3 hardcoded url statements in the code and replaced the #!/usr/local/perl to #!c:/tools/perl in each file and was done.
That's pretty close to WORA IMHO.
talk to your local VB programmer to see what life is like when your tools are closed.
You get the best of both worlds - write your WORA code in Python!
I -love- JSP/Servletes. I have been able to increase my development time significantly and the performance is not (in my perception) lower than Perl or PHP.
So Java Servlets are responsible for the increase in your development time?
cpeterso
If you redesign ANY existing system (completed or not) from scratch you have the benefit of seeing and improving upon the deficiencies of the previous system. Often Java is the language of the system re-write, and gets undue credit for being a superior language as result. The same system could have been rewritten in virtually any language and you would realize the same benefits, having already narrowing down and refining the requirements of the (often unsuccessful) first iteration. Try to keep things in perspective. These server-side projects are using Java in the same fashion as any other conventional language. If the truth be told, whether it is compiled, interpreted or JITted, no-one really cares as long as it acheives the desired goal. To try to suggest that Java makes people think more clearly is silly. If the programmer did not have the discipline in the first place, the program will fail in any event.
For maximum portability. Not all platforms (especially memory-constrained environments) support Java. In C you have no such constraints - legal, ethical or programmatic.
One of the reasons that some ASP users are changing to JSP is so they'll have more flexibility in deployment servers (performance is also better). It's hell to be stuck with NT. For example, Cobalt RaQs running Linux are very nice at the low end. Or if you really need to go with the big iron, you can buy a big Sun box.
So, really, Java and JSP/Servlets are helping migrate users from closed NT shops to using Linux on the server side.
Scott Ferguson
Scott Ferguson
Caucho Technology
On winNT/IIS we use JRun and have great success. On Linux, apache Jserv rocks (they're upcoming XML-Java stuff is very exciting).
"There's so much left to know/ and I'm on the road to find out." -Cat Stevens
So the kid goes to college learns an algorythm or two and benches it...
.edu domain, you would know that for distributed apps that include the network the latency of calls so that a few milliseconds here and a few milliseconds there I DON"T CARE!!! I AM NOT WRITING GAMES!!!!!!!!!!!!!!!!!!!!!
.edu friend, The "only true strength of Java" is the MASSIVE collection of high level APIs that enable me to do web programming as fast as I can (and trust me I am probably a better C++/java programmer than you will ever be). Only only language talks distributed objects as seemlessly as java... gimme RMI/ gimme CORBA/java components GIMME EJB!!!!!! stop looking at what your grandfather was looking at!!!! this is good for school stuff but won't cut it one minute outside. Repeat after me "high level API"
When will you learn, STL and "generic algorythms" are NOT programming, they are nice brain excercises.
I never went to college, I learned C++ on my own and java as well. If you had put a feet outside the
SO let me spell it out for you, my
I have concluded that there is no single best language for web or anything else. The important thing is that the language and paradigm models the *developer's* mind. OO does *not* better model the real world, so what *does* it intend to model?
Personally I miss languages with built-in collections processing not tied to RAM. Perl sucks because it assumes everything is about parsing and skinny, crippled tables; and Java sucks for many reasOOns. However, that is just a subjective opinion.
- wait'n for a real lang
Table-ized A.I.
old wheel new code
I've been coding in Squeak lately. I do most of my coding on a Mac, but I run the app on IRIX, Win95, and WinNT. The Smalltalks have had real WORA for years, as well as a mature class library. Any language that compiles to an interpreted bytecode should be WORA. It's just the nature of the beast. I'm amazed that Sun screwed it up so badly that people now doubt WORA is possible.
How do you get commercial grade encryption (128 bit+) into Apache/JServ?
These guys are catching up fast
While I sometimes enjoy reading slashdot comments (when they aren't just a list of immature flames), I feel that many posters need to get a life outside of computers. This is most evident in the lack of spelling and grammatical skills of the posters. Read something besides slashdot and get a broader perspective on both life and computers. You might even find that it will make you a better programmer, too.
I've been very frustrated with Java ever since it came out. It was born of excellent design and implemented some extremely valuable technology (VMs and GCs). But it was rushed at the end and the result was beauty encrusted with graffiti and hollow paper mache. So, I gave it some time ...
Five years have passed. Some of the graffiti has been removed, but there is still a hollow tone to the base structure. It has been developing strongly in one direction while failing to deliver in other important areas.
Java delivers an excellent development language. It's no surprise that time-to-market sensitive apps have embraced Java. It's really good for that kind of thing: back-end, state-machine based, and atomic operations. Servlet programming is almost exclusively the only success story mentioned. That's a boon to webapp developers, but it does nothing for the other 95% of us.
Java's failures are numerous:
Portability - The resources my company has saved programming with Java are consumed by QA. Each new platform is a significant expense. Our most recent release had to be staggered because there wasn't enough time to QA all the Java on all the platforms. Java VM vendors are largely to blame for this problem; we experience innumerable GUI portability problems (more below) and several nearly undebuggable oddities surrounding threads, file descriptors, and processes. And there are still vendors that lack a 1.2 JVM.
Performance - It's much better than in 1.0, but still has enormous foot print problems. I see the time expended on Java performance work as equal to any other environment. Except that it's worse because of the lack of tools. If you stay away from GUI stuff and reduce your object "churn", you can get pretty good throughput. A JIT helps, but increases your foot print and reduces portability (from experience, JITs bring their own odd bugs, different on each platform).
AWT/Swing - The GUI frameworks for Java are simply crap. It is impossible to develop a large scale GUI app that meets industry standards for performance and usability. Someone noted that Oracle8i has an all Java DB manager. As a marketing bullet it works, but fails utterly in practice. It's slow as a dog. Just try to navigate 100s of schema definitions. You and your machine will be paging like mad: you through your CD collection for that Oracle8 or 7 CD, while your machine pages the 80+MB footprint of the DB server and manager. And that's without installing any of your own DB tables or apps. --- Most of our company had to get RAM upgrades to run the new Swing based release of our software (from 64 to 128MB). Even so, the QA guys mutter and grumble daily as their machines grind away trying to bring up new panels and windows. How will our customers react? --- My comments about portability and performance apply most strongly to AWT/Swing. AWT was truly horrific. Many bugs were fixed during the 1.1 development, but many still existed. We had to hand code replacement widgets for several that were broken in AWT. Or do special per-platform and per-JVM bug work-around hacks. This was possible only because we have one guy that is brilliant at this kind of thing. It's no wonder there are no successful Java GUI apps. The bug parade is reduced with Swing, but at an extreme cost to performance. The minimum Swing footprint on Solaris is 12MB. Our large Swing based app weighs in between 30 and 60MB. An equivalent app on Windows with MFC is 8-12MB and is 10+ times faster.
There you have it, straight from the trenches. My company's greatest Java successes have been with the server-side code. This code is fairly thin and generally simple. Time-to-market is important in this area, so Java is the best solution. But our customers that need high performance stick to C/C++.
[Some what off-my-own-topic] One writer noted that the faster development cycle provides him with more time for performance work. My experience has been that a faster development cycle simply brings ship/deployment closer. The market goals for ship/deployment do not change; it's needed as soon as possible. So as soon as first ship is conceivable (minimum acceptable quality and features) is when it happens. That may come sooner in a Java based product, but the quality level ends up being the same. Or worse if it's a Java GUI app.
Improved server-side webapp development is contributing to the Internet commerce boom. This is no small accomplishment. Java will continue to succeed in this area. But will it be self-restricting? I see little investment in improving Java's client-side capabilities or fixing portability and scalability problems.
Background - My company has written and shipped 100s of thousands of lines of Java code. Most of it GUI code. I participated in only a small portion of this development. The requirements for my part of the product do not mesh with what Java offers, so I use C++.
I was the one who posted the PHP-MySQL tutorial. (My user info isn't showing up perhaps the posting script has a Y2K problem. :-)= kidding...) What we have here is a simple misunderstanding.
I didn't mean that MySQL was an a heavy duty database. (It lacks transactions for one thing...) I meant that the tutorial explained how easy it was to write code to access a database using Apache and PHP.
I found this absolutely astounding, given the really tight labor market.
Heh. If you're planning on making your living doing this, you might want to re-think your career.
But personally, I'm delighted, as my rates went WAY up this year - and I'm wondering if I'm undercharging still.
Keep specializing in Java! I love it!
Java is (will be) successful in 2 areas. 1) Eventually replacing most script languages. JSP is really ASP using Java instead of JavaScript/VBScript. The convergence will come as more specialized packages come out for Java. 2) Eventually become the adcamemic language of choice. It is so easy to use it to teach OO. It will replace Pascal, Ada, Mod3, ...
Java will remain a script-type language. Script languages can do a lot these days but it is hard to replace C/C++ for high performance applications. There are a few problems with its speed. Java is hard to optimize beyoud tuning algorithms. It is not as easy to know what exactly the JVM is doing (now with JIT and HotSpot) to the bytecode. It is still valuable to look at assembler at times to know how to tune C/C++ code. It is also hard to tune memory usage which turned out to be the bottle neck for many high performance apps. A good garbage collector is hard to write and even with one it still will never beat good alloc/free or even new/delete.
It is also simple minded to think that OS/Runtime and language can be totally decoupled and still perform well. OS designers have a set of languages in mind and language designers have some OS specific features in mind. To make Java as fast as C, you will need a Java-specific OS or Java chip.
Just an aside. This is easily done with Perl. In fact you can read in a template .html file and eval it with something like.
$info_str = read_file("template.html")
$eval_str = "print \"$info_str \" ; " ;
eval $eval_str;
Then any variables embedded in your html template are replaced with variables that exist in your script. If they do not exist then they disappear in the output.
Note: You might want to be careful and be sure that no user supplied input will find its way into a eval'd variable. If unsure write a simple switch reg exp and use symbolic references for variable replacement instead.
I agree with the webmacro guy that removal of html within your code is paramount for flexibility and maintainability.
As for those of you that say making Java a GPL product would fork it to death, then why has this not happened for example with the Linux kernel? Think about it. If Java was GPL it might have been using CORBA from the start instead of RMI and it might bind to OpenGL instead of it's own Java3D. In fact you might have Open OS's intigrating Java into themselves in such a way that the VM becomes part of the kernel.
Dude, you can use OpenGL and Corba??
You really should give Java a chance if you haven't, I believe it would surprise you. I have only been working with it at work for about 3-4 months, but I have fallen in love with it. Probably my favorite language. (By far my favorite for Internet backend applications..)
My question is regarding your warnings about JSP. I not sure I understand the design differences between JSP's and the WebMacro approach. Is it that the latter is simpler to use than java?
I haven't used JSP's yet, so please forgive me if I'm missing something obvious.
BTW, another article along the same lines is Design Java servlets with the Delegation Event Model.
Java is a good tool for server-side development where code reuse and maintainability are more important than performance, but there are many areas where it simply won't make a dent, for example, text-handling; until some whiz-bang future version of HTTP replaces HTML text streams with binary data, perl is still the best way to process text, and hence HTML. I can show you regular expressions that you would be hard pressed to fit into ten lines of Java.
Added to which, Pascal and Ada aren't considered "scripting" languages...in fact, outside of Delphi, Pascal simply isn't considered.
why do I even bother? maybe 10% of the people in here have a enough of a clue to be even posting comments.
You are hearing these words from a Java sceptic. I have been developing in ANSI C and Assembler (6502/Z80/x86) for six years, in C++ for 2.5 years and started recently using Perl and PHP. My previous employer has send me to a 14-days Java training (at SUN), so I know a little bit about the language, but I have not yet implemented any real-world applications.
During the last two years, I considered learning and migrating to Java, but the poor quality of both class libraries and any given JVM as well as the failure of Java client side applications and applets shrugged me off.
The recent migration of Java to the server side gave me the impression of being a very desperate retreat, and it looked like a last chance for a language/solution searching for a problem.
However, some postings in this thread, and especially your rather convincing piece of text, make me reconsider my thoughts. From quite a lot of projects I have learned that programmer productivity is maybe the most important and also the most expensive aspect of SW development. Many problems and delays can also be traced back to poor encapsulation and direct usage of global variables/data structures or class variables. This is the point where "clean" OO-Languages might help. It should also be considered that shortage of man power leads often to employment of not very talented and/or experienced developers who are simply overtaxed writing clean and stable C/C++ code.
Java is definitely at least a magnitude slower than well designed C++ code. But trading this loss of speed against a (huge ?) decrease of development time and an increase of stability makes a lot of sense. It is often much cheaper to spend an additional 100k $ on faster hardware if you can cut development time by only a couple of weeks, especially if your application also gains stability and portability.
I appreciate that you directly adress some of Java's current problems. But you also made clear that the edit/compile/link/run cycle of Java is much faster. This (sometimes lengthy) cycle can be a very important and often underevaluated reason for low productivity.
To cut it short: It got the impression that it might be too early to write Java completely off. I will get an IDE, probably JBuilder, (Yes kids, IDEs are much better than stone-age tools like emacs/make !) and start doing some server side development during the next weeks. Hope this will rock !
Jürgen FriedrichAGFA Gevaert AG
Research & Development, Simulations
Its nice that Java is portable, but lets face it, Perl and Python are just as portable in any way that counts. This isn't anything new.
I've done that many times with Perl, Perl/TK
BSDers think is worthy of support? My network card is supported by only *one* free OS. Guess which?
Linux? Nope.
FreeBSD? Surely you jest
It's OpenBSD. Guess which one I use?
So people put ads in papers looking for experienced J2EE people when J2EE is hardly defined. Er, this is a criticism against the ad poster, not Java. And since when is this solely a Java problem? Got 6 years C++ exp. but only 6 mos. of COM? Sorry, buddy - we need real COM exp (even though the spec is how old..?)
Then there's an odd comment that since IT managers are skeptical of Linux because it relies on beta software, they should also be afraid of Java. I'm not sure what to make of this comment - it seems to confuse beta software with the idea of the moving target of a quickly changing standard. Yet in a previous paragraph he states that the J2EE spec was standardized already. Anyway, agree that the software industry moves *very* quickly, but since when is only revolving around Sun?
Read the second to last paragraph: all about cross platform differences, changing and poorly documented spec, market hype, problems because of a general platform for everyone that's good for no one.
I don't know about you, but Windows Everywhere came to mind, Windows 3.1, NT, 2000, CE. Probably Mr. McAllister could've dusted off an old article complaining about Microsoft, ran a 'find/replace' with Java, tossed in some J2EE, and voila, a new article..
According to my bookmarks, Jacl is at www.scriptics.com/products/java/, for anyone who is concerned about it that is.
I've come for the woman, and your head.
My company rolled out a brand new system a year ago that's feeding about 1 million to a million and a half cattle every day. It's written in Java. It runs on laptops running windows 95 or 98, servers running Linux, stand-alone, peer-to-peer and in wireless X client configurations. And you don't get any more mission critical than calling feed for cattle.
It also includes scriptable feed step-up programs using JPython and 3D graphs of consumption.
We haven't had any cross-platform issues beyond keeping our CLASSPATH set. I've done big C projects and OO C++ systems and I've never seen as clean an OO implementation as Java/RMI allows.
I don't like everything in the language, but I think it's the best OOP language right now.
To tell you how much thought went into this and how far this is from being a "fad." This system replaces our original systems which have been in service calling feed for most of the cattle industry since '89. That system is writen in Fortran and runs on DOS.
Tell me the one again about how this would have been a better product written in 3 dialects of C++ with a CORBA ORB and a Jethro's "syntaxes is us" template library.
ko ko kurji
[-- Trust the Monkey --]
Now, two days later, I'm looking for something entirely different and my search leads me to a glossary page. That wasn't what I was looking for so I hit back, but for an instant just before the page was erased, I scrolled down and saw it in the corner of my eye:
WDDX
--
Fuck the system? Nah, you might catch something.