GNU Christmas Gift: Free Eclipse 320
Mark Wielaard writes "Your friendly neighbourhood GNU did
it again. A year ago IBM made much noise
about placing $40 million of its software tools under a free software
license. Technically these tools, called Eclipse, are great for developing
(java) software. There was only one catch, it was build on top of the
proprietary java platform. This made it useless for the Free
Software community. Luckily the GNU project has two projects that come
to the rescue. GNU
Classpath, core libraries for java, and gcj, the GNU Compiler for Java.
We are now able to run Eclipse on a completely free platform! It is
not yet complete, but you can already edit, compile and browse CVS
with it. And since Eclipse uses GTK+ it also looks very nice. I setup
a page with
instructions on how to get this working so you can help us make
it work even better or just so you can view a couple of nice screenshots."
I'm glad... (Score:2)
Blackdown (or was it Blackstone)? (Score:2)
So another GNU team has almost managed to replicate the work done by the Blackdown team 4-5 years ago.
Meanwhile the GNU team has almost managed to release a kernel.
On the sidelines, Wine has almost enabled cross-platform execution, provided you don't want to do something so uncommon as opening a file picker!!! (I mean, come on! I can play video games, but I can't pick an input file to open with a utility program?)
Lately I see a lot of "almost" me-too projects, but I'd be a lot more impressed if they didn't start celebrating until the damned things worked.
Eclipse is free and pretty nice (need to try it again -- it was rough when I first looked almost a year ago.) Sun's SunONE Studio 4 is ok, too.
My favourite remains JBuilder, but I just can't afford to upgrade anymore (paid full price for 3.0, paid for the 3.5 upgrade, the 4.0 upgrade, and realized I'd spent over $2000 with no end in site.)
Despite all the fancy IDEs out there, I still do the bulk of my editing with vi(m), emacs, and text tools, then debug and fix in an IDE. I've yet to find a Java (or C++) IDE whose editor is more than barely usable. But that is another rant...
Re:Blackdown (or was it Blackstone)? (Score:2)
The GCJ team has done something FAR more impressive: without *any* of Sun's sources, they've built a Java implementation from the ground up.
But I shouldn't even bother: you've clearly made up your mind and no amount of facts are likely to change it...
Re:I'm glad... (Score:3, Informative)
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.
Re:I'm glad... (Score:2, Informative)
also, apart from being slow, jbuilder just generally comes across as bloaty to me. i mean, i'm sure _someone_ wants all that stuff, but it goes too far for me. while i was using it, i seemed to spend almost as much time wading through the docs as i did working.
aaalso.. it's really doesn't seem to like most open source stuff. unsuprisingly it's heavily biased toward the commercial appservers (i work with j2ee).
eclipse however, is fast (relatively), simple in terms of interface and finding the actual functionality you need, and has superb support for open and closed type plugins. cvs works nicely, ant works nicely, junit integration is great, and so on.
to me jbuilder is everything that CLI junies hate about GUIs, whereas eclipse is how it should be, minimum bloat, maximum functionality.
Re:I'm glad... (Score:2)
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!
Now take Eclipse, please! (Score:2)
Re:Now take Eclipse, please! (Score:3, Insightful)
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?
SWT vs AWT/Swing (Score:3, Interesting)
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.
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.
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?
Re:SWT vs AWT/Swing (Score:2)
Yes, see my rant [slashdot.org] 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
sun and java (Score:2)
Re:sun and java (Score:2, Interesting)
And the president and board of directors should come to our houses and mow the lawn every Sunday afternoon.
Re:sun and java (Score:2, Offtopic)
...and while I'm at it, I wish I had a pony.
Re:sun and java (Score:2)
Re:sun and java (Score:2)
He instead attempts to turn it around and pretend that he is "superior" somehow
Thus spake "Trolling4Dollars."
Oh, "Trolling," you're nothing if not good for a laugh.
Re:Java + GPLed qt = Attack on .NET (Score:2)
Get busy with SWT [eclipse.org] then. SWT is designed to do exactly that (bind native widgets to Java), and is open source.
Have fun!
Free Software Community (Score:3, Insightful)
Hmm.
Re:Free Software Community (Score:2)
I agree. This is sort of "purist" view.
When I looked at the patch they disable the default garbage collection. I guess that this will cause memory blow ups when loading huge projects. I suppose that the original binary with Sun's Java is the best bet for production machines. Heck, I'm perfectly happy with Eclipse's current Linux GTK+ binary.
Re:Free Software Community (Score:2)
Then again, I haven't tried Eclipse yet, so this is just a guess.
Re:Free Software Community (Score:2)
Well, I have a slight problem with IBM JVM in my Gentoo box. The response was slower IMHO and it trashes when compiling some classes of my project. With Sun's JVM everything's fine, though. Of course, the workaround would be to compile the problematic classes separately, but that sort of pain.
Re:Free Software Community (Score:2, Interesting)
I mean sure, I don't have the source code for it, but it's object oriented. If there's somethign I don't like I can write my own.
Like I would know how to edit, let alone write, code for a compiler!
Re:Free Software Community (Score:2, Insightful)
I know I'm not the only Slashdotter who senses the irony of a community of people who supposedly stand for freedom declaring an entire platform to be useless because they find it politically unacceptable.
Re:Free Software Community (Score:2, Insightful)
Why must you slander us and belittle us?
"Politically unacceptable" is a poor substitute for "under a license that does not guarantee freedom from embracing and extending". It's not about politics, it's about learning a tool we can feel confident will continue to be around even if Microsoft buys Sun out in some dim future.
The platform is useless because the strings attached are too restrictive for those of us who think about the future of software development.
Radical fundamentalists would be the sort to smash the windows of Sun HQ or create cyber-havoc to achieve their political ends. You're smearing reasonable people who don't like Trojan gifts with a very broad brush, and I believe you owe us an apology.
Re:Free Software Community (Score:3, Insightful)
Well, come on. You do bring it on yourselves, don't you? All the high-minded talk of freedom and liberty just reeks of tall poppy syndrome. Even if your political goals weren't wrongheaded and your propaganda methods highly questionable, the "community" in general, and certain members of it in particular, think so much of themselves that being brought down a notch or two from time to time is good for them.
That said, though, let us not lose sight of the fact that your political goals are wrongheaded and your propaganda methods highly questionable.
"Politically unacceptable" is a poor substitute for "under a license that does not guarantee freedom from embracing and extending".
Actually, I think "politically unacceptable" describes the situation perfectly. Here we have a platform that is free for your use, without the sorts of BitKeeper-style restrictions that created such a stink a while back. The platform is ubiquitous and unrestricted, and generally considered to be appropriate for a wide variety of tasks. And yet you (you meaning the "community") refuse to use it for no other reason than that the people who built the platform do not subscribe to your views on intellectual property and source code licensing.
You may wrap it up in terms of "we want a tool that isn't under anybody's control," but the bottom line is that the concerns of the "community" aren't practical. They're ideological.
You're smearing reasonable people who don't like Trojan gifts with a very broad brush, and I believe you owe us an apology.
I am calling it like I see it. I don't think a reasonable person would conclude that Eclipse is "useless for the free software community" simply because it was built with and runs on Java. That is absolutely radical fundamentalism; it is based on the idea that anything that is not ideologically pure is "useless."
Now I didn't speak personally, and I intended no offense, but I will not be offering any apologies, either.
Re:Free Software Community (Score:2)
No we most certainly do not.
All the high-minded talk of freedom and liberty just reeks of tall poppy syndrome. Even if your political goals weren't wrongheaded and your propaganda methods highly questionable, the "community" in general, and certain members of it in particular, think so much of themselves that being brought down a notch or two from time to time is good for them.
I don't get it, what is it about freedom you don't like? Again I hear slander without specifics. You're basically saying "quit whining about your freedom, you need to be put in your place," only less succinctly.
The platform is ubiquitous and unrestricted,
This is a lie, and it undermines what little non-insult argument you offer. The java platform is famously non-free, under the control of Sun rather than standards bodies.
no other reason than that the people who built the platform do not subscribe to your views on intellectual property and source code licensing.
Let's unpack this statement. First we have the insult:
do not subscribe to your views on intellectual property
Clearly, we don't care. Linus works for Transmeta and uses Bitkeeper, but the GPL keeps the Linux kernel free no matter what Linus's politics are. It's not Sun's views on IP we care about, it's the license under which the gift software is offered. What you are trying to do is smear the free software community (who concern themselves with providing free alternatives) with warez kiddiez who have no respect for laws they disagree with. If the free software community didn't respect those laws even as they disagreed with them, they'd just pirate all the software rather than build alternatives. You are trying to beat on a man very much made of straw here.
Second:
and source code licensing.
That's true. We don't like the license so we won't use it. You are trying very hard to make this seem unreasonable, but it is not.
I don't think a reasonable person would conclude that Eclipse is "useless for the free software community" simply because it was built with and runs on Java. That is absolutely radical fundamentalism; it is based on the idea that anything that is not ideologically pure is "useless."
Of course not, you're clearly not reasonable and have no idea what a reasonable person would care about.
The idea that being concerned what license your software runs under makes you a 'radical fundamentalist' is pure slander. It's an attempt to make it sound like anyone who cares about what license their software uses sound like a terrorist. There is no other purpose to these terms, and they are not the terms reasonable people use to discuss their differences.
Now I didn't speak personally,
Ah, but now you have responded to my post personally, and accused me of 'radical fundamentalism' and an obsession with 'ideological purity', and I have taken it personally.
You are coming from the perspective that a little proprietary software is ok. I understand your perspective, and I can see why you might have it. But you seem to think that anyone who has a different perspective on the appropriateness of proprietary software is a raving lunatic, and for this I fault you and continue to demand an apology.
Re:Free Software Community (Score:3, Insightful)
Oh, man. This could take days. But the short answer is that the FSF does not stand for freedom. They stand for strictly limited freedom. They stand for "freedom except." And yet they persist in calling it "free." That's deceptive. But I really have little to say to you on this specific part of the discussion that I haven't already said in this [slashdot.org] extremely lengthy and, surprisingly, civil thread. If you want to know what I think about the FSF and what they call "freedom," please click over and read what I wrote there.
The java platform is famously non-free, under the control of Sun rather than standards bodies.
You're kind of proving my point here, whether you realize it or not. You have called out the fact that Java is defined by a company instead of by a committee as being a sign that it is "non-free." That smacks of the "ideologically impure" thing I mentioned earlier. Because the Java specification is not defined by a committee, the Java platform is impure, so all software that runs on Java is impure. And because Eclipse runs on Java, it is "useless for the free software community." This is, as I said before, an example of radical ideological fundamentalism.
It's not Sun's views on IP we care about, it's the license under which the gift software is offered.
Okay, then for the purposes of our conversation I retract what I said about the FSF's disagreements with Sun over IP. Forget I said that.
What you are trying to do is smear the free software community (who concern themselves with providing free alternatives) with warez kiddiez who have no respect for laws they disagree with.
Wha? I don't understand how you jumped from what I said to that conclusion. I didn't say a thing about software piracy. If you're going to argue with me-- for I do love a spirited debate-- at least have the courtesy to disagree with things that I actually say, if you please.
We don't like the license so we won't use it. You are trying very hard to make this seem unreasonable, but it is not.
What I consider to be unreasonable is the apparent "fruit of a poisoned tree" doctrine that is being applied here. As I said before, Java is considered ideologically unacceptable-- this is a vital distinction; not unacceptable on technological or practical terms, but purely ideological ones-- so all software that runs on Java is also unacceptable.
It is possible to release software for the Java platform under the GPL. It is possible to build software with Eclipse and then release it under the GPL. So the objection here has absolutely nothing to do with the real world. It's purely ideological, and I consider that to be unreasonable.
Of course not, you're clearly not reasonable and have no idea what a reasonable person would care about.
Wow, this is getting better and better.
It's an attempt to make it sound like anyone who cares about what license their software uses sound like a terrorist.
Actually, it's an attempt to make it sound like anyone who considers a tool "useless" not because of its license, or because of the license of the platform on which it runs, but because of the specification of the platform on which it runs sound like a radical fundamentalist. Which is precisely what I said. If you jumped from "radical fundamentalist" to "terrorist," then I submit that you may have been watching too much television, and that you might want to sit down calmly, take a stress pill, and think things over.
Ah, but now you have responded to my post personally, and accused me of 'radical fundamentalism' and an obsession with 'ideological purity', and I have taken it personally.
Well... okay. Yes. If the statement, "[The fact that] it was build on top of the proprietary Java platform... made it useless for the free software community," accurately describes your opinions, then yes, I am accusing you of radical fundamentalism. I am accusing you of being more concerned with ideology than with software, free or otherwise. Most importantly, I am accusing you of cutting off your own nose to spite your face.
If this offends you, I am sincerely sorry. I do not mean to attack your character, hurt your feelings, or insult your person. I mean only to indict your ideas in the court of Slashdot public opinion.
You are coming from the perspective that a little proprietary software is ok.
Actually, just to make things perfectly clear here, I am coming from the perspective that all proprietary software is okay. I disagree most wholeheartedly with the FSF's most fundamental assumption, which is that proprietary software, and by extension all intellectual property, is a bad thing. Just so there's no confusion about where I stand on the issues, you see.
But you seem to think that anyone who has a different perspective on the appropriateness of proprietary software is a raving lunatic, and for this I fault you and continue to demand an apology.
Whether you, sir, are a raving lunatic or not remains to be seen. You may fault me for whatever you like, and you may demand whatever you like. As I said before, no apology will be forthcoming.
Re:Free Software Community (Score:2)
They stand for "freedom except." And yet they persist in calling it "free." That's deceptive.
The whole notion of absolute freedom breaks down when you consider that every freedom exercised that involves more than one person constrains the actions of the other in some way. The FSF's notion of freedom tries to make some good choices about how to provide freedom for everyone most effectively in the tradition of J.S. Mill. That is, you are free to do anything you like but restrict the freedoms of others. It's the software equivalent of "your freedom to swing your fist ends at the tip of my nose."
You have called out the fact that Java is defined by a company instead of by a committee as being a sign that it is "non-free." That smacks of the "ideologically impure" thing I mentioned earlier.
It has nothing to do with "purity", it's the fact that they can take our right to use the platform away at any time they choose; they can "pull the rug out from under us" so to speak. It's not abstract ideology, it's practical management of licensing risk. But if your understanding of "purity" is anything like your understanding of "freedom"...
I didn't say a thing about software piracy.
You didn't have to. What you said was that the reason we won't use Sun's Java is that we don't agree with their view of IP. What this implies is that we are all IP thieves and that Sun is on the right side of the law. If you didn't mean it that way, I accept your clarification and withdraw my complaint. But if I may compliment you for just a moment, as much as I disagree with your claims and apparent motivations, you do not seem the sort to waste a phrase.
not unacceptable on technological or practical terms, but purely ideological ones--
No, it is unacceptable on practical terms. The platform can be broken or taken away, so it's impractical to use it.
at least have the courtesy to disagree with things that I actually say, if you please.
If you'd stop implying so much more than you say explicitly, this would be a very short conversation. But you're using words and phrases that imply more than they say, and I'm simply exposing those instances- taking issue with what you *actually said*, rather than what you claim you meant to express.
Which is precisely what I said. If you jumped from "radical fundamentalist" to "terrorist," then I submit that you may have been watching too much television, and that you might want to sit down calmly, take a stress pill, and think things over.
It becomes more and more clear to me that you have no interest in discussion. Your words were deliberate and hurtful, and the association is obvious.
I disagree most wholeheartedly with the FSF's most fundamental assumption, which is that proprietary software, and by extension all intellectual property, is a bad thing. Just so there's no confusion about where I stand on the issues, you see.
Here we are again. Distortion. The FSF needs an IP system to guarantee that people have the right to actually use the software that's produced. The FSF insists on the preservation of attribution in the GPL. It's important that credit go where it belongs. However, it is not important that we keep people from building on the ideas of others, and at a minimum, it is important that those who want to share their own work and ideas freely be allowed to without interference from those who do not want to share.
But most importantly, who the hell cares what the FSF's feelings about IP are? The point is that practically, using software that is not free to use, alter, and redistribute has *practical* implications in that the continued existence of any project built on a limited platform is at the mercy of the owner of that platform. And what you call "ideological purity" is actually the well justified fear that Sun's corporate interest may (will) one day conflict with the interests of developers and end users, and that this corporation, having gained a foothold into an otherwise free system will pull the plug on all the derivative free projects that didn't worry about the terms of their licensing.
Re:Free Software Community (Score:3, Insightful)
I salute you in your effort to build a computer system that is free of the burden of licensed software. I don't really care about it, because it doesn't affect me at all, but I classify it alongside people who write web browsers in BASIC just to see if it's possible, and other frivolous pursuits.
Of course, as I said before, when the FSF comes along and starts misrepresenting their products, then I get testy. But that's a subject for a different rant entirely.
Re:Free Software Community (Score:2)
On another subject, though, if you're going to go making recommendations to the readers of this thread to add or remove friends based on your opinions, the very least you could do would be to post under your own name instead of hiding behind that "post anonymously" button.
What are you afraid of?
Re:Free Software Community (Score:2)
Which questions would those be?
Re:Free Software Community (Score:2)
Re:Free Software Community (Score:2)
Re:Free Software Community (Score:2)
I know I'm not the only Slashdotter who senses the irony of a community of people who supposedly stand for freedom declaring an entire platform to be useless because they find it politically unacceptable.
I think you should s/politically/ethically/ in the above statement. There is a difference between politics and ethics, and conflating them in the way you are doing is dishonest and empty rhetoric.
"Politics" has come to have a distasteful connotation, meaning roughly, "the arbitrary abuse of power": When the boss's lazy, incompetent protege is promoted ahead of a hard-working and competent individual, everyone complains about "office politics".This isn't the only meaning of "politics, its a special case. Politics is about who has power and how they use it. The reasons for choosing a particular arrangement of power or a particalular use of it can me ethically based, or not.
Anti-war and anti-abortion activists both have political ends in mind, but their reasons for their beliefs and actions is based in ethics. You might disagree with the policies they advocate, or disagree with the reasoning that leads them to these policies, or disagree with their entire system of ethics, but to represent their beliefs and actions as solely political would be dishonest.
Free software does have political implications: it rearranges the legal rights of copyright holders and software users. But free software advocates have ethical reasons for wanting to rearrange these rights in the exact same sense that anti-war and anti-abortion activists have an ethical base for wanting to change government policy.
You might think that ethics has nothing to do with software, and that which software to use should be decided on solely on technical merit. Obviously some people disagree. As stupid as you might find their position it's wrong to misrepresent their beliefs and reasoning.
~Phillip
Re:Free Software Community (Score:2)
Re:Free Software Community (Score:2)
That certainly says something about the type of developer that doesn't adhere to the the simple philosophy of "use the best tool for the job", doesn't it?
Re:Free Software Community (Score:2)
Tim
combo (Score:2)
Keep the zealotry to yourself (Score:2, Informative)
People authoritively claim that Microsoft will use patents to kill these efforts if they become competitive, but there is no evidence to support this paranoia, and in-fact Microsoft does not have a histroy of abusing patents in this manner (unlike another company I could mention [xml.com]).
keep your naiveness to yourself (Score:2, Flamebait)
Ok, because, we don't agree with your stance we're zealots now? Whatever happened to free software advocates?
I have lots of doubts with .NET because it's from Microsoft. I don't think my concerns are unfounded. They've done enough in the past, now they arouse my suspicion just by them twitching.
How many times does a person have to screw you over before you stop trusting them? Similarly how many times does a company have to resort to shady tactics before you decide that it's probably in their corporate culture to do so.
My arguements against .NET are not technical, other than I don't think it brings enough to the table to warrant much of interest. It's mostly that sooner or later MS will find a way to screw open source interest with it.
Re:Keep the zealotry to yourself (Score:5, Informative)
Incorrect in every regard.
Microsoft has already used patents to attack open source projects, and has also used patent licenses to attack the GPL. Microsoft's highest executives have also stated publically that they intend to use patents against certain open source projects.
Examples
- no translation of ASF, WMA and WMV files to any other format.
- patent licenses granted only to non-GPL software
CIFS implementations
- royalty fees on file sharing extensions to SMB in Win2K and WinXP
- Nasty letters to certain Linux kernel developers working on NTFS support.
The Halloween documents also mention the possibility that Microsoft may use Patents to attack OS endeavors.
We also have comments from Mr. Ballmer regarding
Responding to questions about the opening-up of the
And we also have this:
Asked by CollabNet CTO Brian Behlendorf whether Microsoft will enforce its patents against open source projects, Mundie replied, "Yes, absolutely." An audience member pointed out that many open source projects aren't funded and so can't afford legal representation to rival Microsoft's. "Oh well," said Mundie. "Get your money, and let's go to court."
Any statement that Microsoft has not and is not likely to enforce patents in these areas is just not backed up by the history, or by public statements by MS senior executives.
Re:Keep the zealotry to yourself (Score:2)
Rather, I was referring to the particularly dastardly practice of "submarine" patents, encouraging people to code to a standard before springing a patent on the world and forcing those that have adopted the standard to pay up.
For example, Microsoft submitted .NET to the ECMA as a standard, something that Sun has not yet done with Java (they tried but couldn't agree). In the openness stakes, that puts .NET ahead of Java IMHO - and those that claim that Java is automatically more trustworthy than .NET have failed to make their case.
Re:Keep the zealotry to yourself (Score:2)
I have heard
Re:Keep the zealotry to yourself (Score:2, Insightful)
Take a look at a comparative analysis [genamics.com] of c# to java and c++.
some features I particularly liked: delegates (and resulting event support), properties and indexers, and collection management.
Perhaps you should look at the c# and
Re:Keep the zealotry to yourself (Score:2)
I don't particularly see these as ARCHITECTURAL advantages, rather I see these as arguable syntactical advantages. And I don't agree that these are necessarily advantages. For example, let's take Properties.
Properties give you the ability to access mutators and accessors as if they were fields. Now that might seem to be an improvement, I would say that it actully muddies the syntactic distinction between fields and methods, making the code less readable. This is a bad thing IMHO.
To me an architectural advantage is a lot more fundamental; for example a something in the design that makes implementation of a certain design pattern easy. And to be honest this is something I am having difficulty with in ASP.NET. For example, ASP.NET and its framework make it very difficult to implement MVC in ASP.Net cleanly.
Re:Keep the zealotry to yourself (Score:2)
I think the delegates/events are a definite ARCHITECTURAL advantage as well as the Common Type System. The CLR is another advantage because it provides generic support for many other languages. Then you have the bytecode which offers an improvement for JITting because it was designed after a whole lot of research was done on this subject over the last few years. Also, the native generation is a nice feature.
Simply put, coming from a Java background I've found C#/.NET to be a very nice improvement. It just feels good to develop with it and it benefits from being new and shiny without all of the cruft that Java has built up over the years. That being said, I'd love for SUN to get onboard and create a Java# for the ECMA specs or perhaps to one up the C#/.NET standard. In the end I am both a developer with practical wishes/opinions and a Free Software advocate with philosophical needs.
BTW, I want to add that I approached Mono/DotGNU/.NET with an extremely skeptical eye and a protective feeling for my beloved Java. To my amazement I found a really nice framework that was a joy to work with. I am still skeptical of Microsoft and in particular the patent grousing that Ballmer et al, have been spewing. I just don't think this is a good enough reason not to use/develop it. As I've said elsewhere, the entire world of Free Software and all FS projects are endangered by software patents. SAMBA, wine, GCJ, linux kernel
Re:Keep the zealotry to yourself (Score:2)
Well, Delegates and Events have been severely criticized by some language purists, so I don't think that you can point to them as being a clear cut advantage.
I am not sure that the CLR is an architectural advantage, either. Sure, it lets you write in a variety of languages, but does it give you the abilitiy to express something different in each language? Not really, because you are limited by the underlying model as to what you can implement. The same applies to the CTS. In fact, there is a major criticism out there that the CTS/CLR has forced every language ported to
To be honest, I've found the CLR multi-language support to be quite annoying from another perspective. I want to write in C#, but the fact of the matter is that I've found a large percentage of code examples to be in VB.NET. This is a real PITA. To me this multilanguage thing is more like a marketing bullet point than something that is going to help me as a programmer.
Here is a prediction: In the long run software program managers are going to grow to HATE the multilanguage support in
There are also some things in
Sure, I think that
Maybe in 3-4 years when we have had a chance to digest it, and there is real experience with implementation of the standard body of design patterns on it we might have some evidence that
Um, Java++ == J++ (Score:2)
Whoopi (Score:3, Insightful)
Yeah, let's maybe stop making that ridiculous association between software, politics, the fate of humankind and the pursuit of life, liberty and freedom. It's just software. They're just computers.
Free: because everything else costs money and that sucks!
Re:Whoopi (Score:2, Insightful)
I can't believe that this totally idiotic troll got modded up to +4: Insightful! This project is the result of very talented and motivated coders and hackers doing to opposite of waiting for a product to be released. Therein lies the difference between a passive consumer and a real member of society. These folks were quite productive and have made tremendous steps towards a tool that the rest of us can benefit from. Yet an idiot like you bitches about it, and idiot moderators mod you up. Strange that the people doing things keep getting called zealots by those who oppose their actions solely because of the philosophy that motivates them.
Re:Whoopi (Score:3, Insightful)
We're always getting that mentality from the FSF -- that everything they build on is contemptible, and that they should be given complete, or at least vastly disproportionate, GNU/credit for everything they get their fingers into.
Re:Whoopi (Score:2)
When you have corporations trying to leverage monopoly positions in compter operating systems into domination of all financial transactions and industry organizations trying to extend copyright law beyond reason through lobbying activities it's a lot more than just computers and software.
It's about personal privacy, corporatism vs. representative government and ultimately whether a middle class will survive.
Re:Whoopi (Score:2)
Yes, before Bill Gates all hardware and software was free. That's why companies like IBM barely eeked out a living back in the 1960s.
Running Eclipse with gcj/gij (Score:5, Insightful)
It is possible to run Eclipse with gcj since it comes with gij (GNU Interpreter for Java). It does take a little bit of work to get it running since you have to apply some patches to the latest gcj CVS verson. Hopefully the needed patches will make it into CVS soon. It is currently a bit slow (you will need a fast processor, 1Ghz+ recommended) and needs much memory (256MB recommended). And not everything will work yet (it sometimes hangs). But is already useful for gcj bug hunting and making pretty screenshots.
If you just want to know why gcj is so cool, please read: Compiling Java with GCJ by Per Bothner (Learn how gcj can not only be used to compile java programs, but also Scheme and XQuery to native code.) If you are interested in other Free Software running on top of gcj, please checkout RHUG setup by Anthony Green. (It contains precompiled binaries of things like Jakarta Tomcat, Ant, Rhino, Postgresql JDBC drivers, Jython, Xalan, Xerces, and much more.)
It took much effort to get this far with our free java platform. And I want to thank all GNU Classpath and gcj hackers for their years of hacking to make this possible. In particular I want to thank Tom Tromey the main libgcj maintainer for his guidance. And for being the first person to get to the Eclipse Welcome Screen, after all his hacking the rest was easy.
I should also mention Vincent Partington and Erwin Bolwidt for explaining why I should care about Eclipse and for their bughunting help last weekend. Please checkout their free software projects, Jaxup.
How you can help: If you write free java software make sure it works well on the GNU platform and if you like hacking on low level stuff help us make Classpath and gcj even better. And please consider to "Join us now and share the software".
The following pages explain how to patch gcj and setup Eclipse. And show some pretty screenshots of Eclipse in action.
What do you need
If you want to run it yourself you should be familiar with compiling gcj from source (either current mainline or the gcc-3_3-branch) and you will need to apply the following patches.
These patches (except the verify.cc change) should be applied to CVS soon so you might not need them.
Update: The following new patches are highly recommended.
That last patch will optimize classloading for Eclipse that doesn't need any natively compiled classes but should not be used for normal gcj usage. The other patches will hopefully make it into CVS soon.
Update: eclipse.patch [klomp.org] contains all the above patches plus a few tweaks for getting Eclipse to work better on the IKVM.NET VM [weblogs.com]. With all these patches applied I was able to open, edit and compile the Jaxup Java XML Update engine project from my friend Erwin Bolwidt inside Eclipse. The new screenshot looks nice.
When you have build and installed the new GCC you will need to make the following changes to the install.
Go inside the bin directory of the new GCC install and make a java symlink to the gij program. (Eclipse expects a binary called java, you can give the -vm gij option, but then it won't autodetect gcj as Standard VM.)
Copy the share/java/libgcj.jar file to lib/rt.jar. Then create a directory jre/lib/ and make another copy of the rt.jar here. (Note that these cannot be symlinks.)
Make a directory src and copy the gnu, java, javax and org directories from the libjava source directory in it. Then create a src.zip file which contains this src directory. Put this src.zip file in the parent directory of the dir you installed the new GCC in. So if you installed in
This is all needed because eclipse expects a tradition java environment. It should be easy to hack org/eclipse/jdt/internal/launching/StandardVMType
Update: The following is no longer needed with the latest patches.
Disable the garbage collector by export GC_DONT_GC=1. If you don't do this eclipse will not startup properly and you will find a stacktrace in the workspace/.metadata/.log file mentioning a InvocationTargetException caused by a NullPointerException.
Finally get the latest stable Eclipse build (you want the eclipse-SDK-M4-linux-gtk.zip.) It will create a directory eclipse and comes with all the sources (and a precompiled binary and the classes in jar files).
Running it
Make sure that the freshly compiled gij (and the java symlink) is in your path and that LD_LIBRARY_PATH points to the newly installed lib directory. Go inside the eclipse directory and you should be able to just type
This will take several minutes. If anything goes wrong start it with
After several minutes you will see the following welcome screen.
One of the first things you probably want to do is set the correct key bindings
Not everything will work as expected and sometimes you are greeted with the following dialog. Which is often because the garbage collector is disabled. My machine quickly gives up after eclipse has eaten more then 600MB.
Update: There used to be a screenshot here of the terminal window showing lots of Out Of Memory messages. But with all the new patches this does not happen anymore.
Re:Running Eclipse with gcj/gij (Score:2)
Unless it has come miles in the last few months, it is just a toy at this point.
Re:I'm still missing this point (Score:3, Interesting)
Java is, for the most part, a losing battle as long as the current Sun is in charge. Making alternative runtimes isn't really what's needed to further Java, but the GNU people aren't trying to further Java anyway - they're trying to further 'Free' software, and apparently this was enough of an itch to scratch...
Re:I'm still missing this point (Score:2)
Not Ready? Its all about the plugins. (Score:4, Informative)
Java on the client-side needs this to compete... (Score:5, Interesting)
Up to this point, Sun has ignored the client-side, and rightly so. Because Microsoft and MFC rules on the client side (on Win32). Sun exploited the server-side breach that Microsoft had ignored.
But now, Java needs to become a viable alternative to C++ based programming on the client-side. And the only way this is going to happen is for Java to have some kind of a native GUI presence on each platform it runs on. This is where IBM and the SWT libraries come in.
Currently, the SWT libraries are still immature. The Eclipse platform itself is still immature. But they will get better and better. I predict that the SWT libraries will not only get quite expansive... but include things other than GUI widgets/toolkits.
If IBM plays their cards right (and so far they have)... I can see them actually introducing more Java extension libraries for other things that Sun did a terrible job on. Collections. Better native threading model. Better I/O model. The list goes on and on.
Personally, I would have no problem with writing a Java application that only imported IBM extension libraries. As long as they were well-written, and performed well.
Sun really needs to get on the ball here. The time has come to open-source Java. Let the developers do with the language what needs to be done to bring it to the next level.
Otherwise... companies like IBM are going to do it anyways. Just using extension libraries. If Microsoft was smart, they'd have done five years ago what IBM is doing now. Microsoft would own Java on the client-side if they would have played it right.
Re:Java on the client-side needs this to compete.. (Score:2, Insightful)
SWT library already does include GUI widgets/toolkit.
You are right though, saying that it is immature. We've been doing some serious development on SWT trying to convert full featured application from AWT to SWT. So far it's been going great.
However, here's a warning for all of you Java developers: there's quite a few things you still can't do. All Table work is a terrible hassle, there's no easy way of changing colors in single table cells and table functionality is very, very limited. We were able to improve some of that, but that actually ment implementing our own widgets for table. Anyways, it is pretty bad. Hopefully in 2.2 version (next year) they will solve some of the problems.
If anyone from Eclipse development community is reading, please, focus more not on the new features (cheat lists, wizards and stuff), but try to actually make SWT a reacher platform, there's a lot of work that needs to be done.
At the end, I wanted to summarize my opinion of SWT, which is not really what this topic is about. But here it goes: it is a great platform and a great concept (using native libraries and not drawing everything like Swing does). And you are correct - this will/could be Java's savior on the client. But anyone who would want to write a serious application in SWT should think twice before that, wheigh down all pros/cons and also try writing a prototype to make sure that it you can implement anything that you want.
One of the biggest innovations of SWT is a library called JFace, which hides a lot of basic/low level GUI functionality under an interface that is sort of a Model-View-Controller framework. This idea is brilliant, and this framework is just a pleasure to work with.
Anyways, enough with the rambling.. Happy Christmass, everybody!
I disagree in many respects (Score:4, Insightful)
"Microsoft and MFC rules on the client side (on Win32)".
MFC is dead, long live
"But now, Java needs to become a viable alternative to C++ based programming on the client-side."
Absolutely not. Java's only main competitor for Win32 client-side supremacy is VB.NET and C#.NET. C++/MFC is a dead-end.
On UNIX, I would suggest it's a toss-up between C++/Qt and C/GTK, and IMHO I think Java's more productive than either (though pre-1.4 X-windows Swing performance was unacceptable).
Sadly, this doesn't seem to be a battle that Java will win on Win32, even with SWT, for a couple of reasons. Microsoft has the industry's talent in developing high-performance Win32 GUI framewords, which will come out for
They also have the tools support with Visual Studio. The Java world currently has only *ONE* usable GUI building tool -- JBuilder. And that's not saying much. Eclipse won't have one for some time. The second major problem with Swing (besides performance) was this lack of tools support. I don't forsee a groundswell of tools support for SWT from multiple vendors.
Thirdly, there isn't a whole lot of impetus behind client-side "thick" GUIs in the industry. I don't foresee IBM throwing lots of money at making SWT general-use... the open source community will probably assist in this area, but I'm somewhat skeptical about how much adoption this will generate.
On the bright side, I'm not sure it really "matters". Windows peeps will write stuff with VB like they've always done, the C++'ers will switch to C# (they've really not much choice -- I worked at an MS shop as the Java junkie for 2 years, most C++/Windows programmers there took what MS has given them... there's a lot of shock and dismay when Borland/OWL is on one's resume). The 2nd most widely used GUI framework family will be (gasp) Carbon/Cocoa on Mac OS X. ANd rounding out the list, *nix peeps will continue head-butting between Qt and GTK+ (both of which are still gawdawfully ugly IMHO, quite apparent actually if you run a GTK+ app side-by-side with a Mac OS X application. But I digress).
"I can see them actually introducing more Java extension libraries for other things that Sun did a terrible job on. Collections. Better native threading model. Better I/O model. The list goes on and on."
Whoa, whoa! I disagree with each one of these. We are talking about J2SE 1.4, are we not? I'm quite happy with the collections framework (and I compare this to both stdc++ and the Smalltalk collections library), the java.nio.* package is very sophisticated, and IMHO the threading model is a matter of taste, not stemming from any particular technical disadvantage.
Re:I disagree in many respects (Score:2)
1.4 isn't acceptable either. Better than pre 1.4? Yes. Functional? Yes. Acceptable? Haven't seen anything yet which leads me to believe it's 'acceptable'.
I come to bury VB not to praise it (Score:2)
But it still is the most popular client-side language in the world.
Regardless of the politcial debates surrounding
.NET in a nutshell (Score:4, Informative)
Here's the things that it isn't (in reality):
- A new server platform (MIcrosoft marketed it as such, even though there really isn't anything new in their Windows 2000 lines of servers yet).
- A some new magic technology (i.e. the marketing idea that MS Passport became Passport.NET and thus was embued with a +6 long-sword)
Here's what it is:
- The common type system, language spec, and language interface. (CTS, CLS, and CLI). It's a way of getting several languages to interoperate through a virtual machine.
- The Common Language Runtime (CLR) for Win32. This is the Virtual Machine. It's as fast as Java 1.4 in some ways, slower in some ways, and over 2x faster at certain operations like object creation. Ya gatta hand it to Microsoft's x86 team, they know their stuff.
- The following languages are released by Microsoft for
- The Base Class Libraries (BCL), ASP.NET, COM+ (aka Managed Components), and ADO.NET are included.
- The ECMA standards body has been submitted the CLI, CTS, CLS, BCL, and C#. Mainly for show, but maybe something good may come from Miguel et al.
What's
- It's a much better way for binary module interoperability than COM was. Viewed this way,
The language-interop issue at first glance seems like a red herring feature, but in fact it's rather important from a programmer's sociological perspective. VB and C++ programmers are naturally opposed to each other in philosophy - their means and ends do not peacefully coexist.
Things you can do with
- The Windows Registry is NO LONGER NEEDED. Nothing in
- Easy and Flexible Side by side versioning. An app that links against a version stays with that version unless updated or a sysadmin coerces it to use a newer DLL version.
- No filename conflicts (i.e. no 2 vendors with MYSILLYLIBRARY.DLL overwriting each other -- each DLL has a public key stamp)
Other things... Making web services in
So -- you see,
The jury's still out as to whether
I say it's more about "syntax skin" than "flexibility". Certainly you can write Lisp onto
Re:Java on the client-side needs this to compete.. (Score:2)
Uh that's EXACTLY what Microsoft did! Extentions for COM, the WTL, delegation event model, etc. And what'd they get for their trouble? A lawsuit from Sun!
Just use Anjuta (Score:4, Interesting)
Re:Just use Anjuta (Score:2)
The Eclipse framework serves the same purpose as Swing. The Eclipse project is much more than an IDE.
Waste of Effort (Score:5, Interesting)
I think that the Java libraries will be very difficult to control fully by Sun, because they do not have IBM and Oracle to push around. IBM will absolutely not be backed into a corner by one of their main competitors in hardware, Sun. Because of that, I'm not worried about the Java APIs turning into a controlled arena, as Microsoft has done with Windows.
Basically, I think the effort of the Open Source community, of those that like Java, would be much pretty spent on making GCJ integrate seemlessly with a compliant Java VM using JNI. GCJ could used to make a just-of-time optimizer. With C# and dotNet, I think there's an ahead-of-time compiler instead of a just-in-time compiler that can optimize the byte code for the target machine. Using GCJ/GCC, one could get that sort of performance boost, almost for free, if it were plugged into a compliant Java VM, meaning that it could integrate with DLL/DSOs using the Java Native Interface.
Anyway, I, for one, would probably not waste my time using a slightly out-of-date API, on a slightly behind-the-curve VM or compiler. (BTW, I'm a heavy user of emacs, perl, mozilla, etc.) The java API, language and VM still has a LOT of room for improvement. I hope developers would rather innovate and improve the java standard than to fork off a clone.
Re:Waste of Effort (Score:4, Interesting)
I'd like to see a Free clone of Java, and then a community develop around the clone to CHANGE it into a better language. For instance, I'd like to see templates ("generics") added to java. I'd like to see type-safe enums. I'd like to see some "syntactic sugar" to make programs easier to write and read (hello, iterators). I'd like to see a GNU/Java implementation that has all this stuff and more, but is still backwards compatible with Sun/Java.
I'd like to see native-code only Java. I'd like to see GTK+ bindings for Java. I'd like to see all the old library cruft cleared out of Java. Heck, I'd like to see Java pre-installed on Red Hat, without coming on a separate CD with a separate license and a crappy RPM that was made by Sun. I wish it was available on FreeBSD sooner. I wish a lot of stuff that's only possible or easy with third-party implementations.
Re:Waste of Effort (Score:3, Interesting)
Many of the features you describe could still be done by compiling a Java++ superset language into the same bytecode or by translating to java code, like AT&T's cfront did for the original C++. The native-only stuff could be done directly on the byte code, or using something like GCJ to optimize java/java++ to machine code. Way back in java 1.0, SGI had a tool called javat which did almost that. It translated bytecode into machine code, but was not good at optimizing it. That's where GCJ/GCC would be very handy, since there's a full optimizing compiler in it. But my point is that these examples could still be done with the existing Java VM architecture. Language features, alternative syntaxes, and optimizers don't require reimplementing everything from scratch. IBM's jikes compiler is a very fast java compiler (written in C/C++) that adheres strictly to the Sun specifications, but it is buggy as hell. Reimplementing these things is not trivial.
Anyway, I agree that rapid innovation is definately easiest when all the source is available. Mozilla, Linux, and emacs (in the 90's) are great examples of that. Rapid innovation is great for applications because the end-users can benefit immediately, and if something changes, then they can change their habits.
However, for languages and APIs, standardization is very important. Many things depend on them: Documentation, applications, example code, tutorials, third-party books, training seminars, university courses, etc. which are all in the realm of developers. Developers suffer when source trees, APIs, or software practices become needlessly fractured. HTML and the Netscape/Internet Explorer browser wars is a great example of how web developers were saddled with two camps of HTML and zillions of incompatible dialects and implementations. We are still burdened by incompatibilities from those rapid innovation cycles.
My ideal scenario would be that I could take JAR files from GNU, Apache, Borland, Oracle, IBM, etc. and mix them together and get an optimized precompiled (maybe native-only) executable. But some standardization mechanism is needed so they can all talk to each other, (unlike the horrible linking incompatibilities between all C++ compilers). It doesn't have to be Sun; maybe it could be Sun/IBM/ECMA/ANSI. But it will likely be some company, since non-profit standards bodies usually move very slowly. Linux, for instance, has been standardized for the corporate world by RedHat primarily, not the UnitedLinux group or even Linus (who's focus is the kernel).
The important consideration is that there is a limited set of developer resources, even with thousands of open-source community eyeballs. Microsoft is the prime competitor to java, and Sun, IBM, Apple, etc are not. They are closer to being corporate resources and allies. As long as they remain good supporters of a unified java and don't create obstacles to the future use of these APIs/VMs, then I don't see why we shouldn't use them as resources, and thereby build upon their work instead of duplicating it.
Re:Waste of Effort (Score:2)
--jeff++
Re:Waste of Effort (Score:2, Insightful)
Basically, I think the effort of the Open Source community, of those that like Java, would be much pretty spent on making GCJ integrate seemlessly with a compliant Java VM using JNI.
I doubt that it would be practical. JNI does a lot of bookkeeping and is doomed to be far slower than whatever internal calling convention a JVM uses. You'd lose whatever advantages native compilation may have.
I hope developers would rather innovate and improve the java standard than to fork off a clone.
How can they innovate that for which they have no source code? The free implementation must come first. First they make it complete, then make it fast, then make it better.
Old news (Score:2, Informative)
Nevertheless, this is the best tool I've used, and really, thanks IBM for doing such a great and generous job. My point is - this is not really news, and have nothing to do with Christmass.
Cheers.
Re:Old news (Score:2)
GCC vs GCJ? (Score:2)
Useless to RMS, maybe (Score:5, Insightful)
If you define the "Free Software community" as the zealotous 5% of free software users who refuse to use software that hasn't been blessed by RMS, you're right.
For the rest of us, Eclipse has been useful (and free and open source) for over a year.
Re:Useless to RMS, maybe (Score:3, Insightful)
Re:Useless to RMS, maybe (Score:2)
-> no linux (gcc required, you MIGHT try icc)
-> no gnome (maybe parts of kde, IF you get it compiled without gcc)
->
(even parts of windows 2k/xp were written by open-source "zealots" so I suggest you stay away from it too
Keep in mind that those ideals also started the cooperative development that free source code sharing enables, so indirectly he's responsible for much more software.
Re:Useless to RMS, maybe (Score:4, Insightful)
This statement is heresy ONLY if you believe Free Software and RMS are synonymous. I believe they are not. Free Software existed well before RMS, and will exist well after he is gone. He only "created" Free Software if you accept his conceit that Free Software is only software that follows his definitions of Free [gnu.org]. I do not. He has contributed a lot to this world, but didn't invent the world. Many people don't realize that The Cathedral and the Bazaar [tuxedo.org] wasn't necessarily contrasting the development styles of commercial software vs. free software, but different styles of development within Free Software itself, and the RMS driven gcc was the example of the "closed" Cathedral. Because of the lack of innovation in gcc, especially around the time ANSI C++ came out and it needed large changes, folks forked gcc into egcs, a more "bazaar" style development model, that eventually became the offical gcc. Or are you saying Eric Raymond has nothing to say on the topic of Free Software because he differs with RMS?
Or if this was a troll, nevermind.
Give me a break (Score:4, Interesting)
There is plenty of java code that has been released under the GPL and BSD licenses. The only way that java would be useless to someone is if they turned their nose up at it. Turning one's nose up at something for non-technical reasons is usually a bad idea.
Lee
The point (Score:5, Insightful)
The point that so many have missed is that this shows how close the GNU implementations are to be being a complete JDK replacement. Eclipse is a very complex beast that uses nearly all of the Java APIs. This achievement shows the quality of the years of work that has gone into these free projects. All of this work is now finally ready to pay off.
Congratulations to the whole ClassPath and GCJ teams!
-Avery Regier
Damn (Score:2)
How Eclipse/SWT saved the GCJ project (Score:4, Insightful)
Compiling your application to a single binary (or
Java doesn't suck. Java's GUIs need not be slow. It was Swing that sucked. Finally people realize where to lay blame.
Sun - get rid of Swing once and for all! Swing is a poorly designed GUI tookit and a complete embarassment to Java.
Ah, Java (Score:2)
Re:Ah, Java (Score:2)
I've been developing Java code professionally for a little over two years now, writing server-side stuff for web sites. About half of us work under Linux, the rest using either Win2k or XP, deploying the code on machines running RedHat, and we've never had any trouble.
Of course, if you're talking about applets, then your problem isn't with Java, but with the browser producers' broken JVMs (especially the MS one, which simply isn't worth bothering with). Applets are only really of any use if you control the client environment, right down to being able to tell people to download a new JVM. No use for silly little toys on websites, but fine for more complex, bespoke stuff (although still a pain in the arse to develop, of course, especially if you're not used to creating GUIs).
I have a dream (Score:2)
I can already see problems arising with Mono in that I simply don't trust MS not to try and kick it in the balls with a patent suit after it has started to become widely used.
Java is easy to use and secure, and at the moment, on cellphones which have Java bytecode instruction sets in their CPU's, is anexcellent opportunity for expansion. Cellphones are a booming market and present a real chance for Java on the client side with J2ME. Being able to compile to native code would make it even better suited for that purpose. MS knows how important the Cellphone market is which is why they are up to their tricks and abuse there again (Sendo) and which is why almost all Cellphone makers are giving MS a wide berth and are using Symbian, which brings the story back to Java...
Starting with Eclipse; Help a newbie! (Score:2)
Maybe you have books to recommend. Please provide any helpfull info you got (libraries to suggest, tricks, etc...) that would help a newbie to jump start quickly on this platform.
Aww man! (Score:2)
Proprietary platform (Score:2)
Re:so what? (Score:3, Interesting)
The second one.
I sense that your question may have been rhetorical, but I just thought I'd cast my vote anyway.
Re:so what? (Score:3, Insightful)
Let's think about the possible scenarios here. You said that you predict Sun will either "crush the foundations of these projects" or "force compliance with some IP-ridden future standard." How could this come to pass?
If Sun has a patent that covers some core aspect of the Java runtime environment, then they could probably put a stop to the distribution of Classpath. If this is the case-- I have no idea whether Sun holds any such patents-- then they will be right to stop distribution of Classpath.
The same could theoretically be said about GCJ, but this seems much less likely. IBM has had their own Java compiler, Jikes, for some time, and Sun has shown no sign that they disapprove of this in the slightest.
So pretty much the only way that anybody could "crush the foundations of these projects" would be a patent action against the FSF over Classpath. But-- and this is critically important-- the same can be said of all FSF software. If anybody has a patent that covers anything the FSF has made, they could sue the FSF to stop distribution of that product. In fact, this dirty little secret is often used by those who oppose the FSF to cast doubt in the minds of potential users of the FSF's software. If it's FUD for them, it's FUD in this case, too.
What else could Sun do? Well, they could change the Java specification. In fact, they do this all the time. Java 1.4 is out, Java 1.5 is coming, and there will surely be another release of Java after that. Each one of these releases brings significant changes. The FSF will have no choice but to modify Classpath to keep up with Sun; that's a natural consequence of cloning somebody else's platform. So since this is inevitable, it's kinda silly to talk about it in terms of "crusing the foundations of these projects" as well. Sun will change the runtime specification, and Classpath will lag behind. It's the nature of the beast.
As for "forcing compliance with some IP-ridden future standard," I don't see how that could happen at all. The FSF isn't a licensee of Sun's, so Sun has no authority to try to force them to comply with anything.
Re:Why should I use Eclipse instead of Emacs + JDE (Score:5, Funny)
Re:Why should I use Eclipse instead of Emacs + JDE (Score:5, Informative)
Eclipse is an IDE without all the crap you usually associate with an IDE. JDE isn't bad, but it's nothing like Eclipse. Eclipse's debugging support in particular is way better than JDEs (which took me some hours to configure properly). Not to mention that Eclipse let's you do really neat things, like stop the debugger right before an exception was thrown, fix the bug, and continue with the debugging as if nothing had happened!
Re:Why should I use Eclipse instead of Emacs + JDE (Score:2)
Heck, even Visual Basic has this. I got used to it, and I've been disappointed that I couldn't get it elsewhere. It's quite nice.
Re:What do you mean GNU present??? (Score:2)
Whoa! Whoa! and Whoa! there buddy. Speaking of crackpots, you've been smoking from yours a little too heavily.
This post has nothing to do with the fine work the folks at IBM have done on Eclipse. That's old news.
This article is about the GNU components that have been released to allow Eclipse to run with all Free components.
I know it's trendy to bash RMS, and the Slashdot editors, but let's save that for when they are actually doing stupid stuff.
Re:SWT binaries? (Score:2, Informative)
Yes, absolutely. Get ftp://sources.redhat.com/pub/rhug/swt-gcj-green-s
Run configure/make/make install, and you'll en up with lib-org-eclipse-swt.so.
People are also building for Win32 using gcj for Windows (or a cross compiler from Linux)
AG
Re:SWT binaries? (Score:5, Informative)
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 [sun.com] 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. [eclipse.org] There is some GCJ and SWT [gnu.org] info available here. [ibm.com]
Re:SWT binaries? (Score:2)
SWT [...] abandons [...] the idea that the same binary must run on all platforms. [...] Even though the libraries are implemented completely differently, the public interfaces are the same.
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.
SWT and AWT both use JNI, so both (the libraries themselves, not consumers thereof) need to be compiled for the appropriate platform. The only difference is that Sun makes AWT, so you can assume that it came with the JVM and avoid distributing your own copy. Probably not a reasonable assumption for SWT.
Re:SWT binaries? (Score:2)
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.
Re:SWT binaries? (Score:2)
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.
Re:Useless how? (Score:2)
Shush, you'll start giving them ideas...
Seriously though, you seem to be forgetting that you're talking about people who believe that all code should be free. It doesn't matter to these people that the free and proprietary JVMs will be indistinguishable (at least to Eclipse), they know that there's a difference.
Personally, I don't care; I've been developing in Java for a little over two years now, and have never had a problem that could've been solved by it being Free. You get the source to the core APIs with the SDK, and I don't do anything that would require the source to the JVM. If they care enough to spend their time developing something like this, though, good on them. I won't be using it myself, but I certainly have to give them credit for actually living by their principles.
As for the hardware, if it weren't so expensive and difficult to make, you can bet there'd be a Free x86 compatible processor available. As long as manufacturing costs are as high as they are, though, we're not going to see one. Again, I don't care - my P4 works just fine. Then again, I'm a little more pragmatic; I'm a professional coder, working on closed-source code (unless the client pays for the source too), so I can't afford not to be.