I guess I'm not communicating very well. How are the Zend IDE, or JBuilder, consumer applications? They're for programmers, and the latter is for Java programmers in particular. My definition of successful hasn't changed at all. My definition isn't "impossible to meet". The systems that are commonly used to develop GUIs for consumer applications all qualify - there are quite a few of them around, page through an industry mag for the ads.
I don't think you mentioned moneydance in your original message. I'll check it out, thanks.
As for FUD: I do Java development, and have done since the first beta JDKs became available. I have no interest in spreading FUD about Swing, or anything else. However, I happen to have high standards when it comes to GUIs, because my clients have high standards. Just about any Visual BASIC programmer with minimal experience can produce a GUI that's better than 90% of the Swing apps I've seen, though, and that's a problem.
I simply didn't say accurately what I meant in my first message. I probably shouldn't have spent so much time trying to explain the details; here's the point:
There doesn't seem to be any successful shrinkwrap GUI software being sold to consumers, as an independent product, that uses Java.
That's not an arbitrary set of criteria; what it indicates, to me, is that the market hasn't found the Swing UI to be competitive, in its current form, compared to native UIs. And based on my personal experience with these apps, I can see why.
There's also the fact that it although it's apparently possible to create an acceptable UI with Swing, such apps don't seem to be the norm. The problem with that is that developers (including me) don't want some kind of low-level GUI construction kit; we want something high-level that'll create a professional-looking UI without a great deal of work. The Swing apps on Sourceforge seem to prove that it doesn't succeed at this.
Having listened to people defending Swing, the best two conclusions I can come to are (a) Swing has potential and will continue to improve; and (b) it's very good, if not the best, for cross platform apps, but it still doesn't stack up too well against native Windows UIs (and apparently requires a lot of work to even come close).
What'll change my mind is seeing an app where I don't have to make apologies for it to consider it acceptable. The first Java GUI app that did that for me was Eclipse - which doesn't use Swing.
But Netscape apparently convinced them that native look and feel was more important than cross platform implementation.
I think, at the time, that Netscape was probably correct. I think you're quite right about this:
If we'd had a pure Java GUI relying only on simple graphics primitives we could have build arbitrary interfaces that worked - cross platform - from the beginning. They would have been slow at first, and then rapidly gotten better (as Swing has).
...but I don't think people would have waited around for that to happen. From Netscape's perspective, Java had to present a convincing face to Windows users from day one.
Netscape set Java up and Microsoft knocked it down for a while at least...
AWT had a lot to do with it, but performance was also a big issue, independent of AWT. The average user's machine in '97 or so would not have been able to run any significant Java GUI apps - the CPU and memory requirements were too great. I predicted (to my friends) Corel's office suite failure (circa '97), based on their very first announcement.
The Java UI has been evolving since then. It's improved a lot, but as a developer who wants to have UI stuff handed to me on a platter:), I still have issues with it. Judging by the state of the market, I'm not the only one.
Netscape only set Java up by acknowledging the realities of its market, i.e. the dominance of Windows. So in that sense, yes, Microsoft's presence made it harder for Java to break in. But I still don't think that Java's problems on the client really had that much to do with Microsoft, beyond Microsoft's very existence as a monopoly.
Author of Learning Java, O'Reilly & Associates and the BeanShell Java scripting language.
Congratulations on a great package. I've used BeanShell, and like it a lot. I evaluated it, for a client, as a Java scripting solution against Jython, Kawa (Scheme), JScheme, and Rhino. Choosing BeanShell ended up being something of a no-brainer, although that wasn't obvious to me initially. The deciding factor ended up being the degree of compatibility with Java, especially when it comes to data type integration. All of the others had issues in this area.
I particularly liked BeanShell's optional typing - it's what I think Javascript should have been. Where were you when Netscape was looking for a scripting language?;)
(Not to diss Brendan Eich; Javascript is very cool in its own way - it's just perhaps not the ideal scripting language for Java.)
I think you have it backwards. A great deal of the world (at least in the US) is like that. The companies that aren't, are exceptional, and they often do quite well as a result.
The original poster's comment rung completely true for me. There are plenty of "executives" out there that have been promoted up because they were good salespeople, or good schmoozers, or whatever. These people know nothing about the wise use of human resources, about strategic thinking, and a host of other things that they really ought to have at least a little clue about. People like this can survive for long periods of time, using various strategies, and one of them is chewing up and spitting out the unsuspecting employees beneath them.
I'm a consultant so I get to see a fair variety of management behavior. You couldn't pay me enough to be an employee at many of the companies I consult to.
but Java clients are good when it comes to remote administration.
I prefer web clients for that purpose - Webmin, IPCop, Netsaint/Nagios are a few that come to mind. Most of these interfaces don't need really need the full interaction of a typical gui app.
One reason I like Java on the server side, though, is that it's allowed me to sell clients on the idea of Linux application servers (as opposed to Windows). The Java gives them the feel that they're not going out on too much of a limb, since they know they can run the same stuff on their Windows servers if they have to.
You should check out SGI's Rhino(GPL/LGPL) system admin package
Thanks, I will.
There may be more packages that try to glue the two ends, but this is the only one I know about.
Heh, well I've worked on projects that did that with CORBA, but I try not to think too much about those...:)
I use JEdit on my Linux laptop. I don't consider it good enough to replace any of the editors I use on Windows.
I agree Jdiskreport is nice, but (a) it's quite small and special-purpose and (b) it's written by a self-proclaimed GUI expert. As I've said elsewhere, it certainly seems to be true that with some effort, you can produce decent guis with Swing. The Sourceforge Swing projects I've seen, though, don't give nearly as good an impression.
Netbeans - hmm. I used it for a number of months. To me, the comparison between Netbeans and Eclipse is a really good argument against Swing. JBuilder is a bit slicker, but as I mentioned in another response, it's too incestuous - Borland used Swing because there are benefits to eating your own dogfood, especially for programmer tools in the Java world which tends towards everything being 100% Pure Java.
The Oracle DBA tools - these aren't applications that people buy because they freely choose to - they chose the database, they're stuck with the tools.
I haven't used ThinkFree Office or Zend. You're right that a successful office suite written in Java would prove me wrong. I'll try ThinkFree, who knows, maybe I'll like it more than every other Swing app I've ever tried, but somehow I doubt it.
I think there's an expectations issue here. I'm judging Swing guis against Windows guis, and I think Swing comes off second best. Maybe my standards are unrealistic, but the point is when choosing a way to write a gui app, most people don't want to hear excuses about how they have to put up with an inferior end product if they choose a certain approach.
There is a fundamental difference between a code generator (widget builder) and a compiler.
Actually, "fundamentally", a widget builder and a compiler are the same thing. You're taking a narrow view of code generation, though. Widget building is only one reason to generate code, and one that I agree doesn't seem to be done well in Java at the moment.
In general, a compiler is a program which accepts statements in a source language and outputs statements in a target language. All widget builders have some source language; some quite explicitly have a special-purpose text-based language, but even environments that don't have this, store their GUI layouts in some kind of data structure. They're nevertheless translating a source language, it just may not be human readable (or if you like, the GUI layout itself is the source language).
In some cases, these GUI description languages are interpreted rather than compiled. A good example of an interpreted GUI description language is HTML. I'm just mentioning this to try to un-narrow the scope of the discussion, because when I say "code generation", I don't mean "generating Java code from widget layout descriptions". That's just one small, narrow application of code generation, and not a good one on which to base your opinions about code generation.
Now I can address this:
however for now any code generation in Java is bad and is usually the reason for slowness in a modern Java application.
You're wrong, but it's probably because of how narrowly you're viewing code generation. In fact, regarding performance, code generation can often improve performance, when it's used as an alternative to doing things dynamically at runtime using reflection.
One particular area where your "it's all bad" theory doesn't hold up is where you do the generation yourself, rather than relying on some kind of general-purpose generator. That allows you to control for performance issues.
As I mentioned, Java programs necessarily include a lot of boilerplate code, and it's quite easy to abstract this out to a higher-level meta-definition language. Books have been written about this, for example, Program Generators with XML and Java.
For a trivial example, think of defining a bunch of bean-style properties on a class - what do you gain by writing that boilerplate code by hand? The answer is nothing, except a lot of unnecessarily verbose code.
For somewhat less trivial examples, try this paper on Explicit Programming
. One example given in that paper is of a nine-line program that generates a 100-line class which includes standard implementations (chosen by the developer, not the tool) of five different patterns.
I'm not suggesting that people rush out and begin using experimental academic tools in their everyday work. But it's quite easy to write code to generate code, actually. Once you find yourself with a few thousand lines of code that were generated from a meta-description that's a couple hundred lines long, you might start seeing my point. That's exactly what I do with persistent objects, to name one application I use - having chosen a persistent object mechanism, I generate code to manage persistence from a meta-description of the object structures and relationships.
And in fact, you can use this approach to generate your own GUI code, too, the way you want it.
Perhaps in 10 years I will recind my comment about code generators in Java.
Or, you could start using them yourself now, and get a 10-year jump on the rest of the industry...
BTW, you mentioned Emacs earlier, so there's a slight possibility you have some familiarity and perhaps appreciation for Lisp. Well, developers who use Lisp and Scheme don't necessarily do code generation per se, but they use macros, which give them similar capabilities built right into the language. Java has nothing that powerful, but nothing stops you from providing a similar capability for yourself.
I don't use Eclipse to write (much) code for me, but I do use it to refactor code for me, and to navigate through code.
Using a visual editor (widget machine) to do GUI code is just a Bad Idea.
I think that in practice, and with most tools, you're quite right. But I think that's a reflection of the immaturity of such tools, and of the poor separation and interface, in code, between the widgets and their application-level functionality.
IMHO all code including and especially GUI code should be written by hand.
I think I can prove you wrong: do you write everything in machine code? Or assembler? No? But there was a time when you could find people saying that everything should be written in assembler, for much the same reasons as you're proposing. There are many repetitive patterns even in manual code, which can often lend themselves well to being abstracted out and machine-generated. In Java in particular, generating code can make quite a difference to an application: an enormous percentage of Java code is boilerplate. If you insist on writing all that by hand, you're hobbling yourself for no good reason.
I'll agree that in an ideal language, you shouldn't have to be generating a lot of code to run alongside the code you're writing by hand. But Java is not an ideal language. Since Java doesn't really support metaprogramming very well, generating code provides a way to start with a higher semantic level and still end up with Java code.
You seem like you're just mindlessly bashing Macs. If that's true, it's okay with me; I just want to know if this is an informed opinion or a troll.
Not intended to be a troll - but it was a response to what was effectively a troll. The limited functionality claim was effectively made by the message I responded to: no command shell, no security permissions (all code running as root). So, it seems like the way to hack it would be to find an ISP foolish enough to use it, get an account, and take it from there...
I'll add another limitation, which is no multithreading. I can't imagine a Webstar server doing a good job of being a web application server, i.e. where it's doing something much more substantial than serving static pages. I'll admit I haven't tried it. But I've done a fair amount of server-oriented system level coding, and am very familiar with concurrency issues and the various kinds of APIs on multiple platforms, and cooperative multitasking is not going to cut it in any kind of high-demand situation.
For some testimonials, try this page: "iTools/Apache has been much more reliable than WebSTAR. WebSTAR used to tank (especially on the SSL side) twice a month at least. Under heavy load the SSL side tended to crash"; or, "I had...the same 'tanking' problems which [put me] twice a month in front of the computer to fix what had to be fixed."
4D even promoted WebStar v4.5 as "more stable" - an interesting tacit acknowledgement. Perhaps Mac vendors are just more honest... BTW, WebStar V is multithreaded, so clearly 4D are aware of the problems inherent in the prior Mac architecture.
Whether there is one Mac webserver or one hundred million, secure is secure is secure.
I think you're missing the logical point on a number of fronts. The Fort Knox example is actually a good one - no-one knows how secure it is in reality, because it hasn't suffered any serious attacks. For all we know, it might have a horrible Achille's heel. You can only make claims and assumptions, and "impenetrable" is a clearly invalid claim. Impenetrable to what? The U.S. Army? A fleet of killer radio-controlled vehicles?
As I said, you could have made a claim about the security of Windows, back around '96, and the empirical evidence would not have disagreed with you, simply because net hackers were not yet seriously targeting Windows machines. Similarly (almost conversely), the fact that you didn't succeed in cracking WebStar means very little. Without a hacker population attacking WebStar with the same gusto that they attack Windows and Unix servers, the empirical evidence is of limited value.
That all said, I'm perfectly willing to concede some basic points: a biggy is that use of the Pascal string convention is certainly less likely to suffer from buffer overruns than the C convention, and that's a major source of holes right there. I'm not saying that Webstar isn't more secure in general or by default than your average C-language web server on Unix - it may very well be. But so what? It's a bit like saying that living in Siberia, you're less likely to be mugged. True, but irrelevant to most people.
Beside, a big problem with the original message I responded to was the implication that other servers couldn't be configured to be as secure. That, I dispute strongly. None of the servers I maintain have ever been hacked, even when boxes on either side of them have been. I know of many other servers that have never been hacked. The way to be secure is to have an understanding of what makes you secure, and to act on that, not to blindly purchase something because it says "secure" on the box, shut your eyes, and hope for the best. I've maintained secure Windows servers, secure Linux servers, secure BSD servers (various flavors). I'm tempted to say something like "software doesn't make boxes insecure, people make boxes insecure." It's close to the truth.
It was really the entire combination of specious claims and invalid assumptions that caused me to react to the original message.
Too incestuous. Borland used Swing because there are benefits to eating your own dogfood, especially in the Java world which tends towards everything being 100% Pure Java. But why aren't there popular consumer apps written with Swing?
I suppose you could argue that it's too new, but the problem with that is that if it does eventually become widely used in GUI application development, the Swing of that time won't be the one that's being used today, and it's the one that's available today that I'm talking about.
What IDE do you use? The only one I've come across that I think comes close to Eclipse is IDEA. Since Eclipse is free, it's at least worth a look. The refactoring support in release 2.0 is very nice. Download here. And anyway, it might make you realize how bad Swing really is.;oP
You're cutting Swing all sorts of slack implicitly in your message. First of all, yes it's more viable for internal applications where you can control the hardware it runs on, and tell your users they just have to live with whatever shortcomings it might have. But you'd have to show me successful commercial shrinkwrap Swing apps, or popular open source Swing apps, before I would change my mind. Small special-purpose apps (the NetZero dialer comes to mind) don't really count - I'm talking about apps that people purchase because they want to use the app itself.
AWT's problems were a poorly-designed API, which were only remotely related to having native widgets. The whole architecture of AWT was suspect.
I'm not saying Java UI hasn't improved. In the pre-Swing days, a Java UI was an oxymoron. That's certainly changed. But I think it has a long ways yet to go, and apparently the industry in general agrees.
You're right about Sun, but I think they're pretty much like any big company in that respect. The real problems only arise when one company gets too much power and has too much control over something. I don't think that's the case with Java, which has some other powerful forces in its universe - like IBM.
Sooner or later Linux will be a problem for Sun too.
Sure, but they're going to have a hard time doing anything about it, since they can't control the licensing of Linux the way they can with Java. Linux has built-in guarantees over any companies gaining too much control over it, which is one of its biggest attractions - it's a force for responsible corporate behavior, like competition and public accountability.
Sorry, I guess I was thinking of the kind of creationist that believes the Earth is 4000 years old, etc. That's usually coupled with a large set of irrational beliefs denying evidence that's been collected by a large body of scientists around the world, including many Christians and members of other religions.
You're right about the difficulty most US residents have in travelling to other countries (other than Mexico or Canada). Although for many Americans, I suspect it's much more of a psychological block than a financial one - you can fly New York to London for $265 round trip, on Virgin Atlantic.
Of course, it'll be quite a bit more than that from Texas - which I'm sure does go a long way towards explaining the much higher level of fundamentalism in the central US states, which are physically isolated in a way that only has an equivalent in some other physically large countries like perhaps China, India, Brazil, Russia.
That might be fine if the US really was isolationist, but unfortunately (for you too), the US has a strong military presence in the Middle East, primarily to protect its oil interests. The combination of isolationism and global interventionism makes for some strange policies, and has some unfortunate consequences.
I last used JBuilder at version 5. That's when I switched to using Eclipse. I agree it's possible to make acceptable UIs with Swing, but judging by how few of them are around, it requires a great deal of effort. That's not a sign of having good UI development capabilities.
You (The USA) apparently have a guilty conscience. I was talking about creationists. I don't credit the creationists and their ilk with creating US foreign policy, although they might influence it. However, I've found that people with beliefs like that are far more likely to have uninformed views about the world outside the US, and see things purely in us vs. them terms. Never having travelled outside the US doesn't help. Parochialism is bad; religious extremism tends to foster the worst kind of parochialism.
I'm a guru-level Microsoft-basher, but the fact that Java sucked for the development of GUI apps was not Microsoft's fault. Including pure Java in IE probably wouldn't have done much to change that - the embedding of Java in browsers was always a Frankenstein's monster kind of deal, anyway, and had little to do with the development of real Java apps.
Java still sucks for GUI development today. I use it heavily for server-side development, and I've worked with plenty of Java UIs. The only acceptable Java UI system I've ever seen is IBM's SWT framework, as used in Eclipse. Swing UIs are borderline at best, and AWT isn't even worth discussing. In Sun's defense, creating a decent fully cross-platform UI (without depending on native widgets) is a tough problem. SWT's use of native widgets makes a whole lot more sense - Sun should take note.
Of course, none of this changes the fact that Microsoft did everything in its monopoly power to crush Java. Abandoning Visual J++ and then insulting their userbase with J# and "Jump to.NET" showed that when it comes to crushing the competition, even Microsoft's own customers better not get in the way.
Do creationists realise that their beliefs are really only a USA phenomenon?
That's a tough one, since US creationists are only vaguely aware of the existence of a world outside the USA, and what awareness they do have tends to be about which parts of it need to be carpet-bombed to eliminate the infidels (oops, I mean pagans, getting my religious extremism confused there...)
I wonder if the behavior of organizations like eWeek will eventually change, as it becomes clear that when some questionable behavior is noticed and discussed publicly, that said organization can't just get away with quietly trying to hide the original problem?
I think a big part of the behavior of execs at these companies - aside from the fact that they're businessmen, not journalists, and wouldn't know a journalistic ethic if it bit them in the MBA - is that the execs don't "feel" the criticism, because they don't participate in online forums, so at best, hear about it secondhand, and certainly don't feel threatened by it - they don't perceive it as "real".
Before you scoff, I have an example. It was reported on TV the other day that Jeff Skilling, ex-CEO of Enron, currently hangs out at some chic club in Houston, essentially crying in his beer and asking people if they believe his claims of being innocent of wrongdoing.
Regardless of Skilling's innocence or guilt, he clearly feels a great deal of shame (or is doing a decent job of pretending that). This guy's a Harvard-educated MBA, he's taught essentially that ethics are secondary to profit, and how to put that into practice, so why the shame?
Because he has been publicly attacked and judged, in venues that he and his peers understand and participate in themselves - in this case, the major media, especially TV and print.
When we have executives who've grown up IM'ing their buddies from their bedrooms, who have a feel for online media, will they be as averse to being excoriated in those media, as current execs are to the old media? Are we simply seeing a bunch of tired old companies trying to hide their heads in the sand and pretend that no-one sees what they're doing? When it's finally realized that this doesn't work, will it stop?
Oh wait. This is the real world, and I'm talking about interminably idiotic human beings. Please ignore everything I've just said.
Millions of people continue to buy Macs to use as personal workstations - my g/f is one such, although having some technical savvy, she's running OS X. Nobody buys Macs to use as corporate web servers (the subject here is the hacking of NBC, remember?)
What functionality do you want.
Hmm, let's see... How about, say, multithreading? The ability to play DVDs without skipping if you so much as move the mouse?
Look, the old Mac OS had a cutting edge GUI when it came out, in 19-frickin-80-something. It had various usability innovations. But on the technical capabilities of the OS, it hasn't cut it for a long, long time.
The entire premise of "secure Mac OS" web servers is based on two factors:
Reduced functionality tends to improve security. Mac OS web servers have extremely limited functionality, therefore are more secure by default.
Mac OS web servers are not widely used (a serious understatement, hardly anyone uses them), and are thus not targets for attacks. There was a time when it was quite safe to put an unprotected Windows web server on the Internet, for the same reasons, and we all know how secure they turned out to be.
It would thus be accurate to say "The Mac OS web server may be a good choice if you are clueless, do not know how to administer secure servers, and want to run an OS that is now officially obsolete."
Why speak of "hackers" like this? Are they still a sub-culture, marginalized?
Are you kidding? In the United States, the kind of hacker that breaks into other people's systems get arrested and do jail time, if they get caught. Yeah, they're a marginalized sub-culture, like most other criminals under the law.
Following the trend set by "oligopoly", where an "o" was stolen from "monopoly" simply to aid in pronunciation, the word you want might be "polyopoly" -
or perhaps "poliopoly", but that sounds a bit too much like someone who is infected by multiple polio viruses.
Slashdot Mirror
I don't think you mentioned moneydance in your original message. I'll check it out, thanks.
As for FUD: I do Java development, and have done since the first beta JDKs became available. I have no interest in spreading FUD about Swing, or anything else. However, I happen to have high standards when it comes to GUIs, because my clients have high standards. Just about any Visual BASIC programmer with minimal experience can produce a GUI that's better than 90% of the Swing apps I've seen, though, and that's a problem.
There doesn't seem to be any successful shrinkwrap GUI software being sold to consumers, as an independent product, that uses Java.
That's not an arbitrary set of criteria; what it indicates, to me, is that the market hasn't found the Swing UI to be competitive, in its current form, compared to native UIs. And based on my personal experience with these apps, I can see why.
There's also the fact that it although it's apparently possible to create an acceptable UI with Swing, such apps don't seem to be the norm. The problem with that is that developers (including me) don't want some kind of low-level GUI construction kit; we want something high-level that'll create a professional-looking UI without a great deal of work. The Swing apps on Sourceforge seem to prove that it doesn't succeed at this.
Having listened to people defending Swing, the best two conclusions I can come to are (a) Swing has potential and will continue to improve; and (b) it's very good, if not the best, for cross platform apps, but it still doesn't stack up too well against native Windows UIs (and apparently requires a lot of work to even come close).
What'll change my mind is seeing an app where I don't have to make apologies for it to consider it acceptable. The first Java GUI app that did that for me was Eclipse - which doesn't use Swing.
I think, at the time, that Netscape was probably correct. I think you're quite right about this:
If we'd had a pure Java GUI relying only on simple graphics primitives we could have build arbitrary interfaces that worked - cross platform - from the beginning. They would have been slow at first, and then rapidly gotten better (as Swing has).
Netscape set Java up and Microsoft knocked it down for a while at least...
AWT had a lot to do with it, but performance was also a big issue, independent of AWT. The average user's machine in '97 or so would not have been able to run any significant Java GUI apps - the CPU and memory requirements were too great. I predicted (to my friends) Corel's office suite failure (circa '97), based on their very first announcement.
The Java UI has been evolving since then. It's improved a lot, but as a developer who wants to have UI stuff handed to me on a platter :), I still have issues with it. Judging by the state of the market, I'm not the only one.
Netscape only set Java up by acknowledging the realities of its market, i.e. the dominance of Windows. So in that sense, yes, Microsoft's presence made it harder for Java to break in. But I still don't think that Java's problems on the client really had that much to do with Microsoft, beyond Microsoft's very existence as a monopoly.
Author of Learning Java, O'Reilly & Associates and the BeanShell Java scripting language.
Congratulations on a great package. I've used BeanShell, and like it a lot. I evaluated it, for a client, as a Java scripting solution against Jython, Kawa (Scheme), JScheme, and Rhino. Choosing BeanShell ended up being something of a no-brainer, although that wasn't obvious to me initially. The deciding factor ended up being the degree of compatibility with Java, especially when it comes to data type integration. All of the others had issues in this area.
I particularly liked BeanShell's optional typing - it's what I think Javascript should have been. Where were you when Netscape was looking for a scripting language? ;)
(Not to diss Brendan Eich; Javascript is very cool in its own way - it's just perhaps not the ideal scripting language for Java.)
The original poster's comment rung completely true for me. There are plenty of "executives" out there that have been promoted up because they were good salespeople, or good schmoozers, or whatever. These people know nothing about the wise use of human resources, about strategic thinking, and a host of other things that they really ought to have at least a little clue about. People like this can survive for long periods of time, using various strategies, and one of them is chewing up and spitting out the unsuspecting employees beneath them.
I'm a consultant so I get to see a fair variety of management behavior. You couldn't pay me enough to be an employee at many of the companies I consult to.
Well, yeah, but I code for a living...
but Java clients are good when it comes to remote administration.
I prefer web clients for that purpose - Webmin, IPCop, Netsaint/Nagios are a few that come to mind. Most of these interfaces don't need really need the full interaction of a typical gui app.
One reason I like Java on the server side, though, is that it's allowed me to sell clients on the idea of Linux application servers (as opposed to Windows). The Java gives them the feel that they're not going out on too much of a limb, since they know they can run the same stuff on their Windows servers if they have to.
You should check out SGI's Rhino(GPL/LGPL) system admin package
Thanks, I will.
There may be more packages that try to glue the two ends, but this is the only one I know about.
Heh, well I've worked on projects that did that with CORBA, but I try not to think too much about those... :)
I agree Jdiskreport is nice, but (a) it's quite small and special-purpose and (b) it's written by a self-proclaimed GUI expert. As I've said elsewhere, it certainly seems to be true that with some effort, you can produce decent guis with Swing. The Sourceforge Swing projects I've seen, though, don't give nearly as good an impression.
Netbeans - hmm. I used it for a number of months. To me, the comparison between Netbeans and Eclipse is a really good argument against Swing. JBuilder is a bit slicker, but as I mentioned in another response, it's too incestuous - Borland used Swing because there are benefits to eating your own dogfood, especially for programmer tools in the Java world which tends towards everything being 100% Pure Java.
The Oracle DBA tools - these aren't applications that people buy because they freely choose to - they chose the database, they're stuck with the tools.
I haven't used ThinkFree Office or Zend. You're right that a successful office suite written in Java would prove me wrong. I'll try ThinkFree, who knows, maybe I'll like it more than every other Swing app I've ever tried, but somehow I doubt it.
I think there's an expectations issue here. I'm judging Swing guis against Windows guis, and I think Swing comes off second best. Maybe my standards are unrealistic, but the point is when choosing a way to write a gui app, most people don't want to hear excuses about how they have to put up with an inferior end product if they choose a certain approach.
Actually, "fundamentally", a widget builder and a compiler are the same thing. You're taking a narrow view of code generation, though. Widget building is only one reason to generate code, and one that I agree doesn't seem to be done well in Java at the moment.
In general, a compiler is a program which accepts statements in a source language and outputs statements in a target language. All widget builders have some source language; some quite explicitly have a special-purpose text-based language, but even environments that don't have this, store their GUI layouts in some kind of data structure. They're nevertheless translating a source language, it just may not be human readable (or if you like, the GUI layout itself is the source language).
In some cases, these GUI description languages are interpreted rather than compiled. A good example of an interpreted GUI description language is HTML. I'm just mentioning this to try to un-narrow the scope of the discussion, because when I say "code generation", I don't mean "generating Java code from widget layout descriptions". That's just one small, narrow application of code generation, and not a good one on which to base your opinions about code generation.
Now I can address this:
however for now any code generation in Java is bad and is usually the reason for slowness in a modern Java application.
You're wrong, but it's probably because of how narrowly you're viewing code generation. In fact, regarding performance, code generation can often improve performance, when it's used as an alternative to doing things dynamically at runtime using reflection.
One particular area where your "it's all bad" theory doesn't hold up is where you do the generation yourself, rather than relying on some kind of general-purpose generator. That allows you to control for performance issues.
As I mentioned, Java programs necessarily include a lot of boilerplate code, and it's quite easy to abstract this out to a higher-level meta-definition language. Books have been written about this, for example, Program Generators with XML and Java.
For a trivial example, think of defining a bunch of bean-style properties on a class - what do you gain by writing that boilerplate code by hand? The answer is nothing, except a lot of unnecessarily verbose code.
For somewhat less trivial examples, try this paper on Explicit Programming . One example given in that paper is of a nine-line program that generates a 100-line class which includes standard implementations (chosen by the developer, not the tool) of five different patterns.
I'm not suggesting that people rush out and begin using experimental academic tools in their everyday work. But it's quite easy to write code to generate code, actually. Once you find yourself with a few thousand lines of code that were generated from a meta-description that's a couple hundred lines long, you might start seeing my point. That's exactly what I do with persistent objects, to name one application I use - having chosen a persistent object mechanism, I generate code to manage persistence from a meta-description of the object structures and relationships.
And in fact, you can use this approach to generate your own GUI code, too, the way you want it.
Perhaps in 10 years I will recind my comment about code generators in Java.
Or, you could start using them yourself now, and get a 10-year jump on the rest of the industry...
BTW, you mentioned Emacs earlier, so there's a slight possibility you have some familiarity and perhaps appreciation for Lisp. Well, developers who use Lisp and Scheme don't necessarily do code generation per se, but they use macros, which give them similar capabilities built right into the language. Java has nothing that powerful, but nothing stops you from providing a similar capability for yourself.
Using a visual editor (widget machine) to do GUI code is just a Bad Idea.
I think that in practice, and with most tools, you're quite right. But I think that's a reflection of the immaturity of such tools, and of the poor separation and interface, in code, between the widgets and their application-level functionality.
IMHO all code including and especially GUI code should be written by hand.
I think I can prove you wrong: do you write everything in machine code? Or assembler? No? But there was a time when you could find people saying that everything should be written in assembler, for much the same reasons as you're proposing. There are many repetitive patterns even in manual code, which can often lend themselves well to being abstracted out and machine-generated. In Java in particular, generating code can make quite a difference to an application: an enormous percentage of Java code is boilerplate. If you insist on writing all that by hand, you're hobbling yourself for no good reason.
I'll agree that in an ideal language, you shouldn't have to be generating a lot of code to run alongside the code you're writing by hand. But Java is not an ideal language. Since Java doesn't really support metaprogramming very well, generating code provides a way to start with a higher semantic level and still end up with Java code.
Not intended to be a troll - but it was a response to what was effectively a troll. The limited functionality claim was effectively made by the message I responded to: no command shell, no security permissions (all code running as root). So, it seems like the way to hack it would be to find an ISP foolish enough to use it, get an account, and take it from there...
I'll add another limitation, which is no multithreading. I can't imagine a Webstar server doing a good job of being a web application server, i.e. where it's doing something much more substantial than serving static pages. I'll admit I haven't tried it. But I've done a fair amount of server-oriented system level coding, and am very familiar with concurrency issues and the various kinds of APIs on multiple platforms, and cooperative multitasking is not going to cut it in any kind of high-demand situation.
For some testimonials, try this page: "iTools/Apache has been much more reliable than WebSTAR. WebSTAR used to tank (especially on the SSL side) twice a month at least. Under heavy load the SSL side tended to crash"; or, "I had...the same 'tanking' problems which [put me] twice a month in front of the computer to fix what had to be fixed."
4D even promoted WebStar v4.5 as "more stable" - an interesting tacit acknowledgement. Perhaps Mac vendors are just more honest... BTW, WebStar V is multithreaded, so clearly 4D are aware of the problems inherent in the prior Mac architecture.
Whether there is one Mac webserver or one hundred million, secure is secure is secure.
I think you're missing the logical point on a number of fronts. The Fort Knox example is actually a good one - no-one knows how secure it is in reality, because it hasn't suffered any serious attacks. For all we know, it might have a horrible Achille's heel. You can only make claims and assumptions, and "impenetrable" is a clearly invalid claim. Impenetrable to what? The U.S. Army? A fleet of killer radio-controlled vehicles?
As I said, you could have made a claim about the security of Windows, back around '96, and the empirical evidence would not have disagreed with you, simply because net hackers were not yet seriously targeting Windows machines. Similarly (almost conversely), the fact that you didn't succeed in cracking WebStar means very little. Without a hacker population attacking WebStar with the same gusto that they attack Windows and Unix servers, the empirical evidence is of limited value.
That all said, I'm perfectly willing to concede some basic points: a biggy is that use of the Pascal string convention is certainly less likely to suffer from buffer overruns than the C convention, and that's a major source of holes right there. I'm not saying that Webstar isn't more secure in general or by default than your average C-language web server on Unix - it may very well be. But so what? It's a bit like saying that living in Siberia, you're less likely to be mugged. True, but irrelevant to most people.
Beside, a big problem with the original message I responded to was the implication that other servers couldn't be configured to be as secure. That, I dispute strongly. None of the servers I maintain have ever been hacked, even when boxes on either side of them have been. I know of many other servers that have never been hacked. The way to be secure is to have an understanding of what makes you secure, and to act on that, not to blindly purchase something because it says "secure" on the box, shut your eyes, and hope for the best. I've maintained secure Windows servers, secure Linux servers, secure BSD servers (various flavors). I'm tempted to say something like "software doesn't make boxes insecure, people make boxes insecure." It's close to the truth.
It was really the entire combination of specious claims and invalid assumptions that caused me to react to the original message.
I suppose you could argue that it's too new, but the problem with that is that if it does eventually become widely used in GUI application development, the Swing of that time won't be the one that's being used today, and it's the one that's available today that I'm talking about.
What IDE do you use? The only one I've come across that I think comes close to Eclipse is IDEA. Since Eclipse is free, it's at least worth a look. The refactoring support in release 2.0 is very nice. Download here. And anyway, it might make you realize how bad Swing really is. ;oP
AWT's problems were a poorly-designed API, which were only remotely related to having native widgets. The whole architecture of AWT was suspect.
I'm not saying Java UI hasn't improved. In the pre-Swing days, a Java UI was an oxymoron. That's certainly changed. But I think it has a long ways yet to go, and apparently the industry in general agrees.
If only! Where do you think Homer got it from?
Sooner or later Linux will be a problem for Sun too.
Sure, but they're going to have a hard time doing anything about it, since they can't control the licensing of Linux the way they can with Java. Linux has built-in guarantees over any companies gaining too much control over it, which is one of its biggest attractions - it's a force for responsible corporate behavior, like competition and public accountability.
Sorry, I guess I was thinking of the kind of creationist that believes the Earth is 4000 years old, etc. That's usually coupled with a large set of irrational beliefs denying evidence that's been collected by a large body of scientists around the world, including many Christians and members of other religions.
You're right about the difficulty most US residents have in travelling to other countries (other than Mexico or Canada). Although for many Americans, I suspect it's much more of a psychological block than a financial one - you can fly New York to London for $265 round trip, on Virgin Atlantic.
Of course, it'll be quite a bit more than that from Texas - which I'm sure does go a long way towards explaining the much higher level of fundamentalism in the central US states, which are physically isolated in a way that only has an equivalent in some other physically large countries like perhaps China, India, Brazil, Russia.
That might be fine if the US really was isolationist, but unfortunately (for you too), the US has a strong military presence in the Middle East, primarily to protect its oil interests. The combination of isolationism and global interventionism makes for some strange policies, and has some unfortunate consequences.
I last used JBuilder at version 5. That's when I switched to using Eclipse. I agree it's possible to make acceptable UIs with Swing, but judging by how few of them are around, it requires a great deal of effort. That's not a sign of having good UI development capabilities.
Java still sucks for GUI development today. I use it heavily for server-side development, and I've worked with plenty of Java UIs. The only acceptable Java UI system I've ever seen is IBM's SWT framework, as used in Eclipse. Swing UIs are borderline at best, and AWT isn't even worth discussing. In Sun's defense, creating a decent fully cross-platform UI (without depending on native widgets) is a tough problem. SWT's use of native widgets makes a whole lot more sense - Sun should take note.
Of course, none of this changes the fact that Microsoft did everything in its monopoly power to crush Java. Abandoning Visual J++ and then insulting their userbase with J# and "Jump to .NET" showed that when it comes to crushing the competition, even Microsoft's own customers better not get in the way.
That's a tough one, since US creationists are only vaguely aware of the existence of a world outside the USA, and what awareness they do have tends to be about which parts of it need to be carpet-bombed to eliminate the infidels (oops, I mean pagans, getting my religious extremism confused there...)
I wonder if the behavior of organizations like eWeek will eventually change, as it becomes clear that when some questionable behavior is noticed and discussed publicly, that said organization can't just get away with quietly trying to hide the original problem?
I think a big part of the behavior of execs at these companies - aside from the fact that they're businessmen, not journalists, and wouldn't know a journalistic ethic if it bit them in the MBA - is that the execs don't "feel" the criticism, because they don't participate in online forums, so at best, hear about it secondhand, and certainly don't feel threatened by it - they don't perceive it as "real".
Before you scoff, I have an example. It was reported on TV the other day that Jeff Skilling, ex-CEO of Enron, currently hangs out at some chic club in Houston, essentially crying in his beer and asking people if they believe his claims of being innocent of wrongdoing.
Regardless of Skilling's innocence or guilt, he clearly feels a great deal of shame (or is doing a decent job of pretending that). This guy's a Harvard-educated MBA, he's taught essentially that ethics are secondary to profit, and how to put that into practice, so why the shame?
Because he has been publicly attacked and judged, in venues that he and his peers understand and participate in themselves - in this case, the major media, especially TV and print.
When we have executives who've grown up IM'ing their buddies from their bedrooms, who have a feel for online media, will they be as averse to being excoriated in those media, as current execs are to the old media? Are we simply seeing a bunch of tired old companies trying to hide their heads in the sand and pretend that no-one sees what they're doing? When it's finally realized that this doesn't work, will it stop?
Oh wait. This is the real world, and I'm talking about interminably idiotic human beings. Please ignore everything I've just said.
What functionality do you want.
Hmm, let's see... How about, say, multithreading? The ability to play DVDs without skipping if you so much as move the mouse?
Look, the old Mac OS had a cutting edge GUI when it came out, in 19-frickin-80-something. It had various usability innovations. But on the technical capabilities of the OS, it hasn't cut it for a long, long time.
The entire premise of "secure Mac OS" web servers is based on two factors:
It would thus be accurate to say "The Mac OS web server may be a good choice if you are clueless, do not know how to administer secure servers, and want to run an OS that is now officially obsolete."
Are you kidding? In the United States, the kind of hacker that breaks into other people's systems get arrested and do jail time, if they get caught. Yeah, they're a marginalized sub-culture, like most other criminals under the law.
see subj
Following the trend set by "oligopoly", where an "o" was stolen from "monopoly" simply to aid in pronunciation, the word you want might be " polyopoly " - or perhaps "poliopoly", but that sounds a bit too much like someone who is infected by multiple polio viruses.