BTW I'm glad we're coming back on topic -- sorta (the whole thread is off-topic to JDS). My original jumping in to the thread was to support the OP who got modded -1 in like 30 seconds or so. He didn't articulate very well what (I think) he meant. And FWIW this is the coolest-headed argument I've yet seen on Slashdot related to Java, thank you.
I'll stay off-topic just to illustrate a little more and then wind back into COBOL at the end...
I am a Smalltalk developer, and have been for 20 years. I love the language, but poor performance and stupid licencing of commercial implementations cut back on my use.
My old team was had three former developers from the Smalltalk group. Good people, good code, but they hated how the platform dwindled into oblivion. Java clearly won't suffer that fate, especially with efforts like GNU Classpath out there.
The socket timeout example was from the *client* side. The client needs a very long-lived connection open, and the server (you're exactly right) has no code in place to ensure a long-lived connection. The server in this case is Apache talking through a plugin to WebSphere -- code that clearly cannot be changed -- and the client is a JSP requester. The architecture is plain wrong: the client should do its work without the use of TCP/IP, but that was not my call and it was too late to change it. The point of the example was that host semantics bubbled straight up through the JVM layer as one workaround after another failed to keep the client alive. Similarly with the file example: production-quality code on the backend needs to predictably run the same whether its Windows or Linux, and that requires either dumbing down to the most restrictive platform or doing a check at runtime.
One final example that I think supports the OP when he said "bugs used to mean application bugs". The JVMs themselves are responsible for many application crashes. We had to support all the "Group I" languages including Korean and Japanese on Solaris, AIX, Linux, and Windows. Bugs abounded in the AWT font rendering in all the available JVM's such that we had to create a matrix of "Language to install in" versus "JVM to use" and keep that around for the support staff. One combination (Solaris + Japanese I think) had NO JVM's available that didn't core. I'm sure you have many stories yourself of "100% Pure Java(tm)" code that led straight to a javacore.txt file.
The point being: write once run anywhere has its limitations.
Anyway, back to COBOL...
My final point: this is all irrelevant to the argument! The point that was made is that Java is like COBOL. This is a plain silly comparison.
But I'm not talking technical points, I'm talking business priorities. Java is being developed and paid for disproportionately towards business logic users. Yes, it's got the libraries out there to do games and networking, and sure COBOL can't possibly touch Java technically especially as COBOL predates both TCP/IP and the GUI interface. Comparing Java to COBOL sounds silly on the surface, but it's still the most apt comparison when you look at what a developer's job often boils down to: moving data from here to there, only now over SOAP or EJB or RMI/CORBA or whatever the next successor to EDI is supposed to be. People didn't come to dislike COBOL entirely for its odd syntax and language features.
Just because Java doesn't suit *you* does not make it poor language for general developers in a wide range of situations.... Have a look at freshmeat - see Java being used for collaboration, games, multimedia, science. Java is not like COBOL!
I'm not trying to make you or anyone else stop developing in Java. The more people make demands of Java in areas outside business logic the faster it will get there. It's a Turing-complete language, and you've always got JNI to wrap low-level code in, so Java can be made to do anything with a computer's hardware you can think of to do (except
Which has a gold release? And runs on how many platforms? And has which professional J2EE servers using it?
I can say Language FOO has any features I want -- if I pull the beta that runs only on one or two operating systems.
Yes it does - the eclipse development environment. But who cares? The desktop environment is a absolutely tiny part of the market. The main market for everything the web, where Java rules.
First, Eclipse bypasses completely the Java Swing library when using SWT (which just about everyone uses). How can Eclipse be a "real" Java app when it had to violate such a fundamental part of the true Java way just to run at a decent clip? Also, Eclipse cost $30 million to develop before it was released as open source; it was originally intended to take out Visual Studio. The only anecdote I can offer (since I use Emacs) is that my friends who use Eclipse, VS and NetBeans generally put it last on their list of favorite environments. I would expect a real best-of-breed product to be able to swing them around.
Second, are we talking market for paid professional work, or market for all applications? If you mean the former, sure the web is where it's at right now. If you mean the latter, go get out more. Do you see any Java 3D games in the store? Consumer-grade productivity software? CAD? Education? Maybe I've been looking on the wrong shelves...
No. Java mobile games alone dwarfs almost all other software in terms of deployments. Java is also becoming widely used as a numerical and engineering language: C/C++ and other just did not cut it as a replacement for Fortran. Java does.
Sorry, beg to differ. You're changing the rules mid-stream: if you want to argue that every cell phone or gameboy on the planet counts as a real Java deployment, I'll have to pull out FORTH and beat your numbers with every washer, dryer, toaster, microwave, and parking gate meter. Or I could go one further and point out that every Java VM is a C deployment too. Or will you say that "C is assembly language" so that doesn't count?
Yes, Java is gaining ground in science. It still has a very long way to go before it replaces the embarassingly-parallelizable Fortran or the custom bleeding-edge C/C++ code out there.
Rubbish. Java has far more OO features than C++. Multiple inheritance was abandoned long ago by mainstream OO language designers as a flawed idea. The interface/contract system, as used by Java, is considered superior.
I probably ought to stop here. (Go ask a Smalltalk developer how much OOP Java really has.)
We could argue MI, but I'll instead ask: why NOT MI in Java? Why re-create every non-overlapping function from the implemented Interfaces rather than just direct-MI all the code? Why force the creation of an abstract class? You probably have an immediate response handy regarding the diamond inheritance pattern, but I'm asking you to just step back, breathe a moment, and remember all the times you've copied the same dozen functions into multiple implementation classes when you wouldn't have needed to if you could have said "public class MyClass extends BusinessClass1, BusinessClass2 {... }".
There is no (standard and guaranteed) ability to dynamically load classes and inspect their properties in C++. I can't take a.so compiled on an Intel architecture and load it on PowerPC. I can, of course, do that with a Java.class.
True. And how often do you need to? I've used Reflection many times to simplify life on the EJB client and server side, and of course I had to Reflect away the Oracle BLOB accessor, but generally my applications, once built, don't change until someone really needs them to change. If I were writing an application server, I would absolutely love the ClassLoader heirarchy and the ability to just set a pointer to null to wipe out a deployed EAR. But I don't write appl
And neither does C, yet we still see 3D games written in C before we see them in COBOL or Java. Java doesn't have templates, multiple inheritance, a free-as-in-speech runtime environment, or a best-of-breed desktop application of any kind.
Apart from that, its very much like COBOL, in that both languages are widely deployed, robust, reliable and used by some of the largest companies to handle critical data.
Precisely. Java and COBOL are both used for business applications and not much else, when compared to the alternatives. Java has the sweet spot of just enough OO-ism without too many confusing abstractions plus a big enough standard library to cover 95% of most uses. But once you leave the business logic arena, Java has a very long way indeed to catch up.
Here's a simple thing in C that I do almost every day: "initscr()" Where's the equivalent functionality in java.* or javax.*? Without initscr() you'll never have a Java equivalent to BitchX, slrn, tin, aptitude, or mc. We should all thank the efforts of Rob Pitman for addressing this rather huge class of use cases. But Sun and IBM couldn't care less. Banks and online retailers don't use (n)curses, so Java will never get that functionality as part of a standard installation.
And as the parent poster originally inferred: a computer science degree should be useful for far more than just business logic code.
We end up with uniform ways to store certain kinds of common data: who you are (in IM, or on a pay web site, or in a MMORG); what you're doing right now (fuse IM away messages with groupware calendaring); your physical location (to those parties in IM you authorize to see); most importantly your cryptographic keys database (so you can actually authorize those IM'ers to know your location).
We get closer to the Star Trek computer. "Computer: what is Britney Spears up to?" "Britney Spears is on a date with John Crusoe, guests are welcome to take pictures. Would you like a map to the location?"
I used to work across the floor from the WebSphere developers. They're very smart people, and WebSphere after version 4.x is quite nice. Add Portal Server (I know more of them that WAS) and you've got some slick stuff.
But building anything NON-webapp/portlet-like (e.g. isn't focused on users clicking links from a browser and is not web services) inside WebSphere is probably a mistake when objectively compared to the alternatives. I'm talking about things like desktop software, high-performance batch processing, and of course games.
Not trying to get into a flamewar, just want to remind you that there's plenty more under the sun that works really well too. The GP was talking about CSCI in general, and outside the server room there's still a LOT of CSCI that needs to get done before we reach our Star Trek interface.:)
I agree with you in general. Java has its uses, but its enthusiasts are flat out wrong that it's the best language for any job, or even "most jobs". Comparing Java to COBOL is almost exactly right.
Nonetheless, most of these applications would be that much more valuable if they were integrated together.
How do you figure?
When I think IM, I've got GAIM. I *like* that it's a "simple" (to the user) application whose sole purpose is done well and doesn't interfere with the rest of my system. Granted, some integration exists: when new mail notifications pop up GAIM can call Mozilla to open my web-based email account; when I click on links in GAIM they open in new tabs in Mozilla.
I'm the end user here -- usually accessing the 'Net on a dialup account. What does integrating other networked applications into my browser buy me? In short, what's your final vision of the browser?
I've heard that some linux gurus can update sshd and restart the daemon while logged in via ssh, without losing the ssh session
I doubt they're doing anything particularly magical. sshd the root-level daemon listens on port 22. After it establishes the connection, it hands off to a child sshd -- a completely separate process. So your gurus are likely just restarting the listener process which shouldn't effect the child processes.
I would test it for you but I'm kinda sleepy.:) Check out the man pages on listen(), accept(), and fork() to see how a parent process can listen and then hand off the existing connection.
The question today (as in so many other days past) is what can we Linux developers learn from Microsoft's mud?
I wish I could say there's lots to learn from Sasser, but there really isn't. We learned about insecure root-level networks daemons in 1988 with the Internet Worm: fingerd and sendmail were the culprits then. Since 1988 the common Unix daemons have been audited hundreds of times, and after a long rash of compromises through the early 90's they've gotten "reasonably" secure.
What we learned in 1988 was that most daemons should NOT run as root, and that those which do should be very very small and selective with what they do AS root. We created tools to carefully control root access (chroot and sudo), we've implemented kernel-level firewalls to restrict inbound network access to insecure applications, and we've implemented other system controls to prevent non-root local users from seeing sensitive data (shadow passwords).
All these steps don't work ALL the time, but they've increased the bar considerably since 1988 for unauthorized penetration.
Then add the new security software we've written: intrusion detection systems, tripwire monitoring, weak password scanners, and dedicated honeypot systems. Some of these tools have been ported/duplicated for Windows, but they aren't used nearly so frequently in my limited server shop experience. Security has just always been an afterthought in the Windows market, and now Windows is undergoing the painful growing experience Unix went through fifteen years ago.
What are the issues that are allowing these things to happen and how can we prevent them? I hope everyone has heard this before.
Well, mostly we've got distros that set up the system to use lots of different user IDs to restrict access on listening ports. So very few network daemons are running with superuser privileges at all, generally only sshd, named, and RPC, plus a few others that are "unusual" on most systems. Most of these daemons have had their share of troubles, but that was many years ago and they have undergone a security beating far more severe than any version of Windows, so they can generally be "trusted". Furthermore, when holes DO pop up (as they have), we've got very mature systems for patching those holes without requiring major disruption. (In my case it's simply "apt-get upgrade".)
Finally, even when a worm compromises a typical non-root network daemon such as Apache, its scope is limited to damaging whatever Apache's user (typically 'nobody') has access to. This point doesn't go very far in typical business use cases -- mostly those non-root users ARE the critical business data.
The difference with Windows is that Microsoft started with dozens of services on that all have superuser access that they don't really need. So a hole in any one of these leads to an entirely compromised system that (important part) the user sitting at the desktop cannot fix. When apache goes down, I just type "apachectl stop" or "kill -9 [apache's PID]" and the worm is dead in its tracks. On Windows 2000/XP, I pull up taskmgr.exe and try to kill the service and I'm told it cannot be terminated.
I used to think the Windows ACL's would provide better security than Unix group IDs (GIDs). But after migrating to a modern distro, I see that there's very little I can't control with GIDs. For example, my regular user is part of the cdrom, audio, and scanner groups, so I can rip and burn CDs, play music, and scan images, but I can't do anything else that would screw up the system. I'm sure Windows can be secured the same way, but (important point) it isn't ever shipped that way. Many Windows apps require Administrator rights just to *run* correctly, and I've encountered no professional apps that can install without Administrator rights. So IMHO those ACLs are providing only theoretical security. Unix distros are providing practical security.
It seems to me that the world in general would benefit most from a pro
Perhaps I can be of assistance here. I'm from Texas and nearly everything Bush is accused of doing nationally was originally documented locally, yet thoroughly ignored by the Associated Press during the 2000 election:
I do not like anyone who accuses someone else of anything, especially lying, without any sort of proof.
Houston Press article, circa 1997: Bush used insider trading to sell his share of the Texas Rangers at a huge profit. Different article, same year: Bush pressured the Houston City Council to illegally confiscate a family's land via eminent domain in order to seal a sports stadium deal ("Enron Field", now sporting a new name of course but still referred to by all the locals as Enron Field) before presenting the deal up for a public vote.
Different Houston Press article, circa 1998: Bush's education reform bill first pass was entirely unworkable. The version that was signed into law was the bipartisan work of the leaders (Bob Bolluck and... I can't remember) of the two legislative bodies. Bush claimed sole credit anyway. Perhaps it worked out for the best with respect to the anti-Bush crowd: the reforms have failed miserably at improving high school graduation rates, and have actually forced more kids to dropout earlier. It became material for MoveOn.org's "Bush in 30 Seconds" contest. Doesn't help the kids much though.
I do not like anyone who feels there's *anything* self-righteous about enforcing numerous broken U.N. resolutions and freeing millions of enslaved people, as well as avenging the deaths of millions more.
Tangental but I have to respond. See "Rogue State" by William Blum: too many citations to list! The gist is that the USA is the most prominent breaker of UN resolutions and illegal supporter of the brutal regimes (including Hussein's) that have led directly to the death and enslavement of millions. However, while I agree that correcting the grievous wrongs (helping the Ba'ath Party take over in 1963, supporting Hussein throughout the 1980's with conventional, chemical and biological weapons, and allowing Hussein to (barely) retain his grip on power via the Food-For-Oil program) is the morally right thing to do, I'm hard-pressed to see the current Iraqi occupation as really being about paying for our sins. Virtually every non-US news source is carrying stories that show a far more cynical picture.
But that's neither here nor there, let's get back to Bush.
I do not like people make baseless accusations about someone they don't know.
Bush was born in Maine, grew up mostly in Texas, attended Yale, but generally stayed in Texas. His accent is probably genuine.
"I do not like unknowlegdable leaders who depend upon advisors to tell them what to do."
What kind of effective leader does not consult with his advisors? Answer: There is no such thing as an effective leader who doesn't consult with his advisors. You obviously have a lot to learn about leadership. Why do I know so much about it? Because I've spent years learning and practicing and honing leadership skills in the military.
The PP is almost certainly referring to Bush's overreliance on advisors. Bush is quoted in several AP articles as saying that he relies on his advisors so much that he feels it unnecessary to even read the newspaper or watch television news. He was genuinely shocked (sorry it's not an AP link, I lost that a while back) that members of Congress applauded when he bemoaned the PATRIOT Act's pending expiration during his State of the Union speech, just as he was rumored to be surprised to see people protesting him on his recent trip to Indonesia.
Furthermore, upon what grounds do you accuse Bush of having advisors that "tell him what to do"? I would love to see actual evidence that he does exactly what his advisors tell him to do.
That's like hiring a builder to build your house, then hanging over them all the time and telling them they're doing it wrong.
You won't get very far arguing with this analogy. Ask anyone who has hired a builder to build their dream home.
How about instead, "That's like hiring a certified mechanic to fix your car, then insisting on getting under it with them and telling them they're doing it all wrong." ?
I would agree with you, except that employers require a degree nowadays for code monkeys. And, having a degree and the $20,000 debt to prove it, I can say that there is no way in hell minimum wage can recover that cost.
So if employers stopped requiring degrees I'd support your drive to lower IT wages. Especially when the employee quality priced at minimum wage causes the business to go belly up.
I think we might agree about who it is doing the complaining, but perhaps we should replace your key phrases:
Start with:...most of the crying seems to be coming from people who
And begin replacing:
didn't have any savings,
"weren't born into the upper middle class"
made poor choices,
"majored in a high-growth field right before a huge -- and unpredicted -- change in the global economy"
and want something handed to them.
"yet still want to be capable of duplicating their parents' lifestyle."
We end with:
"...most of the crying seems to be coming from people who weren't born into the upper middle class, majored in a high-growth field right before a huge -- and unpredicted -- change in the global economy, yet still want to be capable of duplicating their parents' lifestyle."
you don't even want to imagine what a US bankruptcy would do to the world. Let's just simplify it and say that no one will be left standing and world-wide human suffering would be incalculable.
Have you by chance read "Rogue State" by William Blum? It's very "illuminating" about America's foreign policy objectives.
I actually agree with you that an American bankruptcy -- manifested as a US dollar that becomes literally worthless -- would bring the Western world down into a major Depression with probably 30%+ unemployment in most countries. However, I have to balance that with the fact that US foreign policy will become impossible to pursue, and as such many many people may prosper where they cannot do so now.
I believe "no one will be left standing" may also be true because the US will probably resort to violence to achieve its ends even after its currency is devalued in this hypothetical future. But if the US could be brought to heel and forced to weather its own Depression without resorting to war or fascism, we might ALL benefit.
Come on now, writing ANY type of program at 7 or 8 is AB-FUCKING-NORMAL, I don't care how smart you are, when you're 7 or 8 you're flying kites and playing little league, so I call bullshit. I call bullshit cause you think the dweebs and nerds here will give you credence and props cause you were one of the maybe 5, 10, 100? kids globally 'programming at 7 or 8'. Sorry Doogie Howser, you were learning to read and write at 7 or 8, and if you weren't, in all honesty, how normal of a child were you? Really?
Sigh.
I took a class in 3rd grade, at 8 years old mind you, to program Apple II BASIC. My elementary school of a few hundred students had about 25 in my class, all of us programming at age 8. Granted it was the "gifted" program and only two elementary schools had it in my old town, but I assure you that THOUSANDS of 8-year-old children learned how to program computers; many of them did NOT grow up to be computer geeks either. Do you remember all the books for teaching children how to program BASIC and eventually move up to Pascal? They were right next to the Visicalc manuals two shelves away of the UFO section at my local library.
if you use, or know how to use, or have heard of anything but Microsoft Windows, then you're NOT a typical user.
My brother has heard of Linux. My wife had heard of Unix before I met her. Everyone has heard of Macintosh.
I understand your frustration with assholes who reply "RTFM" to any user question. But I think you fail to grasp the point that a rather large segment of the population knows how to use computers at a much higher level than they are given credit for. Yes, throughout the 80's people picked up on DOS commands (many of which DO have relevance in the command-line Unix era).
You SAY we should get off our elitist high horse. Then you turn around and insult everyone who isn't you. Cognitive dissonance perhaps?
My uptime is 19 days as of right now, if you were wondering.
I know you were trying to show that XP is significantly more stable than 98, NT4, etc., but perhaps you should pick a different metric.:)
My work machine was Redhat 7.1, and its uptime was 356 days I think. I was sad to turn it off, but I was moving floors.
My home machine is never turned off -- it takes too long to spin up all the SCSI drives -- and I typically run Debian 6 days/week, switching to '98 only long enough to do some schoolwork in Excel '97.
Yes, and outside IBM there's Japhar, Kaffe, and every other program that emulates the Java Virtual Machine. BTW I used to work with a guy on the team that made the Real-Time Java VM.
I meant JVM in that same sense that the OP did: the JRE. IBM's "JRE" -- as distributed for Linux, Windows, and AIX -- is Sun's "JRE".
People who continue to claim that IBM has a total clean-room JVM are right only in the sense that IBM has its own programs that can execute (most).class files and show output.
They are wrong in the sense that IBM's clean-room JVM won't actually do anything useful unless you have the rest of the licensed Sun JRE environment handy that has the code for java.lang.*, java.io.*, java.net.*, etc. Until IBM has all that code duplicated, they really don't have a clean-room JRE.
Is that better?
IBM knows an awful lot about Java. They wrote RTJava, they experimented with a Java->native compiler (abandoned due to excessive memory requirements for the available hardware at that time), they've got a clean-room JCE, an ORB robust enough for JNDI lookups hence EJB, they've got WebSphere, Portal, and WSAD/Eclipse (though Eclipse is its own story of a lot of lost money, it was supposed to be the Visual Studio killer in 2001).
But what they have not done is pay for the time to duplicate all the Objects and Interfaces in java.* and javax.*. It's just not worth it when you're already a Sun licensee. They do indeed make significant changes to the Sun JVM with every release of the IBM JRE (see now I'm using the terms in the more correct manner). But if Sun suffered corporate death right now IBM would NOT have a JRE available for forking as everyone likes to believe and say. IBM would instead have a long road ahead of it to either finish the work of GNU Classpath or write its own Classpath Objects.
Sigh. People say JVM to mean JRE and I follow suit, and then I get flamed by the ignorant.
Repeat after me: Sun's classes are the ONLY CLASSES IMPLEMENTING THE "STANDARD" IN COMMON USE TODAY.
Got that?
If you have a car, and it's got a part broken, and only one supplier in the entire world has the part to fix it, then it's a reasonable idea to say that your car is dependant on that one supplier. Car -> dependant on one part -> dependant on one supplier == car -> dependant on one supplier.
Like I said, more FUD, move along.
Fuck you. Come back when you've written 100,000+ lines production J2EE code on multiple J2EE servers using more than one JVM -- oops I meant JRE -- from more than one vendor.
I think I know what you're talking about: "webapps" in the loosest sense only in that they run on a J2EE server, that may not have an exposed web page interface of any kind. You talk to them with SOAP or EJB clients. They've got all the libraries from Java: JavaMail, EJB, JDBC, JCE, etc., plus they can use hundreds of other liraries from Apache and elsewhere.
That's the kind of thing I used to do for a living. Bored the hell out of me. I started calling it the "COBOL of the 21st Century".
I used to really like the J2EE environment. I changed my mind when I put up a web page in PHP, and found that it was far easier to debug what was going on and make changes. Email in PHP is a snap, even though it introduces a platform dependency; SOAP is even easier than the already easy Apache Axis API; database access is just like Perl's DBI. I was amazed how many libraries are in CPAN, and how easy it is to install them ("perl -MCPAN -e 'install Foo::Bar'). I even got angry at how much time we already spent on a full-blown J2EE "solution" that could've been done in Perl or PHP -- including the frontend! -- in 1/5 the time.
But back to your uses: strong typing IS handy for business-critical logic I agree, especially as these apps have to live "forever" (a.k.a. until the business goes under) and will probably see lots of turnover in the development staff over the years. (And come to think of it I forgot to add multi-threaded prototyping is a job Java does well.)
Wether classes in javax.* or java.* depend on other com.sun.* classes is irrelevant.
What matters is the the API of java.* and javax.* or free to be implemented by anyone. So it's a bit far fetched to call everything in javax.* proprietary. The implementation may be, bu the API sure isn't.
Let's talk reality and not theory: until a free implementation of all those classes is in common use (not 100% use, just more than 5% use), then all of the code that relies on those published APIs is still dependant on proprietary code. That's what RMS is trying to point out, and that's why GNU Classpath is necessary before your code is really "free" from Sun's ultimate control.
By analogy: Your car is broken and needs a part. You go to NAPA, they say you need a water pump. It so happens that only one water pump with the dimensions that fit your car is sold in the country, manufactured by company Foo, available for $3000. The NAPA salesman says "Sorry man, too bad you have to pay $3000 for your part." You tell him "I don't technically need that $3000 part. My car was designed so that any water pump that matches the published specs will work." He says, "But dude there's only one store with that part anywhere. Say what you want, but right now your car is designed to need part #98923-2A75F6 from Foo Inc. You gonna pay $3000 to repair this car or are you gonna get a new car?"
If you're going to argue word choice, at least spell "non sequitur" correctly. Regardless, for small-medium projects, Java isn't a good choice compared to the alternatives. Perhaps you should TRY LAMP first before disparaging it. Or put yourself in the shoes of a small business owner who needs a web site and doesn't have $20,000 to dedicate to software licenses or a Java professional's time.
And to be blunt, the LAMP site is going to be up in 1/5 the development time and be far more responsive to the user (faster) than the equivalent J2EE site. The J2EE site can be improved to meet the LAMP site's speed, but it's an uphill battle all the way. It isn't until you need a LOT more than a basic site that J2EE starts to pay off, and my point is the market for such sites is tiny (even though it pays $$$ reasonably well) compared to the market that LAMP can satisfy.
Python, Qt, wxWindows, Tcl/Tk, etc., support WAY more platforms than Flash. Where I came from you weren't cross-platform until you supported AIX, Solaris, HP-UX, IRIX, Linux, Windows, and finally Mac OS X.
I say prefer Perl or PHP for quick-and-dirty database apps because they are very effective at being quick-and-dirty. Like fifteen minutes or so to make a program that can SELECT and do basic string or numeric manipulation before writing the data out to a flat file. In Java that would take about an hour to write, not due to JDBC but because you have to add external libraries for string manipulation. Perhaps if you tried Perl DBI you'd see why I say it's much faster. I say PREFER Perl/PHP, but if that's not available and JDBC/ODBC is, then use that before resorting to command-line scripts.
"Like Batik?" OK, let's see how even Batik does:
---snip---
$ java -fullversion java full version "J2RE 1.3.0 IBM build cx130-20010626"
Converting mapSpain.svg to batik-1.5.1/samples/mapSpain.png... _X11TransSocketINETConnect: Can't get address for foo.bar Exception in thread "main" java.lang.InternalError: Can't connect to X11 window server using 'foo.bar:543' as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnviron ment.java:63)
at java.lang.Class.forName1(Native Method)
at java.lang.Class.forName(Class.java:134)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvir onment(GraphicsEnvironment.java:64)
at java.awt.Font.initializeFont(Font.java:277)
at java.awt.Font.(Font.java:361)
at java.awt.Font.getFont(Font.java:378)
at sun.java2d.SunGraphicsEnvironment.getBestFontFor(S unGraphicsEnvironment.java:585)
at java.awt.font.TextLayout.standardInit(TextLayout.j ava:628)
at java.awt.font.TextLayout.(TextLayout.java:479)
at org.apache.batik.gvt.text.BidiAttributedCharacterI terator.(Unknown Source)
at org.apache.batik.gvt.renderer.StrokingTextPainter. getTextRuns(Unknown Source)
at org.apache.batik.gvt.renderer.StrokingTextPainter. getBounds2D(Unknown Source)
at org.apache.batik.gvt.TextNode.getPrimitiveBounds(U nknown Source)
at org.apache.batik.gvt.AbstractGraphicsNode.getTrans formedPrimitiveBounds(Unknown Source)
at org.apache.batik.gvt.AbstractGraphicsNode.getTrans formedBounds(Unknown Source)
---snip---
(Oh look at that! It's an IBM JVM using Sun's code!)
I've been doing headless java graphics manipulation since 1.1.6 as part of my photo album and other tools. It got a bit easier in 1.4, but it's always been possible. For example: my house temperature diagram takes the collected data and renders to PNG or GIF depending on what your client claims to accept.
How? The only ways I've heard of are using an AWT replacement library ala Pure Java AWT, using code that doesn't depend on AWT at all, or setting up a virtual frame buffer X server. If there's another way I'd sure like to know. Even Batik relies on AWT, as I demonstrated to another poster.
IBM's JDK/JVM is Sun's JDK/JVM ported to IBM hardware with some enhancements for performance and added libraries (JCE, ORB).
IBM's JVM is Sun's JVM. IBM did NOT invent a new JVM, and IBM's JVM is completely dependent on the licensing status of Sun's JVM.
I worked for IBM in the WebSphere Tools group from 2000-2003. We got previews of the IBM JVM from Hursley every few months; we saw IBM's branded JVM a full year before the rest of the world did.
Please let this meme die. IBM did NOT invent a new JVM. Sun still controls all of the viable JVM's in use. Kaffe's JVM is the only clean-room JVM *I've* heard of, and it is never used inside IBM.
When you import java.awt.*, and call new java.awt.Frame(), sure enough you've suddenly gone deep into sun.* territory. Try it: run your program from the command line without an X11 server (or set an invalid DISPLAY value), catch and print the stacktrace of the java.lang.InternalError produced.
But particularly javax.* is strictly proprietary land, and that includes: servlets, portlets, JSPs, JavaMail, EJB, and JCE to start with.
I've programmed Java J2EE for years. I am expert at the "best practices", performance tweaks, and real production-quality code, yet Java's utility is almost nonexistent beyond "it's what I [was] paid to write." Here is MY short list of things Java is useful for:
1) HUGE web sites. J2EE is a good solution: strong typing in the language, a security model that is complete from the database backend up to the Struts frontend, and clustering/failover with EJB 2.0.
COROLLARY: Small-medium sites should use LAMP and rely on redundant hardware to handle failover.
2) Applets. Since they run on "most" Unixes + Windows browsers, and despite the load time an applet is much friendlier to users than Flash. But you have to use Java 1.1 to ensure compatibility.
COROLLARY: Cross-platforms GUIs should use Python, Qt, wxWindows, Tcl/Tk, etc.
3) Unusual database applications for which only an ODBC or JDBC driver exists. JDBC is a rather mature standard (should be since it ripped off ODBC) that works pretty well. It's faster to write a few quick Statements and PreparedStatements and run them against a database than to use native tools that "have" 'different' ''ways'' of quoting strings.
COROLLARY: Prefer Perl or PHP if the database is supported.
4) Any application for which speed is not an issue. Yeah, Java can do everything any other language can do, and if this is the one easiest for someone to "think in" then they should use it.
COROLLARY: NEVER use Java to create or manipulate graphics from the command line. No JDK, EVER, has managed to do this despite five years of pleading from the professional programmers. Without a GUI Java goes belly-up on the first "new java.awt.Frame()". (And for you 1.4+ folks who think HeadlessException was a fine solution, it wasn't.)
Java was a great idea in 1995, but since then Java has been pushed as the Second Coming and it just hasn't measured up. The other languages have surpassed Java in every one of its primary marketing points: platform independence, performance, object-orientedness, ease of use.
So what jobs are you doing that make Java the best solution?
Not trying to flame, but genuinely curious.
FYI Blackdown, IBM et al CAN'T fork the Sun JDK unless Sun frees the code. And, as apparently thousands of Slashdotters are unaware, every other JDK except Kaffe+GNU is an independently licensed derivative of Sun's JDK.
Slashdot Mirror
BTW I'm glad we're coming back on topic -- sorta (the whole thread is off-topic to JDS). My original jumping in to the thread was to support the OP who got modded -1 in like 30 seconds or so. He didn't articulate very well what (I think) he meant. And FWIW this is the coolest-headed argument I've yet seen on Slashdot related to Java, thank you.
... Have a look at freshmeat - see Java being used for collaboration, games, multimedia, science. Java is not like COBOL!
I'll stay off-topic just to illustrate a little more and then wind back into COBOL at the end...
I am a Smalltalk developer, and have been for 20 years. I love the language, but poor performance and stupid licencing of commercial implementations cut back on my use.
My old team was had three former developers from the Smalltalk group. Good people, good code, but they hated how the platform dwindled into oblivion. Java clearly won't suffer that fate, especially with efforts like GNU Classpath out there.
The socket timeout example was from the *client* side. The client needs a very long-lived connection open, and the server (you're exactly right) has no code in place to ensure a long-lived connection. The server in this case is Apache talking through a plugin to WebSphere -- code that clearly cannot be changed -- and the client is a JSP requester. The architecture is plain wrong: the client should do its work without the use of TCP/IP, but that was not my call and it was too late to change it. The point of the example was that host semantics bubbled straight up through the JVM layer as one workaround after another failed to keep the client alive. Similarly with the file example: production-quality code on the backend needs to predictably run the same whether its Windows or Linux, and that requires either dumbing down to the most restrictive platform or doing a check at runtime.
One final example that I think supports the OP when he said "bugs used to mean application bugs". The JVMs themselves are responsible for many application crashes. We had to support all the "Group I" languages including Korean and Japanese on Solaris, AIX, Linux, and Windows. Bugs abounded in the AWT font rendering in all the available JVM's such that we had to create a matrix of "Language to install in" versus "JVM to use" and keep that around for the support staff. One combination (Solaris + Japanese I think) had NO JVM's available that didn't core. I'm sure you have many stories yourself of "100% Pure Java(tm)" code that led straight to a javacore.txt file.
The point being: write once run anywhere has its limitations.
Anyway, back to COBOL...
My final point: this is all irrelevant to the argument! The point that was made is that Java is like COBOL. This is a plain silly comparison.
But I'm not talking technical points, I'm talking business priorities. Java is being developed and paid for disproportionately towards business logic users. Yes, it's got the libraries out there to do games and networking, and sure COBOL can't possibly touch Java technically especially as COBOL predates both TCP/IP and the GUI interface. Comparing Java to COBOL sounds silly on the surface, but it's still the most apt comparison when you look at what a developer's job often boils down to: moving data from here to there, only now over SOAP or EJB or RMI/CORBA or whatever the next successor to EDI is supposed to be. People didn't come to dislike COBOL entirely for its odd syntax and language features.
Just because Java doesn't suit *you* does not make it poor language for general developers in a wide range of situations.
I'm not trying to make you or anyone else stop developing in Java. The more people make demands of Java in areas outside business logic the faster it will get there. It's a Turing-complete language, and you've always got JNI to wrap low-level code in, so Java can be made to do anything with a computer's hardware you can think of to do (except
Yes it does, in JAVA 1.5
... }".
.so compiled on an Intel architecture and load it on PowerPC. I can, of course, do that with a Java .class.
Which has a gold release? And runs on how many platforms? And has which professional J2EE servers using it?
I can say Language FOO has any features I want -- if I pull the beta that runs only on one or two operating systems.
Yes it does - the eclipse development environment. But who cares? The desktop environment is a absolutely tiny part of the market. The main market for everything the web, where Java rules.
First, Eclipse bypasses completely the Java Swing library when using SWT (which just about everyone uses). How can Eclipse be a "real" Java app when it had to violate such a fundamental part of the true Java way just to run at a decent clip? Also, Eclipse cost $30 million to develop before it was released as open source; it was originally intended to take out Visual Studio. The only anecdote I can offer (since I use Emacs) is that my friends who use Eclipse, VS and NetBeans generally put it last on their list of favorite environments. I would expect a real best-of-breed product to be able to swing them around.
Second, are we talking market for paid professional work, or market for all applications? If you mean the former, sure the web is where it's at right now. If you mean the latter, go get out more. Do you see any Java 3D games in the store? Consumer-grade productivity software? CAD? Education? Maybe I've been looking on the wrong shelves...
No. Java mobile games alone dwarfs almost all other software in terms of deployments. Java is also becoming widely used as a numerical and engineering language: C/C++ and other just did not cut it as a replacement for Fortran. Java does.
Sorry, beg to differ. You're changing the rules mid-stream: if you want to argue that every cell phone or gameboy on the planet counts as a real Java deployment, I'll have to pull out FORTH and beat your numbers with every washer, dryer, toaster, microwave, and parking gate meter. Or I could go one further and point out that every Java VM is a C deployment too. Or will you say that "C is assembly language" so that doesn't count?
Yes, Java is gaining ground in science. It still has a very long way to go before it replaces the embarassingly-parallelizable Fortran or the custom bleeding-edge C/C++ code out there.
Rubbish. Java has far more OO features than C++. Multiple inheritance was abandoned long ago by mainstream OO language designers as a flawed idea. The interface/contract system, as used by Java, is considered superior.
I probably ought to stop here. (Go ask a Smalltalk developer how much OOP Java really has.)
We could argue MI, but I'll instead ask: why NOT MI in Java? Why re-create every non-overlapping function from the implemented Interfaces rather than just direct-MI all the code? Why force the creation of an abstract class? You probably have an immediate response handy regarding the diamond inheritance pattern, but I'm asking you to just step back, breathe a moment, and remember all the times you've copied the same dozen functions into multiple implementation classes when you wouldn't have needed to if you could have said "public class MyClass extends BusinessClass1, BusinessClass2 {
There is no (standard and guaranteed) ability to dynamically load classes and inspect their properties in C++. I can't take a
True. And how often do you need to? I've used Reflection many times to simplify life on the EJB client and server side, and of course I had to Reflect away the Oracle BLOB accessor, but generally my applications, once built, don't change until someone really needs them to change. If I were writing an application server, I would absolutely love the ClassLoader heirarchy and the ability to just set a pointer to null to wipe out a deployed EAR. But I don't write appl
Cobol does not have...blah blah blah.
And neither does C, yet we still see 3D games written in C before we see them in COBOL or Java. Java doesn't have templates, multiple inheritance, a free-as-in-speech runtime environment, or a best-of-breed desktop application of any kind.
Apart from that, its very much like COBOL, in that both languages are widely deployed, robust, reliable and used by some of the largest companies to handle critical data.
Precisely. Java and COBOL are both used for business applications and not much else, when compared to the alternatives. Java has the sweet spot of just enough OO-ism without too many confusing abstractions plus a big enough standard library to cover 95% of most uses. But once you leave the business logic arena, Java has a very long way indeed to catch up.
Here's a simple thing in C that I do almost every day: "initscr()" Where's the equivalent functionality in java.* or javax.*? Without initscr() you'll never have a Java equivalent to BitchX, slrn, tin, aptitude, or mc. We should all thank the efforts of Rob Pitman for addressing this rather huge class of use cases. But Sun and IBM couldn't care less. Banks and online retailers don't use (n)curses, so Java will never get that functionality as part of a standard installation.
And as the parent poster originally inferred: a computer science degree should be useful for far more than just business logic code.
OK, I think I know where you're heading.
We end up with uniform ways to store certain kinds of common data: who you are (in IM, or on a pay web site, or in a MMORG); what you're doing right now (fuse IM away messages with groupware calendaring); your physical location (to those parties in IM you authorize to see); most importantly your cryptographic keys database (so you can actually authorize those IM'ers to know your location).
We get closer to the Star Trek computer. "Computer: what is Britney Spears up to?" "Britney Spears is on a date with John Crusoe, guests are welcome to take pictures. Would you like a map to the location?"
I used to work across the floor from the WebSphere developers. They're very smart people, and WebSphere after version 4.x is quite nice. Add Portal Server (I know more of them that WAS) and you've got some slick stuff.
:)
But building anything NON-webapp/portlet-like (e.g. isn't focused on users clicking links from a browser and is not web services) inside WebSphere is probably a mistake when objectively compared to the alternatives. I'm talking about things like desktop software, high-performance batch processing, and of course games.
Not trying to get into a flamewar, just want to remind you that there's plenty more under the sun that works really well too. The GP was talking about CSCI in general, and outside the server room there's still a LOT of CSCI that needs to get done before we reach our Star Trek interface.
I've had this flamewar before too. I decided to write an essay to address my points in one shot:
_ like_java.php
http://www.patd.net/~ciggieposeur/writings/i_dont
I agree with you in general. Java has its uses, but its enthusiasts are flat out wrong that it's the best language for any job, or even "most jobs". Comparing Java to COBOL is almost exactly right.
Nonetheless, most of these applications would be that much more valuable if they were integrated together.
How do you figure?
When I think IM, I've got GAIM. I *like* that it's a "simple" (to the user) application whose sole purpose is done well and doesn't interfere with the rest of my system. Granted, some integration exists: when new mail notifications pop up GAIM can call Mozilla to open my web-based email account; when I click on links in GAIM they open in new tabs in Mozilla.
I'm the end user here -- usually accessing the 'Net on a dialup account. What does integrating other networked applications into my browser buy me? In short, what's your final vision of the browser?
I've heard that some linux gurus can update sshd and restart the daemon while logged in via ssh, without losing the ssh session
:) Check out the man pages on listen(), accept(), and fork() to see how a parent process can listen and then hand off the existing connection.
I doubt they're doing anything particularly magical. sshd the root-level daemon listens on port 22. After it establishes the connection, it hands off to a child sshd -- a completely separate process. So your gurus are likely just restarting the listener process which shouldn't effect the child processes.
I would test it for you but I'm kinda sleepy.
The question today (as in so many other days past) is what can we Linux developers learn from Microsoft's mud?
I wish I could say there's lots to learn from Sasser, but there really isn't. We learned about insecure root-level networks daemons in 1988 with the Internet Worm: fingerd and sendmail were the culprits then. Since 1988 the common Unix daemons have been audited hundreds of times, and after a long rash of compromises through the early 90's they've gotten "reasonably" secure.
What we learned in 1988 was that most daemons should NOT run as root, and that those which do should be very very small and selective with what they do AS root. We created tools to carefully control root access (chroot and sudo), we've implemented kernel-level firewalls to restrict inbound network access to insecure applications, and we've implemented other system controls to prevent non-root local users from seeing sensitive data (shadow passwords).
All these steps don't work ALL the time, but they've increased the bar considerably since 1988 for unauthorized penetration.
Then add the new security software we've written: intrusion detection systems, tripwire monitoring, weak password scanners, and dedicated honeypot systems. Some of these tools have been ported/duplicated for Windows, but they aren't used nearly so frequently in my limited server shop experience. Security has just always been an afterthought in the Windows market, and now Windows is undergoing the painful growing experience Unix went through fifteen years ago.
What are the issues that are allowing these things to happen and how can we prevent them? I hope everyone has heard this before.
Well, mostly we've got distros that set up the system to use lots of different user IDs to restrict access on listening ports. So very few network daemons are running with superuser privileges at all, generally only sshd, named, and RPC, plus a few others that are "unusual" on most systems. Most of these daemons have had their share of troubles, but that was many years ago and they have undergone a security beating far more severe than any version of Windows, so they can generally be "trusted". Furthermore, when holes DO pop up (as they have), we've got very mature systems for patching those holes without requiring major disruption. (In my case it's simply "apt-get upgrade".)
Finally, even when a worm compromises a typical non-root network daemon such as Apache, its scope is limited to damaging whatever Apache's user (typically 'nobody') has access to. This point doesn't go very far in typical business use cases -- mostly those non-root users ARE the critical business data.
The difference with Windows is that Microsoft started with dozens of services on that all have superuser access that they don't really need. So a hole in any one of these leads to an entirely compromised system that (important part) the user sitting at the desktop cannot fix. When apache goes down, I just type "apachectl stop" or "kill -9 [apache's PID]" and the worm is dead in its tracks. On Windows 2000/XP, I pull up taskmgr.exe and try to kill the service and I'm told it cannot be terminated.
I used to think the Windows ACL's would provide better security than Unix group IDs (GIDs). But after migrating to a modern distro, I see that there's very little I can't control with GIDs. For example, my regular user is part of the cdrom, audio, and scanner groups, so I can rip and burn CDs, play music, and scan images, but I can't do anything else that would screw up the system. I'm sure Windows can be secured the same way, but (important point) it isn't ever shipped that way. Many Windows apps require Administrator rights just to *run* correctly, and I've encountered no professional apps that can install without Administrator rights. So IMHO those ACLs are providing only theoretical security. Unix distros are providing practical security.
It seems to me that the world in general would benefit most from a pro
Perhaps I can be of assistance here. I'm from Texas and nearly everything Bush is accused of doing nationally was originally documented locally, yet thoroughly ignored by the Associated Press during the 2000 election:
... I can't remember) of the two legislative bodies. Bush claimed sole credit anyway. Perhaps it worked out for the best with respect to the anti-Bush crowd: the reforms have failed miserably at improving high school graduation rates, and have actually forced more kids to dropout earlier. It became material for MoveOn.org's "Bush in 30 Seconds" contest. Doesn't help the kids much though.
I do not like anyone who accuses someone else of anything, especially lying, without any sort of proof.
Houston Press article, circa 1997: Bush used insider trading to sell his share of the Texas Rangers at a huge profit. Different article, same year: Bush pressured the Houston City Council to illegally confiscate a family's land via eminent domain in order to seal a sports stadium deal ("Enron Field", now sporting a new name of course but still referred to by all the locals as Enron Field) before presenting the deal up for a public vote.
Different Houston Press article, circa 1998: Bush's education reform bill first pass was entirely unworkable. The version that was signed into law was the bipartisan work of the leaders (Bob Bolluck and
I do not like anyone who feels there's *anything* self-righteous about enforcing numerous broken U.N. resolutions and freeing millions of enslaved people, as well as avenging the deaths of millions more.
Tangental but I have to respond. See "Rogue State" by William Blum: too many citations to list! The gist is that the USA is the most prominent breaker of UN resolutions and illegal supporter of the brutal regimes (including Hussein's) that have led directly to the death and enslavement of millions. However, while I agree that correcting the grievous wrongs (helping the Ba'ath Party take over in 1963, supporting Hussein throughout the 1980's with conventional, chemical and biological weapons, and allowing Hussein to (barely) retain his grip on power via the Food-For-Oil program) is the morally right thing to do, I'm hard-pressed to see the current Iraqi occupation as really being about paying for our sins. Virtually every non-US news source is carrying stories that show a far more cynical picture.
But that's neither here nor there, let's get back to Bush.
I do not like people make baseless accusations about someone they don't know.
Bush was born in Maine, grew up mostly in Texas, attended Yale, but generally stayed in Texas. His accent is probably genuine.
"I do not like unknowlegdable leaders who depend upon advisors to tell them what to do."
What kind of effective leader does not consult with his advisors? Answer: There is no such thing as an effective leader who doesn't consult with his advisors. You obviously have a lot to learn about leadership. Why do I know so much about it? Because I've spent years learning and practicing and honing leadership skills in the military.
The PP is almost certainly referring to Bush's overreliance on advisors. Bush is quoted in several AP articles as saying that he relies on his advisors so much that he feels it unnecessary to even read the newspaper or watch television news. He was genuinely shocked (sorry it's not an AP link, I lost that a while back) that members of Congress applauded when he bemoaned the PATRIOT Act's pending expiration during his State of the Union speech, just as he was rumored to be surprised to see people protesting him on his recent trip to Indonesia.
Furthermore, upon what grounds do you accuse Bush of having advisors that "tell him what to do"? I would love to see actual evidence that he does exactly what his advisors tell him to do.
The PP might be referring to the fact that in do
That's like hiring a builder to build your house, then hanging over them all the time and telling them they're doing it wrong.
You won't get very far arguing with this analogy. Ask anyone who has hired a builder to build their dream home.
How about instead, "That's like hiring a certified mechanic to fix your car, then insisting on getting under it with them and telling them they're doing it all wrong." ?
I would agree with you, except that employers require a degree nowadays for code monkeys. And, having a degree and the $20,000 debt to prove it, I can say that there is no way in hell minimum wage can recover that cost.
So if employers stopped requiring degrees I'd support your drive to lower IT wages. Especially when the employee quality priced at minimum wage causes the business to go belly up.
I think we might agree about who it is doing the complaining, but perhaps we should replace your key phrases:
...most of the crying seems to be coming from people who
Start with:
And begin replacing:
didn't have any savings,
"weren't born into the upper middle class"
made poor choices,
"majored in a high-growth field right before a huge -- and unpredicted -- change in the global economy"
and want something handed to them.
"yet still want to be capable of duplicating their parents' lifestyle."
We end with:
"...most of the crying seems to be coming from people who weren't born into the upper middle class, majored in a high-growth field right before a huge -- and unpredicted -- change in the global economy, yet still want to be capable of duplicating their parents' lifestyle."
Look, we're in agreement afterall!
you don't even want to imagine what a US bankruptcy would do to the world. Let's just simplify it and say that no one will be left standing and world-wide human suffering would be incalculable.
Have you by chance read "Rogue State" by William Blum? It's very "illuminating" about America's foreign policy objectives.
I actually agree with you that an American bankruptcy -- manifested as a US dollar that becomes literally worthless -- would bring the Western world down into a major Depression with probably 30%+ unemployment in most countries. However, I have to balance that with the fact that US foreign policy will become impossible to pursue, and as such many many people may prosper where they cannot do so now.
I believe "no one will be left standing" may also be true because the US will probably resort to violence to achieve its ends even after its currency is devalued in this hypothetical future. But if the US could be brought to heel and forced to weather its own Depression without resorting to war or fascism, we might ALL benefit.
Come on now, writing ANY type of program at 7 or 8 is AB-FUCKING-NORMAL, I don't care how smart you are, when you're 7 or 8 you're flying kites and playing little league, so I call bullshit. I call bullshit cause you think the dweebs and nerds here will give you credence and props cause you were one of the maybe 5, 10, 100? kids globally 'programming at 7 or 8'. Sorry Doogie Howser, you were learning to read and write at 7 or 8, and if you weren't, in all honesty, how normal of a child were you? Really?
Sigh.
I took a class in 3rd grade, at 8 years old mind you, to program Apple II BASIC. My elementary school of a few hundred students had about 25 in my class, all of us programming at age 8. Granted it was the "gifted" program and only two elementary schools had it in my old town, but I assure you that THOUSANDS of 8-year-old children learned how to program computers; many of them did NOT grow up to be computer geeks either. Do you remember all the books for teaching children how to program BASIC and eventually move up to Pascal? They were right next to the Visicalc manuals two shelves away of the UFO section at my local library.
if you use, or know how to use, or have heard of anything but Microsoft Windows, then you're NOT a typical user.
My brother has heard of Linux. My wife had heard of Unix before I met her. Everyone has heard of Macintosh.
I understand your frustration with assholes who reply "RTFM" to any user question. But I think you fail to grasp the point that a rather large segment of the population knows how to use computers at a much higher level than they are given credit for. Yes, throughout the 80's people picked up on DOS commands (many of which DO have relevance in the command-line Unix era).
You SAY we should get off our elitist high horse. Then you turn around and insult everyone who isn't you. Cognitive dissonance perhaps?
My uptime is 19 days as of right now, if you were wondering.
:)
I know you were trying to show that XP is significantly more stable than 98, NT4, etc., but perhaps you should pick a different metric.
My work machine was Redhat 7.1, and its uptime was 356 days I think. I was sad to turn it off, but I was moving floors.
My home machine is never turned off -- it takes too long to spin up all the SCSI drives -- and I typically run Debian 6 days/week, switching to '98 only long enough to do some schoolwork in Excel '97.
Yes, and outside IBM there's Japhar, Kaffe, and every other program that emulates the Java Virtual Machine. BTW I used to work with a guy on the team that made the Real-Time Java VM.
.class files and show output.
I meant JVM in that same sense that the OP did: the JRE. IBM's "JRE" -- as distributed for Linux, Windows, and AIX -- is Sun's "JRE".
People who continue to claim that IBM has a total clean-room JVM are right only in the sense that IBM has its own programs that can execute (most)
They are wrong in the sense that IBM's clean-room JVM won't actually do anything useful unless you have the rest of the licensed Sun JRE environment handy that has the code for java.lang.*, java.io.*, java.net.*, etc. Until IBM has all that code duplicated, they really don't have a clean-room JRE.
Is that better?
IBM knows an awful lot about Java. They wrote RTJava, they experimented with a Java->native compiler (abandoned due to excessive memory requirements for the available hardware at that time), they've got a clean-room JCE, an ORB robust enough for JNDI lookups hence EJB, they've got WebSphere, Portal, and WSAD/Eclipse (though Eclipse is its own story of a lot of lost money, it was supposed to be the Visual Studio killer in 2001).
But what they have not done is pay for the time to duplicate all the Objects and Interfaces in java.* and javax.*. It's just not worth it when you're already a Sun licensee. They do indeed make significant changes to the Sun JVM with every release of the IBM JRE (see now I'm using the terms in the more correct manner). But if Sun suffered corporate death right now IBM would NOT have a JRE available for forking as everyone likes to believe and say. IBM would instead have a long road ahead of it to either finish the work of GNU Classpath or write its own Classpath Objects.
Sigh. People say JVM to mean JRE and I follow suit, and then I get flamed by the ignorant.
Repeat after me: Sun's classes are the ONLY CLASSES IMPLEMENTING THE "STANDARD" IN COMMON USE TODAY.
Got that?
If you have a car, and it's got a part broken, and only one supplier in the entire world has the part to fix it, then it's a reasonable idea to say that your car is dependant on that one supplier. Car -> dependant on one part -> dependant on one supplier == car -> dependant on one supplier.
Like I said, more FUD, move along.
Fuck you. Come back when you've written 100,000+ lines production J2EE code on multiple J2EE servers using more than one JVM -- oops I meant JRE -- from more than one vendor.
I think I know what you're talking about: "webapps" in the loosest sense only in that they run on a J2EE server, that may not have an exposed web page interface of any kind. You talk to them with SOAP or EJB clients. They've got all the libraries from Java: JavaMail, EJB, JDBC, JCE, etc., plus they can use hundreds of other liraries from Apache and elsewhere.
That's the kind of thing I used to do for a living. Bored the hell out of me. I started calling it the "COBOL of the 21st Century".
I used to really like the J2EE environment. I changed my mind when I put up a web page in PHP, and found that it was far easier to debug what was going on and make changes. Email in PHP is a snap, even though it introduces a platform dependency; SOAP is even easier than the already easy Apache Axis API; database access is just like Perl's DBI. I was amazed how many libraries are in CPAN, and how easy it is to install them ("perl -MCPAN -e 'install Foo::Bar'). I even got angry at how much time we already spent on a full-blown J2EE "solution" that could've been done in Perl or PHP -- including the frontend! -- in 1/5 the time.
But back to your uses: strong typing IS handy for business-critical logic I agree, especially as these apps have to live "forever" (a.k.a. until the business goes under) and will probably see lots of turnover in the development staff over the years. (And come to think of it I forgot to add multi-threaded prototyping is a job Java does well.)
Wether classes in javax.* or java.* depend on other com.sun.* classes is irrelevant.
What matters is the the API of java.* and javax.* or free to be implemented by anyone. So it's a bit far fetched to call everything in javax.* proprietary. The implementation may be, bu the API sure isn't.
Let's talk reality and not theory: until a free implementation of all those classes is in common use (not 100% use, just more than 5% use), then all of the code that relies on those published APIs is still dependant on proprietary code. That's what RMS is trying to point out, and that's why GNU Classpath is necessary before your code is really "free" from Sun's ultimate control.
By analogy: Your car is broken and needs a part. You go to NAPA, they say you need a water pump. It so happens that only one water pump with the dimensions that fit your car is sold in the country, manufactured by company Foo, available for $3000. The NAPA salesman says "Sorry man, too bad you have to pay $3000 for your part." You tell him "I don't technically need that $3000 part. My car was designed so that any water pump that matches the published specs will work." He says, "But dude there's only one store with that part anywhere. Say what you want, but right now your car is designed to need part #98923-2A75F6 from Foo Inc. You gonna pay $3000 to repair this car or are you gonna get a new car?"
If you're going to argue word choice, at least spell "non sequitur" correctly. Regardless, for small-medium projects, Java isn't a good choice compared to the alternatives. Perhaps you should TRY LAMP first before disparaging it. Or put yourself in the shoes of a small business owner who needs a web site and doesn't have $20,000 to dedicate to software licenses or a Java professional's time.
... _X11TransSocketINETConnect: Can't get address for foo.bar
And to be blunt, the LAMP site is going to be up in 1/5 the development time and be far more responsive to the user (faster) than the equivalent J2EE site. The J2EE site can be improved to meet the LAMP site's speed, but it's an uphill battle all the way. It isn't until you need a LOT more than a basic site that J2EE starts to pay off, and my point is the market for such sites is tiny (even though it pays $$$ reasonably well) compared to the market that LAMP can satisfy.
Python, Qt, wxWindows, Tcl/Tk, etc., support WAY more platforms than Flash. Where I came from you weren't cross-platform until you supported AIX, Solaris, HP-UX, IRIX, Linux, Windows, and finally Mac OS X.
I say prefer Perl or PHP for quick-and-dirty database apps because they are very effective at being quick-and-dirty. Like fifteen minutes or so to make a program that can SELECT and do basic string or numeric manipulation before writing the data out to a flat file. In Java that would take about an hour to write, not due to JDBC but because you have to add external libraries for string manipulation. Perhaps if you tried Perl DBI you'd see why I say it's much faster. I say PREFER Perl/PHP, but if that's not available and JDBC/ODBC is, then use that before resorting to command-line scripts.
"Like Batik?" OK, let's see how even Batik does:
---snip---
$ java -fullversion
java full version "J2RE 1.3.0 IBM build cx130-20010626"
$ java -jar batik-1.5.1/extensions/batik-rasterizer-ext.jar batik-1.5.1/samples/mapSpain.svg
About to transcode 1 SVG file(s)
Converting mapSpain.svg to batik-1.5.1/samples/mapSpain.png
Exception in thread "main" java.lang.InternalError: Can't connect to X11 window server using 'foo.bar:543' as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at sun.awt.X11GraphicsEnvironment.(X11GraphicsEnviron ment.java:63)
at java.lang.Class.forName1(Native Method)
at java.lang.Class.forName(Class.java:134)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvir onment(GraphicsEnvironment.java:64)
at java.awt.Font.initializeFont(Font.java:277)
at java.awt.Font.(Font.java:361)
at java.awt.Font.getFont(Font.java:378)
at sun.java2d.SunGraphicsEnvironment.getBestFontFor(S unGraphicsEnvironment.java:585)
at java.awt.font.TextLayout.standardInit(TextLayout.j ava:628)
at java.awt.font.TextLayout.(TextLayout.java:479)
at org.apache.batik.gvt.text.BidiAttributedCharacterI terator.(Unknown Source)
at org.apache.batik.gvt.renderer.StrokingTextPainter. getTextRuns(Unknown Source)
at org.apache.batik.gvt.renderer.StrokingTextPainter. getBounds2D(Unknown Source)
at org.apache.batik.gvt.TextNode.getPrimitiveBounds(U nknown Source)
at org.apache.batik.gvt.AbstractGraphicsNode.getTrans formedPrimitiveBounds(Unknown Source)
at org.apache.batik.gvt.AbstractGraphicsNode.getTrans formedBounds(Unknown Source)
---snip---
(Oh look at that! It's an IBM JVM using Sun's code!)
Are you SURE you know what "headless Java" means?
I've been doing headless java graphics manipulation since 1.1.6 as part of my photo album and other tools. It got a bit easier in 1.4, but it's always been possible. For example: my house temperature diagram takes the collected data and renders to PNG or GIF depending on what your client claims to accept.
How? The only ways I've heard of are using an AWT replacement library ala Pure Java AWT, using code that doesn't depend on AWT at all, or setting up a virtual frame buffer X server. If there's another way I'd sure like to know. Even Batik relies on AWT, as I demonstrated to another poster.
IBM's JDK/JVM is Sun's JDK/JVM ported to IBM hardware with some enhancements for performance and added libraries (JCE, ORB).
IBM's JVM is Sun's JVM. IBM did NOT invent a new JVM, and IBM's JVM is completely dependent on the licensing status of Sun's JVM.
I worked for IBM in the WebSphere Tools group from 2000-2003. We got previews of the IBM JVM from Hursley every few months; we saw IBM's branded JVM a full year before the rest of the world did.
Please let this meme die. IBM did NOT invent a new JVM. Sun still controls all of the viable JVM's in use. Kaffe's JVM is the only clean-room JVM *I've* heard of, and it is never used inside IBM.
I think he means:
javax.*
java.net.*
java.io.*
java.security.*
java.awt.*
When you import java.awt.*, and call new java.awt.Frame(), sure enough you've suddenly gone deep into sun.* territory. Try it: run your program from the command line without an X11 server (or set an invalid DISPLAY value), catch and print the stacktrace of the java.lang.InternalError produced.
But particularly javax.* is strictly proprietary land, and that includes: servlets, portlets, JSPs, JavaMail, EJB, and JCE to start with.
It's a serious question. To paraphrase myself:
I've programmed Java J2EE for years. I am expert at the "best practices", performance tweaks, and real production-quality code, yet Java's utility is almost nonexistent beyond "it's what I [was] paid to write." Here is MY short list of things Java is useful for:
1) HUGE web sites. J2EE is a good solution: strong typing in the language, a security model that is complete from the database backend up to the Struts frontend, and clustering/failover with EJB 2.0.
COROLLARY: Small-medium sites should use LAMP and rely on redundant hardware to handle failover.
2) Applets. Since they run on "most" Unixes + Windows browsers, and despite the load time an applet is much friendlier to users than Flash. But you have to use Java 1.1 to ensure compatibility.
COROLLARY: Cross-platforms GUIs should use Python, Qt, wxWindows, Tcl/Tk, etc.
3) Unusual database applications for which only an ODBC or JDBC driver exists. JDBC is a rather mature standard (should be since it ripped off ODBC) that works pretty well. It's faster to write a few quick Statements and PreparedStatements and run them against a database than to use native tools that "have" 'different' ''ways'' of quoting strings.
COROLLARY: Prefer Perl or PHP if the database is supported.
4) Any application for which speed is not an issue. Yeah, Java can do everything any other language can do, and if this is the one easiest for someone to "think in" then they should use it.
COROLLARY: NEVER use Java to create or manipulate graphics from the command line. No JDK, EVER, has managed to do this despite five years of pleading from the professional programmers. Without a GUI Java goes belly-up on the first "new java.awt.Frame()". (And for you 1.4+ folks who think HeadlessException was a fine solution, it wasn't.)
Java was a great idea in 1995, but since then Java has been pushed as the Second Coming and it just hasn't measured up. The other languages have surpassed Java in every one of its primary marketing points: platform independence, performance, object-orientedness, ease of use.
So what jobs are you doing that make Java the best solution?
Not trying to flame, but genuinely curious.
FYI Blackdown, IBM et al CAN'T fork the Sun JDK unless Sun frees the code. And, as apparently thousands of Slashdotters are unaware, every other JDK except Kaffe+GNU is an independently licensed derivative of Sun's JDK.