According to Mitnick, a speedy trial would have meant going to court with unprepared counsel and possibly getting put away for a large part of his life. So he decided to sit around in jail a while.
Most of the time, when you free native resources owned by a Java object, you do so in the "finalizer" that the GC calls when it's about to free your object. A finalizer is analogous to a C++ destructor and is called ClassName.finalize().
Never rely on finalizers for reclaiming resources or your program's behavior is undefined. You can't control when the garbage collector will run the finalizer, and if there's plenty of memory it may never run. Scroll down to the middle of this page for more details on why you shouldn't release any sort of limited system resource in finalizers. (Except for memory.)
If Bill Gates came in and posted an insightful criticism on the open source world, and the GPL, and free software, and he could be genuinely determined to be the *real* Bill gates at Microsoft, would he be modded away? Would he receive the same harsh criticism?
I'm sure if Bill Gates bothered to show up here he'd be moderated up to 5 even if all he wrote was "FUCK YOU".
The problems you mention aren't JBuilder's fault, you just had a lazy developer ! The default visibility of generated variables is a project configuration setting (at least it is in JBuilder 4, I can't imagine they've taken it away in later versions).
Thanks for telling me that; now I have to strangle him! Actually he's the original developer of the project, and he's the CEO of the company now, so I shouldn't complain too much about his code. He was trained as a physicist and can hold 15 things in his head at once so some of his stuff is absolutely incomprehensible. The parts of his code that were written by JBuilder are almost a pleasure to work with in comparison!
As for the default naming (jLabel3 etc): how do you suppose the designer would figure out the correct name on its own ? As far as I know there's no mind-reading plugin yet. Just rename the thing after dropping it on your design area using the property editor.
Sigh... Can't it at least suggest memorable default names, like panelFred and buttonBarney? I've never seen anyone who used a visual designer even bother to change the names of those damn things. When they're messing with the designer, they often have it in their head that nobody will ever have to edit the code by hand anyway, so they don't care if it looks like diarrhea.
If you manually write all GUI code you can probably avoid a few variable declarations for layout managers if you always use their default settings (e.g. myPanel.setLayout(new BorderLayout())). But runtime this doesn't make a difference, the layout manager is still in scope for the entire lifetime of the instance.
Yeah, at runtime from the JVM's point of view the scope is no different. But I don't care about the JVM's point of view. From my point of view, it's in my face! Which code would you rather maintain? This:
myPanel.setLayout(new BorderLayout())
or this:
BorderLayout borderLayout4 = new BorderLayout(); ... ... myPanel = new Panel(); ... ... borderLayout4.setHgap(5); ... ... myPanel.setLayout(borderLayout4); ... ... borderLayout4.setVgap(5);
Imagine all this stuff repeated for ten BorderLayouts, two GridLayouts, and four FlowLayouts! With everything mixed up with and on top of everything else! And you should see what it can do with a GridBagLayout! Holy crap! Code like that should just be sent to India.
JBuilder's designer hasn't given me any problems.
Actually, it's pretty impressive how much manual editing of the source file is tolerated by the damn thing. It even incorporated a custom layout manager we wrote with no problems, and does a passable job with our custom components. But as time goes by, more and more human-generated changes creep in- and eventually the code gets so far from what JBuilder wrote that it gets hopelessly confused and the Designer won't work anymore. If you use one of these things, by all means try to keep the classes segregated from the manually edited code, for the benefit of both the Designer and the other human developers. But by all means do not assume from the outset that you will be successful in doing so, because chances are you won't be.
About the only thing we have to change manually is a call to a GridBagConstraints constructor that didn't exist before JDK 1.2, since we have to be Mac OS 9 compatible.
Ah, so you know the nightmare I live with every day! Damn that Mac OS 9! We're supporting it for six more months and after that I can use all the Java 2 methods that pop up in the autocomplete! Woo hoo!
Hmm, I can't get the first statement from the second. In Java, you shouldn't ever need to recompile code unless the interface it uses is changed. So a jar you make that uses swt.jar shouldn't need to be recompiled unless it uses JNI itself. No different than AWT.
Actually (after thinking about it a little more) it's really a matter of whether you consider the SWT libs to be part of the JVM, or part of the distributed binary for your program.
If it's part of the JVM, then your code that's compiled against it is a 100% portable. But unless Sun incorporates the SWT libs into the JVM (as has been suggested to them by many people) then you have to distribute it yourself, which means each platform gets a different binary distribution, differing only in the SWT implementation. Hence my misleading comment about portable binaries.
Most Java apps I've seen bundle their own JRE instead of trusting whatever's on the target machine anyway, so different binaries are going out the door anyway and the point is largely moot.
So, the question is, would you listen to the racist if he said "If you use these bullets, they'll go into the nigger without breaking up his internal parts and still kill him dead as a doornail"?
Well I might be willing to put up with an offensive description if I'm really that desperate and the information isn't available elsewhere. I guess it's all a matter of what you're willing to put up with. As long as the topic is ammunition and not politics, I might put up with it, keeping in mind that he's an idiot if he talks like that.
The point behind the question is that my experience with racists shows that race always comes up in conversation, from simpe things like "I went to the gas station and sand nigger behind the counter carded me" to more complex things like "I ate a burger at this place but all the tables I saw looked like a nigger picnic. I won't go there until they clean the place up." Remove the race references and the statements themselves are making valid points that any one of us would say, the only difference being the racial references.
Yeah, that's usually true. However notice that in this case the guy managed to squeeze out an entire post with no references at all to chinks, wops, kikes, or sand niggers! And he still got a harsh reaction, which was entirely based on his username and signature- i.e. at who he was, not at what he was saying- which, in this particular case, happened to be completely mundane and inoffensive.
Your mention of the Linux and Solaris SWT bindings as separate bindings raises interesting questions about Java and the degree of Java Political Correctness.
Yes, see my rant in this thread about Sun and its Political Correctness regarding Java. Whenever Sun is faced with a choice between practicality and ideology, they seem to choose ideology every time.
AWT/Swing doesn't have or need bindings because 1) they are 100% Java or 2) to the extent that they are not 100% Java and need to JNI down to something, that something is distributed with the Java VM that appears on each machine, so you don't need to distribute any platform specific AWT/Swing bindings with your app.
That's a fairly good description- the native bindings for AWT (and Swing, which depends on AWT) are hidden within the JVM. Actually AWT uses a peer layer which is not present in SWT. Buttons in AWT are represented by a java.awt.Button. The java.awt.Button class never changes- it's the exact same class across Linux, Windows, Solaris, etc. The class accesses platform specific button resources via an instance field it has that implements the java.awt.peer.ButtonPeer interface. On Windows the implementing class is a sun.awt.windows.WButtonPeer. This way each class has a globally unique definition. In SWT, they didn't bother with the peer layer at all. The thing that changes as you move from one platform to another is the very org.eclipse.swt.widgets.Button that is manipulated by your client code- there is a separate version of that class for each platform (they're careful to always keep the public methods the same). Sun would never do something like that. They meticulously avoid having classes change from one platform to another and in fact they seem enamored of the idea that a class name should get you a unique class out of some global repository. (Of course, there's usually a million versions of a class anyway, but whatever.) IBM could have incorporated a peer layer into SWT rather easily, but I guess they decided it wasn't worth the bother.
SWT needs separate bindings for each target platform -- it becomes like wxWindows or Qt in that regard. If you want to distribute an SWT app, you need to distribute those bindings, or tell your users how to install the right binding on their machine. But then you are into a bindings model rather than a true "write once, run everywhere" model.
Well this is also the case with AWT and Swing, which have their platform-specific bindings hidden right within the JVMs- so you don't even realize it's a problem! There isn't a Java GUI library on earth that won't at some point require a JNI layer somewhere. But the native layer of SWT is extremely thin- IBM claims there's "nothing interesting in the native code" and that it's a 1-1 function mapping. If they could convince Sun to incorporate SWT bindings into the JVMs along with the AWT stuff, then it would be on pretty much equal footing with Sun's GUI toolkits. Fat chance though, as Sun has already put all its eggs in Swing's basket. They're known for hissing at SWT whenever the topic arises.
My remark about J++ may not be completely off the mark. To the extent that C# is in reality J++, and that WFC was transformed to System.Windows.Forms, and to the extent the Mono is going down the bindings road to port System.Windows.Forms (to answer your question, 2002 - 1997 = 5 years to get Linux and Solaris versions of WFC), and to the extent that Miguel gets lambasted for doing what he is doing, why should Eclipse/SWT get a free pass for doing a similar thing with Java?
It's not really a valid comparison, for several reasons. First of all there's intent. It's not as if IBM created SWT with the goal of destroying Swing. They just needed a GUI library with which to write Eclipse after they determined (correctly) that Swing sucked too much to be seriously considered for developing Eclipse. SWT was a means to an end, not an end in itself. Now they're saying, "we wrote this nice GUI library for our app, and if you want to use it for your own purposes, here it is." Compare that to Microsoft's predatory behavior with J++, which was carefully designed to discourage portable code by seducing you with visual designers that only worked with WFC. Often J++ users didn't even realize they were writing Windows-specific programs because Microsoft was doing such a good job of obfuscating that simple fact!
As for platform specificity- Swing runs on all platforms, and so does SWT- except that the Windows implementation is nicer and further along than the others. So what? Are you suggesting that IBM doesn't want Eclipse to be successful on Linux? The Windows implementation has probably received more of IBM's resources so far because of what their user base is- there's nothing Windows specific in the design of SWT per se. Anyone is free to help on improving the other bindings, which by the way are still part of SWT, in a way that Mono is not part of Microsoft's.NET implementation! If Microsoft were implementing Mono themselves, I'd be more impressed with your "5 years" statistic. But face it, Mono owes its existence to Java, because it conveniently (if perhaps unconvincingly) undermines the argument that.NET is not cross platform like its competition. (You might say.NET owes its existence to Java as well, but that's another thread.) But Mono faces an uncertain future. It is resting on a bed of Microsoft patents. And the non-Windows version of.NET will never be as nice, not ever. Microsoft has made that much pretty clear. How much longer than Java do you think Mono will survive? Mono is cool, and I salute the Mono team for the effort they're putting into it. I wish them all the luck in the world. And I might play around with it. But no way would I let my career hang on its continued existence or relevance, because I don't trust Microsoft.
Hmm, I can't get the first statement from the second. In Java, you shouldn't ever need to recompile code unless the interface it uses is changed. So a jar you make that uses swt.jar shouldn't need to be recompiled unless it uses JNI itself. No different than AWT.
Yeah, I misspoke, sort of. Strictly speaking, you don't really need to recompile, or you shouldn't, since IBM is careful to keep the public methods of each SWT implementation the same on each platform.
If you want to sleep well at night, however, I recommend doing the recompile anyway to make sure they didn't miss anything! Practically speaking, for other reasons you may be running a separate build script for each version of your program anyway, so it's probably just easier to do it in each build script instead of separating it out into a separate step.
SWT seems like a cool idea, but with its close coupling to Windows (Windows is the farthest along -- the other bindings seem to be "under construction"), how is this different than (gasp, choke, gag) J++?
Oh come on! At least SWT bindings for Linux and Solaris exist, they can exist in the first place, and you can assist in their development. How long do you think you would have to wait for Microsoft to release Linux and Solaris versions of the Windows Foundation Classes?
The Internet isn't pretty, it isn't clean and it isn't proper. Just because Granny can't keep up with the times and learn how to operate machinery properly doesn't mean that Microsoft's gotta bow down and de-evolve their OS even further towards the lowest common denominator.
No, but they can at least refrain from running servers by default on a simple install of XP Home. You have to consider who your users are when adding features and deciding which ones are turned on right out of the box.
Could one, for instance, now compile a Java program using the SWT library to a native binary using GCJ, so it could be run without using a JVM?
Yes.
SWT takes a middle ground between the extremes of AWT and Swing, and abandons a sacred cow of Sun's- the idea that the same binary must run on all platforms without any modifications. This attitude has really been an albatross around Java's neck and is the reason everyone thinks that Java applications have to be cheesy- because Sun demands that they must be equally cheesy everywhere!
AWT takes the approach that ALL widgets are drawn by the native layer. This isn't a bad idea, except that if no native widget is available (like a slider, or tree), AWT refuses to improvise one at the Java level. This is why there are no sliders or trees in AWT, even on platforms like Windows where native widgets for both are present, because there's some platform out there somewhere that doesn't have them. Maybe AIX or something, who knows. AWT is strictly lowest-common-denominator and that's why everyone hates it.
People bitched and moaned. So Sun went straight to the opposite extreme with Swing, which refuses to even consider the native widgets. Instead, it uses Java level methods to draw pictures of them to fool you. This means that Swing can offer you a "pluggable look and feel", so you can have Motif buttons on Windows, or "Metal" buttons on the Mac! Except nobody cares. Microsoft promptly kicked Swing in the nuts by introducing skins with XP, so it becomes obvious what is really Windows and what is pretending to look like Windows but can't keep up. And Swing suffers greatly from the second system effect- it's overengineered as hell. A Hello World in Swing gobbles up 20 MB of overhead- mostly classes loading and initializing themselves. In fact, Swing is why AWT is still alive. AWT sucks, but you can run a program that lasts for more than a couple minutes with it. Writing stable applications with Swing is a real art. (It is in AWT too, but only because Sun has pretty much left AWT flapping in the wind with minimal improvements, maintenance, or bug fixes. Since Swing came along, AWT has been treated like a red-headed stepchild by Sun.)
SWT is much more like AWT than Swing, except that it takes a practical middle ground- something Sun doesn't seem capable of doing at all! It offers you a nice set of native widgets. If a slider or a tree isn't available on some platform, they draw a picture of one for you. This might make sliders and trees look funny on platforms that lack sliders and trees, but you would expect things to look funny on those platforms. People using Windows (i.e. most of them) aren't bothered by any of this.
This sacrifices binary compatibility. Each platform has its own version of the SWT library. For example, there is a Windows specific swt.jar and a swt.dll that goes with it, and there is a Solaris version of swt.jar and a native swt.so library that it uses. Even though the libraries are implemented completely differently, the public interfaces are the same. So if you develop a program against the Windows version of the SWT library, you won't have any problem compiling against the Linux version. (Although I've heard that SWT blows on Linux, but that was a while ago and I don't know what the current state is.)
SWT doesn't abstract much away from you, unlike AWT, where you are separated from the low level GUI details by a leaky abstraction. In SWT you have to write the frigging event loop yourself! (Which is not a big deal- it's a while loop, usually two lines.) There are a few other gotchas, and you absolutely have to test a SWT program on all platforms you're releasing for, but in practical terms the same was always true for AWT because of the leakiness of its abstraction. SWT at least doesn't pretend that you don't have to worry about this stuff.
This means you have to compile and test a program three times before releasing it, once for Windows, once for Linux, once for Mac. This violates Sun's sacred cow of binary compatibility. But when you're releasing a Java application, you're going to make separate installers for each platform anyway, because you have to bundle a JVM for everybody. So it's not really a big deal, unless you're writing an applet- and applets went the way of the dodo long ago in no small part because of AWT and Swing!
With SWT, you can make really nice, professional looking programs. The layer between you and the OS is very thin (JNI). If your program looks silly or stupid, it's YOUR fault. When the user changes the skin in XP, your SWT programs will pick up the change right away. In fact, it isn't even obvious that you're not using C! You can write your stuff in Java and actually get away with it! So that's why I think SWT is the future (if there is any future left anymore) of Java on the client, and why I will be junking AWT/Swing completely when starting new projects.
No, but whose fault is it if you buy a pair of pants with "KICK ME" emblazoned on the backside, and you complain that people kick you all the time, even though you didn't possess the technical inclination to look on the ass for any signs, markings or invitations to random passerby?
Or the technical ability to even realize such markings are there! "KICK ME" can be written in languages that you just don't know! OR it can be written in invisible ink that is only visible with special goggles. My grandma isn't going to run a portscanner on her machine as soon as she unwraps it on Christmas. I mean, give me a break. It's beyond reasonable to suggest that she as an end user should even have to. Stuff happening at the TCP/IP layer on a default XP install is the responsibility of Microsoft. Period.
...I think that Borland's Jbuilder IDE it's the best so far. It's slower than eclipse, but it offers much more features. And... i'm so used to it:)....
Please tell me you don't use JBuilder's Designer. We had a developer who liked to use it a lot. He stopped a year and a half ago, and we're still mopping up the damage! Everything looks like
flowLayout1 = new FlowLayout();
label2 = new Label();
panel3.add(button8);
panel6.add(panel4);
label2.setText("Welcome!");
panel7.setLayout(borderLayout6);
and it goes on and on like this for a couple hundred lines! With not a single local variable in sight- JBuilder declares them all as instance fields! Oy! Unless you keep these window classes tightly segregated from the manually edited code, and ONLY touch them with the Designer, they become unmaintainable monstrosities. Adding a single button or textfield is inordinately painful. As for changing the layout- you might as well do a rewrite.
I've become good at deobfuscating JBuilder's crap. First remove the 30 BorderLayout fields, FlowLayout fields, etc. Then gradually rename the "panel8", "button3", to sensible names, and remove redundant ones as you find them. Then get some graph paper out, and go slowly through the jbInit() method until you see what's going on. This will let you get rid of 90% of the instance fields in the class.
Layout code is tedious, but there's no excuse for not doing it manually unless you're not worried about maintainability. In fact, one thing I like about IntelliJ IDEA is the lack of a GUI designer.
The thing is, if we censor this fuck, then we're accused of being "un-American" or some shit like that.
Maybe not "un-American", since shouting down unpopular opinions seems to be in vogue here nowadays.
But really, you shouldn't censor people just for holding unpopular opinions, especially when they're not even expressing those opinions at the moment. Even a white supremacist might have something to teach you, as long as you know which topics to avoid. I might listen to a racist if he's talking about how to polish a gun or clean a deer, even though I know not to listen when the topic of race comes up.
Sometimes I hate being libertarian, we're _supposed_ to defend the rights of ignorant sister-kissing cousin-fscking inbred so-and-so's like this.
It amazes me how many people are attracted to libertarianism and yet don't understand the concepts behind it. Yeah, freedom for other people can sometimes suck, especially when they're expressing an unpopular opinion, but the censoring of unpopular opionions is the first step down a dangerous path.
And to all the people complaining about the modding up of this guy's post- the moderation applies to the post, not its author. This particular post has no offensive content that I can see. (Although I wouldn't waste mod points on it, because it really doesn't merit an "Insightful".) And the guy is at least honest about who he is. I wish all racists would announce up front who they were.
I'm a programmer and I think the world would be a better place without the damn things. It ran fine without them up until the 1940s.
WTF? Were you around before the 1940s? I'll have you know I've seen real film footage of the world before the 1940s, and from the looks of it, I'd say it was a far cry from "fine". In fact, I think "miserable" would be a better word for it!
And how in the world did the civil rights movement get included in your list? Were you at Strom's birthday party last month?
No one's "hacking into" any computers. Do you "hack into" the webserver when you request a page? Your computer has to be listening on port 139 for these messages to have any effect.
Spoken like a true geek. However, you are extending an abstraction into higher levels than is necessarily appropriate. From my grandma's perspective, the TCP/IP level mechanism is irrelevant. She wants to know where the hell these weird messages are coming from.
Just because XP automatically installs a service that listens on port 139 doesn't or shouldn't necessarily mean that I as a naive user am going to be expecting packets at that port. Taping a "KICK ME" sign to someone's butt doesn't mean they want to be kicked either. Not everyone views these things strictly at the level of the socket API.
Thanks for your friendly advice. Actually I don't know why I wasn't chosen (a domestic squabble case came up, and I answered their questions honestly). I don't know why. You would think I would be a great juror.
Jury duty is normally an interruption in a software developer's work flow. But you can turn jury duty to your advantage if you follow these simple tips, which worked for me:
1. Bring a laptop on which you can do work. If your job cannot be done on a laptop with no network connection then you are screwed and should take the alternate approach, finding excuses to get out of jury duty.
2. Find the outlet in the jury pool room, and sit next to it. Arrive early if you have to. Your laptop battery will not keep you going long enough, so you must plan to run on AC power. If there is only one outlet, you must not let anyone else sit next to it. To avoid problems, you may want to arrive early or bring an extension cord.
3. Pretend to be an idiot during voir dire. This is crucial. Courts take a dim view of software development work in the jury box. The place you want to spend your time is the jury pool room, not the courtroom. It's easy to minimize the time you spend in the courtroom. During the voir dire process, be sure to express at least one of the following opinions whenever any question is asked of you:
Of course I'd be more willing to believe a police officer!
I wouldn't follow a judge's instructions if I knew the law was wrong.
Well duh, rights aren't for guilty people!
This case personally interests me very much and I can't wait to be on the jury!
Of course he's guilty! Why else would they arrest him?
Although I'm not a lawyer, I'm familiar with the law from what I've read on Slashdot.
I am biased against all races.
You may still get picked for a jury despite your best efforts. If this happens to you, make sure you have something dry and technical to read, like a printout of some API documentation. (Don't bring anything more interesting along or you'll end up reading that instead.) Most judges don't care if you catch up on your reading during the procedural lulls that consume most of the court's time, when your attention isn't needed. People read romance novels on juries all the time. But I think an open laptop would be pushing it.
4. Don't make any friends. Remember, you're going to jury duty to get lots of work done, not to socialize! The reason jury duty is great is that it forces you to work because there's nothing else to do and no one interesting to talk to! No meetings, phone calls, emails, or Slashdot. You have to take advantage of this valuable time. If you make friends in the jury pool room, you defeat the entire purpose of not trying to get out of jury duty!
Seriously, I got called for jury duty and I got an amazing amount of work done that week. It was unpleasant and uncomfortable as hell while I was there, but afterwards it was definitely worth it.
Ever since he lost his presidential bid McCain's been the Democrats Democrat (yes, I know - He's a Republican in name only). His Stances and choices usually support what the Democrats want, and often exceeds their wildest dreams.
You know, I thought this petty viciousness against McCain had ended after he lost the primary in 2000. Can you offer any evidence to back up your assertions, or are you just parroting what someone told you on the radio?
I disagree with McCain on most issues. But McCain is an honorable man. He has certainly never stooped to dirty tricks like some other people I can think of.
texts like MORE EVIL: Here, have all the.NET crap you want, and we better see this entering your curriculum or else you lose your discounts and we audit your asses. are just speculation and ment to be insulting for MS and.NET using people.
How in the world do you take this to be insulting to people using.NET? It has nothing to do with them. It's an issue of disclosure. If I'm paying lots of money to a university for a degree, I expect that my curriculum is being chosen by professors who evaluate technologies on their own merits, not because of bullying by a vendor. Maybe they would have taught C# even without extraneous pressure from Microsoft. Who knows?
If you really think "java" or "C#" or whatever language you get on your university is more important than the real point of what you get taught: "OO development using an imperitive language", you don't know jack about computer science and how it is taught to students.
I agree with this sentiment, as far as good students are concerned. You can teach a good student Java or C# and he will be able to abstract his knowledge when picking up other programming languages later in his career. (Things like pointers, etc. are minor details.) Teach a bad student Java or C# and he will be writing everything in Java or C# forever because it's what he knows and he is unable to think abstractly, which is necessary when transferring one's experience to another language.
Frankly, if I went to school and didn't get a course in C, I would be very upset. It's really the Latin of computer science.
and no, to answer your question, I don't see the difference.
Slashdot Mirror
According to Mitnick, a speedy trial would have meant going to court with unprepared counsel and possibly getting put away for a large part of his life. So he decided to sit around in jail a while.
Most of the time, when you free native resources owned by a Java object, you do so in the "finalizer" that the GC calls when it's about to free your object. A finalizer is analogous to a C++ destructor and is called ClassName.finalize().
Never rely on finalizers for reclaiming resources or your program's behavior is undefined. You can't control when the garbage collector will run the finalizer, and if there's plenty of memory it may never run. Scroll down to the middle of this page for more details on why you shouldn't release any sort of limited system resource in finalizers. (Except for memory.)
Doesn't anybody pay attention to robots.txt anymore?
If Bill Gates came in and posted an insightful criticism on the open source world, and the GPL, and free software, and he could be genuinely determined to be the *real* Bill gates at Microsoft, would he be modded away? Would he receive the same harsh criticism?
I'm sure if Bill Gates bothered to show up here he'd be moderated up to 5 even if all he wrote was "FUCK YOU".
The default visibility of generated variables is a project configuration setting (at least it is in JBuilder 4, I can't imagine they've taken it away in later versions).
Thanks for telling me that; now I have to strangle him! Actually he's the original developer of the project, and he's the CEO of the company now, so I shouldn't complain too much about his code. He was trained as a physicist and can hold 15 things in his head at once so some of his stuff is absolutely incomprehensible. The parts of his code that were written by JBuilder are almost a pleasure to work with in comparison!
As for the default naming (jLabel3 etc): how do you suppose the designer would figure out the correct name on its own ? As far as I know there's no mind-reading plugin yet. Just rename the thing after dropping it on your design area using the property editor.
Sigh... Can't it at least suggest memorable default names, like panelFred and buttonBarney? I've never seen anyone who used a visual designer even bother to change the names of those damn things. When they're messing with the designer, they often have it in their head that nobody will ever have to edit the code by hand anyway, so they don't care if it looks like diarrhea.
If you manually write all GUI code you can probably avoid a few variable declarations for layout managers if you always use their default settings (e.g. myPanel.setLayout(new BorderLayout())). But runtime this doesn't make a difference, the layout manager is still in scope for the entire lifetime of the instance.
Yeah, at runtime from the JVM's point of view the scope is no different. But I don't care about the JVM's point of view. From my point of view, it's in my face! Which code would you rather maintain? This:or this:Imagine all this stuff repeated for ten BorderLayouts, two GridLayouts, and four FlowLayouts! With everything mixed up with and on top of everything else! And you should see what it can do with a GridBagLayout! Holy crap! Code like that should just be sent to India.
JBuilder's designer hasn't given me any problems.
Actually, it's pretty impressive how much manual editing of the source file is tolerated by the damn thing. It even incorporated a custom layout manager we wrote with no problems, and does a passable job with our custom components. But as time goes by, more and more human-generated changes creep in- and eventually the code gets so far from what JBuilder wrote that it gets hopelessly confused and the Designer won't work anymore. If you use one of these things, by all means try to keep the classes segregated from the manually edited code, for the benefit of both the Designer and the other human developers. But by all means do not assume from the outset that you will be successful in doing so, because chances are you won't be.
About the only thing we have to change manually is a call to a GridBagConstraints constructor that didn't exist before JDK 1.2, since we have to be Mac OS 9 compatible.
Ah, so you know the nightmare I live with every day! Damn that Mac OS 9! We're supporting it for six more months and after that I can use all the Java 2 methods that pop up in the autocomplete! Woo hoo!
Hmm, I can't get the first statement from the second. In Java, you shouldn't ever need to recompile code unless the interface it uses is changed. So a jar you make that uses swt.jar shouldn't need to be recompiled unless it uses JNI itself. No different than AWT.
Actually (after thinking about it a little more) it's really a matter of whether you consider the SWT libs to be part of the JVM, or part of the distributed binary for your program.
If it's part of the JVM, then your code that's compiled against it is a 100% portable. But unless Sun incorporates the SWT libs into the JVM (as has been suggested to them by many people) then you have to distribute it yourself, which means each platform gets a different binary distribution, differing only in the SWT implementation. Hence my misleading comment about portable binaries.
Most Java apps I've seen bundle their own JRE instead of trusting whatever's on the target machine anyway, so different binaries are going out the door anyway and the point is largely moot.
So, the question is, would you listen to the racist if he said "If you use these bullets, they'll go into the nigger without breaking up his internal parts and still kill him dead as a doornail"?
Well I might be willing to put up with an offensive description if I'm really that desperate and the information isn't available elsewhere. I guess it's all a matter of what you're willing to put up with. As long as the topic is ammunition and not politics, I might put up with it, keeping in mind that he's an idiot if he talks like that.
The point behind the question is that my experience with racists shows that race always comes up in conversation, from simpe things like "I went to the gas station and sand nigger behind the counter carded me" to more complex things like "I ate a burger at this place but all the tables I saw looked like a nigger picnic. I won't go there until they clean the place up." Remove the race references and the statements themselves are making valid points that any one of us would say, the only difference being the racial references.
Yeah, that's usually true. However notice that in this case the guy managed to squeeze out an entire post with no references at all to chinks, wops, kikes, or sand niggers! And he still got a harsh reaction, which was entirely based on his username and signature- i.e. at who he was, not at what he was saying- which, in this particular case, happened to be completely mundane and inoffensive.
Your mention of the Linux and Solaris SWT bindings as separate bindings raises interesting questions about Java and the degree of Java Political Correctness.
.NET implementation! If Microsoft were implementing Mono themselves, I'd be more impressed with your "5 years" statistic. But face it, Mono owes its existence to Java, because it conveniently (if perhaps unconvincingly) undermines the argument that .NET is not cross platform like its competition. (You might say .NET owes its existence to Java as well, but that's another thread.) But Mono faces an uncertain future. It is resting on a bed of Microsoft patents. And the non-Windows version of .NET will never be as nice, not ever. Microsoft has made that much pretty clear. How much longer than Java do you think Mono will survive? Mono is cool, and I salute the Mono team for the effort they're putting into it. I wish them all the luck in the world. And I might play around with it. But no way would I let my career hang on its continued existence or relevance, because I don't trust Microsoft.
Yes, see my rant in this thread about Sun and its Political Correctness regarding Java. Whenever Sun is faced with a choice between practicality and ideology, they seem to choose ideology every time.
AWT/Swing doesn't have or need bindings because 1) they are 100% Java or 2) to the extent that they are not 100% Java and need to JNI down to something, that something is distributed with the Java VM that appears on each machine, so you don't need to distribute any platform specific AWT/Swing bindings with your app.
That's a fairly good description- the native bindings for AWT (and Swing, which depends on AWT) are hidden within the JVM. Actually AWT uses a peer layer which is not present in SWT. Buttons in AWT are represented by a java.awt.Button. The java.awt.Button class never changes- it's the exact same class across Linux, Windows, Solaris, etc. The class accesses platform specific button resources via an instance field it has that implements the java.awt.peer.ButtonPeer interface. On Windows the implementing class is a sun.awt.windows.WButtonPeer. This way each class has a globally unique definition. In SWT, they didn't bother with the peer layer at all. The thing that changes as you move from one platform to another is the very org.eclipse.swt.widgets.Button that is manipulated by your client code- there is a separate version of that class for each platform (they're careful to always keep the public methods the same). Sun would never do something like that. They meticulously avoid having classes change from one platform to another and in fact they seem enamored of the idea that a class name should get you a unique class out of some global repository. (Of course, there's usually a million versions of a class anyway, but whatever.) IBM could have incorporated a peer layer into SWT rather easily, but I guess they decided it wasn't worth the bother.
SWT needs separate bindings for each target platform -- it becomes like wxWindows or Qt in that regard. If you want to distribute an SWT app, you need to distribute those bindings, or tell your users how to install the right binding on their machine. But then you are into a bindings model rather than a true "write once, run everywhere" model.
Well this is also the case with AWT and Swing, which have their platform-specific bindings hidden right within the JVMs- so you don't even realize it's a problem! There isn't a Java GUI library on earth that won't at some point require a JNI layer somewhere. But the native layer of SWT is extremely thin- IBM claims there's "nothing interesting in the native code" and that it's a 1-1 function mapping. If they could convince Sun to incorporate SWT bindings into the JVMs along with the AWT stuff, then it would be on pretty much equal footing with Sun's GUI toolkits. Fat chance though, as Sun has already put all its eggs in Swing's basket. They're known for hissing at SWT whenever the topic arises.
My remark about J++ may not be completely off the mark. To the extent that C# is in reality J++, and that WFC was transformed to System.Windows.Forms, and to the extent the Mono is going down the bindings road to port System.Windows.Forms (to answer your question, 2002 - 1997 = 5 years to get Linux and Solaris versions of WFC), and to the extent that Miguel gets lambasted for doing what he is doing, why should Eclipse/SWT get a free pass for doing a similar thing with Java?
It's not really a valid comparison, for several reasons. First of all there's intent. It's not as if IBM created SWT with the goal of destroying Swing. They just needed a GUI library with which to write Eclipse after they determined (correctly) that Swing sucked too much to be seriously considered for developing Eclipse. SWT was a means to an end, not an end in itself. Now they're saying, "we wrote this nice GUI library for our app, and if you want to use it for your own purposes, here it is." Compare that to Microsoft's predatory behavior with J++, which was carefully designed to discourage portable code by seducing you with visual designers that only worked with WFC. Often J++ users didn't even realize they were writing Windows-specific programs because Microsoft was doing such a good job of obfuscating that simple fact!
As for platform specificity- Swing runs on all platforms, and so does SWT- except that the Windows implementation is nicer and further along than the others. So what? Are you suggesting that IBM doesn't want Eclipse to be successful on Linux? The Windows implementation has probably received more of IBM's resources so far because of what their user base is- there's nothing Windows specific in the design of SWT per se. Anyone is free to help on improving the other bindings, which by the way are still part of SWT, in a way that Mono is not part of Microsoft's
Hmm, I can't get the first statement from the second. In Java, you shouldn't ever need to recompile code unless the interface it uses is changed. So a jar you make that uses swt.jar shouldn't need to be recompiled unless it uses JNI itself. No different than AWT.
Yeah, I misspoke, sort of. Strictly speaking, you don't really need to recompile, or you shouldn't, since IBM is careful to keep the public methods of each SWT implementation the same on each platform.
If you want to sleep well at night, however, I recommend doing the recompile anyway to make sure they didn't miss anything! Practically speaking, for other reasons you may be running a separate build script for each version of your program anyway, so it's probably just easier to do it in each build script instead of separating it out into a separate step.
SWT seems like a cool idea, but with its close coupling to Windows (Windows is the farthest along -- the other bindings seem to be "under construction"), how is this different than (gasp, choke, gag) J++?
Oh come on! At least SWT bindings for Linux and Solaris exist, they can exist in the first place, and you can assist in their development. How long do you think you would have to wait for Microsoft to release Linux and Solaris versions of the Windows Foundation Classes?
The Internet isn't pretty, it isn't clean and it isn't proper. Just because Granny can't keep up with the times and learn how to operate machinery properly doesn't mean that Microsoft's gotta bow down and de-evolve their OS even further towards the lowest common denominator.
No, but they can at least refrain from running servers by default on a simple install of XP Home. You have to consider who your users are when adding features and deciding which ones are turned on right out of the box.
Could one, for instance, now compile a Java program using the SWT library to a native binary using GCJ, so it could be run without using a JVM?
Yes.
SWT takes a middle ground between the extremes of AWT and Swing, and abandons a sacred cow of Sun's- the idea that the same binary must run on all platforms without any modifications. This attitude has really been an albatross around Java's neck and is the reason everyone thinks that Java applications have to be cheesy- because Sun demands that they must be equally cheesy everywhere!
AWT takes the approach that ALL widgets are drawn by the native layer. This isn't a bad idea, except that if no native widget is available (like a slider, or tree), AWT refuses to improvise one at the Java level. This is why there are no sliders or trees in AWT, even on platforms like Windows where native widgets for both are present, because there's some platform out there somewhere that doesn't have them. Maybe AIX or something, who knows. AWT is strictly lowest-common-denominator and that's why everyone hates it.
People bitched and moaned. So Sun went straight to the opposite extreme with Swing, which refuses to even consider the native widgets. Instead, it uses Java level methods to draw pictures of them to fool you. This means that Swing can offer you a "pluggable look and feel", so you can have Motif buttons on Windows, or "Metal" buttons on the Mac! Except nobody cares. Microsoft promptly kicked Swing in the nuts by introducing skins with XP, so it becomes obvious what is really Windows and what is pretending to look like Windows but can't keep up. And Swing suffers greatly from the second system effect- it's overengineered as hell. A Hello World in Swing gobbles up 20 MB of overhead- mostly classes loading and initializing themselves. In fact, Swing is why AWT is still alive. AWT sucks, but you can run a program that lasts for more than a couple minutes with it. Writing stable applications with Swing is a real art. (It is in AWT too, but only because Sun has pretty much left AWT flapping in the wind with minimal improvements, maintenance, or bug fixes. Since Swing came along, AWT has been treated like a red-headed stepchild by Sun.)
SWT is much more like AWT than Swing, except that it takes a practical middle ground- something Sun doesn't seem capable of doing at all! It offers you a nice set of native widgets. If a slider or a tree isn't available on some platform, they draw a picture of one for you. This might make sliders and trees look funny on platforms that lack sliders and trees, but you would expect things to look funny on those platforms. People using Windows (i.e. most of them) aren't bothered by any of this.
This sacrifices binary compatibility. Each platform has its own version of the SWT library. For example, there is a Windows specific swt.jar and a swt.dll that goes with it, and there is a Solaris version of swt.jar and a native swt.so library that it uses. Even though the libraries are implemented completely differently, the public interfaces are the same. So if you develop a program against the Windows version of the SWT library, you won't have any problem compiling against the Linux version. (Although I've heard that SWT blows on Linux, but that was a while ago and I don't know what the current state is.)
SWT doesn't abstract much away from you, unlike AWT, where you are separated from the low level GUI details by a leaky abstraction. In SWT you have to write the frigging event loop yourself! (Which is not a big deal- it's a while loop, usually two lines.) There are a few other gotchas, and you absolutely have to test a SWT program on all platforms you're releasing for, but in practical terms the same was always true for AWT because of the leakiness of its abstraction. SWT at least doesn't pretend that you don't have to worry about this stuff.
This means you have to compile and test a program three times before releasing it, once for Windows, once for Linux, once for Mac. This violates Sun's sacred cow of binary compatibility. But when you're releasing a Java application, you're going to make separate installers for each platform anyway, because you have to bundle a JVM for everybody. So it's not really a big deal, unless you're writing an applet- and applets went the way of the dodo long ago in no small part because of AWT and Swing!
With SWT, you can make really nice, professional looking programs. The layer between you and the OS is very thin (JNI). If your program looks silly or stupid, it's YOUR fault. When the user changes the skin in XP, your SWT programs will pick up the change right away. In fact, it isn't even obvious that you're not using C! You can write your stuff in Java and actually get away with it! So that's why I think SWT is the future (if there is any future left anymore) of Java on the client, and why I will be junking AWT/Swing completely when starting new projects.
For more info see the SWT FAQ. There is some GCJ and SWT info available here.
No, but whose fault is it if you buy a pair of pants with "KICK ME" emblazoned on the backside, and you complain that people kick you all the time, even though you didn't possess the technical inclination to look on the ass for any signs, markings or invitations to random passerby?
Or the technical ability to even realize such markings are there! "KICK ME" can be written in languages that you just don't know! OR it can be written in invisible ink that is only visible with special goggles. My grandma isn't going to run a portscanner on her machine as soon as she unwraps it on Christmas. I mean, give me a break. It's beyond reasonable to suggest that she as an end user should even have to. Stuff happening at the TCP/IP layer on a default XP install is the responsibility of Microsoft. Period.
...I think that Borland's Jbuilder IDE it's the best so far. It's slower than eclipse, but it offers much more features. And ... i'm so used to it :) ....
Please tell me you don't use JBuilder's Designer. We had a developer who liked to use it a lot. He stopped a year and a half ago, and we're still mopping up the damage! Everything looks like
flowLayout1 = new FlowLayout();
label2 = new Label();
panel3.add(button8);
panel6.add(panel4);
label2.setText("Welcome!");
panel7.setLayout(borderLayout6);
and it goes on and on like this for a couple hundred lines! With not a single local variable in sight- JBuilder declares them all as instance fields! Oy! Unless you keep these window classes tightly segregated from the manually edited code, and ONLY touch them with the Designer, they become unmaintainable monstrosities. Adding a single button or textfield is inordinately painful. As for changing the layout- you might as well do a rewrite.
I've become good at deobfuscating JBuilder's crap. First remove the 30 BorderLayout fields, FlowLayout fields, etc. Then gradually rename the "panel8", "button3", to sensible names, and remove redundant ones as you find them. Then get some graph paper out, and go slowly through the jbInit() method until you see what's going on. This will let you get rid of 90% of the instance fields in the class.
Layout code is tedious, but there's no excuse for not doing it manually unless you're not worried about maintainability. In fact, one thing I like about IntelliJ IDEA is the lack of a GUI designer.
The thing is, if we censor this fuck, then we're accused of being "un-American" or some shit like that.
Maybe not "un-American", since shouting down unpopular opinions seems to be in vogue here nowadays.
But really, you shouldn't censor people just for holding unpopular opinions, especially when they're not even expressing those opinions at the moment. Even a white supremacist might have something to teach you, as long as you know which topics to avoid. I might listen to a racist if he's talking about how to polish a gun or clean a deer, even though I know not to listen when the topic of race comes up.
Sometimes I hate being libertarian, we're _supposed_ to defend the rights of ignorant sister-kissing cousin-fscking inbred so-and-so's like this.
It amazes me how many people are attracted to libertarianism and yet don't understand the concepts behind it. Yeah, freedom for other people can sometimes suck, especially when they're expressing an unpopular opinion, but the censoring of unpopular opionions is the first step down a dangerous path.
And to all the people complaining about the modding up of this guy's post- the moderation applies to the post, not its author. This particular post has no offensive content that I can see. (Although I wouldn't waste mod points on it, because it really doesn't merit an "Insightful".) And the guy is at least honest about who he is. I wish all racists would announce up front who they were.
The way things have been going for Trent's political career lately, a "Learn C++ in 21 Days" book might not be a bad gift!
Although it's nice to see him coming back to his old self. The "new Trent Lott" was getting boring.
I'm a programmer and I think the world would be a better place without the damn things. It ran fine without them up until the 1940s.
WTF? Were you around before the 1940s? I'll have you know I've seen real film footage of the world before the 1940s, and from the looks of it, I'd say it was a far cry from "fine". In fact, I think "miserable" would be a better word for it!
And how in the world did the civil rights movement get included in your list? Were you at Strom's birthday party last month?
No one's "hacking into" any computers. Do you "hack into" the webserver when you request a page? Your computer has to be listening on port 139 for these messages to have any effect.
Spoken like a true geek. However, you are extending an abstraction into higher levels than is necessarily appropriate. From my grandma's perspective, the TCP/IP level mechanism is irrelevant. She wants to know where the hell these weird messages are coming from.
Just because XP automatically installs a service that listens on port 139 doesn't or shouldn't necessarily mean that I as a naive user am going to be expecting packets at that port. Taping a "KICK ME" sign to someone's butt doesn't mean they want to be kicked either. Not everyone views these things strictly at the level of the socket API.
Thanks for your friendly advice. Actually I don't know why I wasn't chosen (a domestic squabble case came up, and I answered their questions honestly). I don't know why. You would think I would be a great juror.
So only the rich pay sales tax, gas tax, property tax, car reg tax, amoung other taxes?
No. Where are you getting that from?
Here's another link for you.
1. Bring a laptop on which you can do work. If your job cannot be done on a laptop with no network connection then you are screwed and should take the alternate approach, finding excuses to get out of jury duty.
2. Find the outlet in the jury pool room, and sit next to it. Arrive early if you have to. Your laptop battery will not keep you going long enough, so you must plan to run on AC power. If there is only one outlet, you must not let anyone else sit next to it. To avoid problems, you may want to arrive early or bring an extension cord.
3. Pretend to be an idiot during voir dire. This is crucial. Courts take a dim view of software development work in the jury box. The place you want to spend your time is the jury pool room, not the courtroom. It's easy to minimize the time you spend in the courtroom. During the voir dire process, be sure to express at least one of the following opinions whenever any question is asked of you:
You may still get picked for a jury despite your best efforts. If this happens to you, make sure you have something dry and technical to read, like a printout of some API documentation. (Don't bring anything more interesting along or you'll end up reading that instead.) Most judges don't care if you catch up on your reading during the procedural lulls that consume most of the court's time, when your attention isn't needed. People read romance novels on juries all the time. But I think an open laptop would be pushing it.
4. Don't make any friends. Remember, you're going to jury duty to get lots of work done, not to socialize! The reason jury duty is great is that it forces you to work because there's nothing else to do and no one interesting to talk to! No meetings, phone calls, emails, or Slashdot. You have to take advantage of this valuable time. If you make friends in the jury pool room, you defeat the entire purpose of not trying to get out of jury duty!
Seriously, I got called for jury duty and I got an amazing amount of work done that week. It was unpleasant and uncomfortable as hell while I was there, but afterwards it was definitely worth it.
Bah, this is a stereotype.
Ever since he lost his presidential bid McCain's been the Democrats Democrat (yes, I know - He's a Republican in name only). His Stances and choices usually support what the Democrats want, and often exceeds their wildest dreams.
You know, I thought this petty viciousness against McCain had ended after he lost the primary in 2000. Can you offer any evidence to back up your assertions, or are you just parroting what someone told you on the radio?
I disagree with McCain on most issues. But McCain is an honorable man. He has certainly never stooped to dirty tricks like some other people I can think of.
Everbody, come over here.
I fund a liberal.
I found one !
Really? Which liberal are you funding?
texts like .NET crap you want, and we better see this entering your curriculum or else you lose your discounts and we audit your asses. .NET using people.
.NET? It has nothing to do with them.
MORE EVIL: Here, have all the
are just speculation and ment to be insulting for MS and
How in the world do you take this to be insulting to people using
It's an issue of disclosure. If I'm paying lots of money to a university for a degree, I expect that my curriculum is being chosen by professors who evaluate technologies on their own merits, not because of bullying by a vendor. Maybe they would have taught C# even without extraneous pressure from Microsoft. Who knows?
If you really think "java" or "C#" or whatever language you get on your university is more important than the real point of what you get taught: "OO development using an imperitive language", you don't know jack about computer science and how it is taught to students.
I agree with this sentiment, as far as good students are concerned. You can teach a good student Java or C# and he will be able to abstract his knowledge when picking up other programming languages later in his career. (Things like pointers, etc. are minor details.) Teach a bad student Java or C# and he will be writing everything in Java or C# forever because it's what he knows and he is unable to think abstractly, which is necessary when transferring one's experience to another language.
Frankly, if I went to school and didn't get a course in C, I would be very upset. It's really the Latin of computer science.
and no, to answer your question, I don't see the difference.
Then reread the post more slowly this time.