Sorry about the mention of C/C++ when I was talking about coding paradigms for GUIs. I'm not a C/C++ coder by trade, so I'll gladly rescind my inclusion of them in my statement.
You actually make my point quite well without this, however.
Swing is built from the ground up on the MVC paradigm. If you do not use this paradigm when coding a Swing GUI, you'll effectively "disable" much of the work and code that has gone into Swing. No wonder people think it's a memory hog -- they're turning off half of its features.
Swing, when coded under an MVC architecture, operates quite smoothly and quickly. For those not "in the know" on MVC, let me give an example from my own experience:
In the old days of the AWT, if you wanted to display a list of data, the data was an integral part of the list widget. If you wanted to change the data that was displayed in the list, you would perform an operation on the list widget itself. Similarly, if you wanted the same data displayed in a table, you would need to replicate the data and insert it into your table.
In Swing, you use the model/view/controller architecture (MVC) to separate content from display. Actually that just accounts for model and view. The controller refers to the interaction between the data and the display. This control is typically bundled together with the view (display widget), but can be separated out rather easily.
The benefit of the MVC paradigm becomes readily apparent when you take one of the examples I used above. If you want to display the same data in a list and in a table, you don't need to replicate the data. You set the model for both of the GUI widgets to the same source. When you want to change this data, you simply change the source (the model) and both of the GUI widgets are automatically updated with the change (all Swing GUI widgets have listeners on their models that watch for changes).
With a subtle change in your coding model/paradigm, you can acheive _huge_ benefits in both coding time and performance by simply operating within the parameters that Swing was built on.
In regards to your question of using MVC with C, it would have to depend on the libraries that I was using in C. If the libraries that I was using were built to use MVC, then yes, I would consider this a better idea. If not, then no, I wouldn't use MVC. The use of MVC is really up to the individual's coding style, much like OOP in general. However, if you don't want to code using MVC, then don't choose a tool that is based on it.
If you don't like OOP, then you really don't want to program in Java. Similarly, if you don't like MVC, then you really don't want to code in Swing.
Look, I code Java for a living. I don't want to be a Java-evangelist (Javangelist?), but I've got a few problems with your post.
As far as getting the latest JDK in anything but Windoze, you can currently get Java2 v1.3 in Windoze, Solaris and Linux (with other ports on the way). The fact that they came out with the Windoze port first should be no real surprise to anyone: most folks are still using Windoze, hence there is more demand for upgrades on this OS than any other.
I've written Java stand-alone apps that are monumental in size and I've written Java server-based apps. I think that Java's main glory lies in server-side programming for web-enabled applications, but it is no slouch in the large stand-alone application market. You keep hearing people complain that Java eats up so much memory when all you want is a simple Notepad app. You need to understand what Java is doing and learn to work with/around it.
If you load a large app that utilizes many of the Swing widgets and interfaces, the memory load becomes a bit more understandable. On the large apps that I've written for Java, it has actually performed quite well (sub-second sorting and display on a 10K row table, etc).
Most of the comments that I see bashing Java are from people that have only taken a cursory pass at the language. If you try to code a Swing interface using the same paradigms as AWT (or C, C++, etc), you'll wind up with a slow monstrosity. If you code Swing the way it was intended to be coded (using the MVC architecture), you'll find that it's a remarkably powerful and full-featured GUI API.
At any rate...I'll get off my soapbox now. I really don't mean to tout Java as the be-all end-all of programming languages (it's not). But it is one of the better languages out there for the current direction of Internet-enabled programming.
The form's action URL is encrypted. When you're filling out the form, you're on an unencrypted page. This is fine. Anyone snooping will only see the form itself (blank) being sent to you.
When you submit the form back to the server, it's submitted via an encrypted URL. No one will see what you send back.
Slashdot Mirror
Sorry about the mention of C/C++ when I was talking about coding paradigms for GUIs. I'm not a C/C++ coder by trade, so I'll gladly rescind my inclusion of them in my statement.
You actually make my point quite well without this, however.
Swing is built from the ground up on the MVC paradigm. If you do not use this paradigm when coding a Swing GUI, you'll effectively "disable" much of the work and code that has gone into Swing. No wonder people think it's a memory hog -- they're turning off half of its features.
Swing, when coded under an MVC architecture, operates quite smoothly and quickly. For those not "in the know" on MVC, let me give an example from my own experience:
In the old days of the AWT, if you wanted to display a list of data, the data was an integral part of the list widget. If you wanted to change the data that was displayed in the list, you would perform an operation on the list widget itself. Similarly, if you wanted the same data displayed in a table, you would need to replicate the data and insert it into your table.
In Swing, you use the model/view/controller architecture (MVC) to separate content from display. Actually that just accounts for model and view. The controller refers to the interaction between the data and the display. This control is typically bundled together with the view (display widget), but can be separated out rather easily.
The benefit of the MVC paradigm becomes readily apparent when you take one of the examples I used above. If you want to display the same data in a list and in a table, you don't need to replicate the data. You set the model for both of the GUI widgets to the same source. When you want to change this data, you simply change the source (the model) and both of the GUI widgets are automatically updated with the change (all Swing GUI widgets have listeners on their models that watch for changes).
With a subtle change in your coding model/paradigm, you can acheive _huge_ benefits in both coding time and performance by simply operating within the parameters that Swing was built on.
In regards to your question of using MVC with C, it would have to depend on the libraries that I was using in C. If the libraries that I was using were built to use MVC, then yes, I would consider this a better idea. If not, then no, I wouldn't use MVC. The use of MVC is really up to the individual's coding style, much like OOP in general. However, if you don't want to code using MVC, then don't choose a tool that is based on it.
If you don't like OOP, then you really don't want to program in Java. Similarly, if you don't like MVC, then you really don't want to code in Swing.
--------------------------
Look, I code Java for a living. I don't want to be a Java-evangelist (Javangelist?), but I've got a few problems with your post.
As far as getting the latest JDK in anything but Windoze, you can currently get Java2 v1.3 in Windoze, Solaris and Linux (with other ports on the way). The fact that they came out with the Windoze port first should be no real surprise to anyone: most folks are still using Windoze, hence there is more demand for upgrades on this OS than any other.
I've written Java stand-alone apps that are monumental in size and I've written Java server-based apps. I think that Java's main glory lies in server-side programming for web-enabled applications, but it is no slouch in the large stand-alone application market. You keep hearing people complain that Java eats up so much memory when all you want is a simple Notepad app. You need to understand what Java is doing and learn to work with/around it.
If you load a large app that utilizes many of the Swing widgets and interfaces, the memory load becomes a bit more understandable. On the large apps that I've written for Java, it has actually performed quite well (sub-second sorting and display on a 10K row table, etc).
Most of the comments that I see bashing Java are from people that have only taken a cursory pass at the language. If you try to code a Swing interface using the same paradigms as AWT (or C, C++, etc), you'll wind up with a slow monstrosity. If you code Swing the way it was intended to be coded (using the MVC architecture), you'll find that it's a remarkably powerful and full-featured GUI API.
At any rate...I'll get off my soapbox now. I really don't mean to tout Java as the be-all end-all of programming languages (it's not). But it is one of the better languages out there for the current direction of Internet-enabled programming.
The form's action URL is encrypted. When you're filling out the form, you're on an unencrypted page. This is fine. Anyone snooping will only see the form itself (blank) being sent to you.
When you submit the form back to the server, it's submitted via an encrypted URL. No one will see what you send back.