Boy, I think it's high time I learned.NET, just so I could figure out what the whole problem is. As near as I can tell,.NET has a few objects/methods that generate HTML for web-application programming, and those aren't necessarily spitting out the proper client-side scripting code in the HTML code. Apparently that client-side script is J-script rather than Javascript, and likely has some active-X controls thrown in as well.
Am I right?
WTF is the problem then? I deal with web-application controls creating invalid or mal-formed HTML and scripting all the time from open-source development platforms. If you don't like the way a library does its output, use a different library.
SWT combines everything that's good about both AWT and Swing.
AWT used native OS widgets, but it took a least-common-denominator approach -- it only implemented those widgets that were common to all target platforms. Things like frames, and text fields. Many widgets that weren't available on all platforms, like, say, a combo-box, were not implemented. It had little to do with "crappy GUI libraries" and much more to do with *incomplete* GUI libraries.
Swing went the other route, offering a very full set of widgets that is, indeed, cross-compatible for all platforms. Unfortunately, it took a huge hit in performance to do this, as Swing draws the widgets using the JVM rather than making a JNI call to a native (and much faster) widget.
SWT offers the best of both worlds; it offers a robust and standardized library just like Swing does, but that library is, for the most part, a wrapper to a JNI call, just like AWT was. This gives a marked improvement to GUI performance using SWT over Swing, while at the same time offering nearly all the widgets that Swing does. Widgets not available on some platforms are emulated on those platforms, like Swing.
So, with SWT you have all the performance of native GUI widgets, but with the rich library of Swing. And SWT is cross-platform.
Now harking back to my original post, since some moderator thinks I'm a troll, I'll point out what I meant.
Swing is slow when compared to native widgets -- there is no way of getting around it. Talk all you want about how faster computers will sover the problem; native GUI programs will always outperform Swing programs.
Enter.NET's Common Language Runtime, which is really just a Java-ish bytecode. The big difference, the point that will keep Java from really competing with.NET, is that the CLR makes calls to native widgets, just like SWT. And, of bigger importance:.NET is beginning to cross platforms, just like Java. And *those* implementations of.NET are rumored to make calls to native widgets.
If.NET cross-platform-ness takes off,.NET will outperform Java when it comes to GUI applications, *regardless* of platform.
Sun has a big decision to make with Java: it can continue to push the Swing religion that it has built, or it can adopt a model similar to SWT. I clearly think they should persue the latter.
You may not have understood what was meant, but the rest of us did.;)
(S)he is saying that Swing is like HTML in that there is no guarantee on exact look and feel. You just say "widget here, widget there, work together, please" and, depending on the version of the VM being run, you may get different-looking widgets, albeit conforming to parameters you set like size, and background color, and the like.
The best example I can think of offhand is JColorChooser. Once upon a time you got a very small, handy little widget to select a color. I rather liked it. Nowadays you have this huge monstrosity with a hundred tabs and bells and whistles and the like, offering dozens of different *ways* of choosing your color. I rather hate it.
Until Sun drops Swing like a hot-potato, or reworks it using SWT thinking, Java will *never* beat.NET for client-side applications, even with a Java VM shipping on new Windows vers.
Java requires native-code widget performance and look/feel. Without it Java will not compete with.NET.
Re:XML is Great of Content Syndication and much mo
on
DTD vs. XML Schema
·
· Score: 1
There's nothing that says it *has* to be on port 80, but providing XML rather than binary data reduces both the initial development *and* the maintenance time required to release the data to the public.
Also, session level security is unnecessary in a public publishing environment.
Finally, with modern compression techniques, bandwidth isn't wasted.
Teh bastard killed Chewbacca! He will always be the worst author ever in my mind for that alone. Of course, his writing style certainly helps that assesment along quite nicely...
Very true, but there is also the issue of tampering with votes. Once identified and cast, electronic votes could easily be changed by someone with knowledge of the system.
Given that Firewire is as old as USB 1 and is still better (faster, simpler) than USB 2, not paying that price is a decision based purely on principles and one that costs users extra.
This translates to:
Firewire is as old as USB1. Firewire is still better (faster, simpler) than USB2.
He left out the subject (firewire) in the second half of the sentence; it (the subject, firewire) is clearly implied, however.
Slashdot Mirror
... of a rush job capitalizing on customer loyalty from a previous product.
You mean a non-Libertarian? :P
Ok, Dave, since you're the expert on the internet, give it to us straight: the internet was designed strictly for porn, right?
Boy, I think it's high time I learned .NET, just so I could figure out what the whole problem is. As near as I can tell, .NET has a few objects/methods that generate HTML for web-application programming, and those aren't necessarily spitting out the proper client-side scripting code in the HTML code. Apparently that client-side script is J-script rather than Javascript, and likely has some active-X controls thrown in as well.
Am I right?
WTF is the problem then? I deal with web-application controls creating invalid or mal-formed HTML and scripting all the time from open-source development platforms. If you don't like the way a library does its output, use a different library.
I see nothing to complain about here.
P.S. The grandparent's spelling of "intercompatible" is the correct spelling. So is the usage of the word.
I was just about to post this...
:(
Does anyone know if the video has been released on the net yet? My kids are watching cartoons and won't let me change the channel.
for a Theory of Everything. :)
But Swing has no guarantee on actual appearance.
SWT combines everything that's good about both AWT and Swing.
.NET's Common Language Runtime, which is really just a Java-ish bytecode. The big difference, the point that will keep Java from really competing with .NET, is that the CLR makes calls to native widgets, just like SWT. And, of bigger importance: .NET is beginning to cross platforms, just like Java. And *those* implementations of .NET are rumored to make calls to native widgets.
.NET cross-platform-ness takes off, .NET will outperform Java when it comes to GUI applications, *regardless* of platform.
AWT used native OS widgets, but it took a least-common-denominator approach -- it only implemented those widgets that were common to all target platforms. Things like frames, and text fields. Many widgets that weren't available on all platforms, like, say, a combo-box, were not implemented. It had little to do with "crappy GUI libraries" and much more to do with *incomplete* GUI libraries.
Swing went the other route, offering a very full set of widgets that is, indeed, cross-compatible for all platforms. Unfortunately, it took a huge hit in performance to do this, as Swing draws the widgets using the JVM rather than making a JNI call to a native (and much faster) widget.
SWT offers the best of both worlds; it offers a robust and standardized library just like Swing does, but that library is, for the most part, a wrapper to a JNI call, just like AWT was. This gives a marked improvement to GUI performance using SWT over Swing, while at the same time offering nearly all the widgets that Swing does. Widgets not available on some platforms are emulated on those platforms, like Swing.
So, with SWT you have all the performance of native GUI widgets, but with the rich library of Swing. And SWT is cross-platform.
Now harking back to my original post, since some moderator thinks I'm a troll, I'll point out what I meant.
Swing is slow when compared to native widgets -- there is no way of getting around it. Talk all you want about how faster computers will sover the problem; native GUI programs will always outperform Swing programs.
Enter
If
Sun has a big decision to make with Java: it can continue to push the Swing religion that it has built, or it can adopt a model similar to SWT. I clearly think they should persue the latter.
You may not have understood what was meant, but the rest of us did. ;)
(S)he is saying that Swing is like HTML in that there is no guarantee on exact look and feel. You just say "widget here, widget there, work together, please" and, depending on the version of the VM being run, you may get different-looking widgets, albeit conforming to parameters you set like size, and background color, and the like.
The best example I can think of offhand is JColorChooser. Once upon a time you got a very small, handy little widget to select a color. I rather liked it. Nowadays you have this huge monstrosity with a hundred tabs and bells and whistles and the like, offering dozens of different *ways* of choosing your color. I rather hate it.
Until Sun drops Swing like a hot-potato, or reworks it using SWT thinking, Java will *never* beat .NET for client-side applications, even with a Java VM shipping on new Windows vers.
.NET.
Java requires native-code widget performance and look/feel. Without it Java will not compete with
There's nothing that says it *has* to be on port 80, but providing XML rather than binary data reduces both the initial development *and* the maintenance time required to release the data to the public. Also, session level security is unnecessary in a public publishing environment. Finally, with modern compression techniques, bandwidth isn't wasted.
Heh... yeah, and the worst part is that he had no friends.
;)
On Slashdot, that is.
Teh bastard killed Chewbacca! He will always be the worst author ever in my mind for that alone. Of course, his writing style certainly helps that assesment along quite nicely...
:)
P.S. Yes, that's my name.
What about that R. A. Salvatore fellow? I hear people like his crap for some god-forsaken reason.
Yeah, the last thing we need is an old paedophile with a penchant for puns. :D
J.R.R. Tolkien! I mean, look, he has like 3 movies out right now! He's gotta be good or sumptin... ;)
Erm... I meant my post. And how I didn't get the joke in its parent. And stuff.
Ok, alright, I misread it and blew my wad early. Alright? Are you happy?
*hangs head in shame*
Very true, but there is also the issue of tampering with votes. Once identified and cast, electronic votes could easily be changed by someone with knowledge of the system.
I think this post demonstrates a need for a new moderation reason:
-1 Didn't Get Joke.
You clearly do not want karma! Read my .sig. :)
Seriously, I agree with you. The Sun JVM is a load of crap. It's slow and buggy.
Not that the MS VM is any better. Sure it's faster, and works better, but it doesn't always work with pure Java code.
I think a better ruling would be to force Microsoft to comply with Java's VM standards.
PHP kicks Perl syntax around a bit, but Python knocks PHP down for the count.
It's available for DOS! 'nuff said. :D
Firewire is as old as USB1. Firewire is still better (faster, simpler) than USB2.
He left out the subject (firewire) in the second half of the sentence; it (the subject, firewire) is clearly implied, however.
You'll get modded offtopic, I predict. :)