Nice indignation here, with Liskov, component stereos and all.
But you've got it quite wrong, I'm afraid. And then I'm assuming that you mean java.lang.NoSuchMethodError, and not javax.mail.MethodNotSupportedException which is something else completely.
NoSuchMethodErrors only occur when you run code that wouldn't compile (such as when you remove a method, but forget to recompile users of that method).
And since you refuse to use the compiler, what's a poor runtime supposed to do when you call a non-existing method? Create one for you? Or install a new tuner?
Ok, RMS (*ahum*) consistency is impressing. But he's not quite on the money here.
I'm pretty sure that the BitKeeper adventure has been, overall, good for kernel development. Linus and a lot of the others liked it, and felt productive using it.
More importantly, the switch to something else seems to go quite swiftly. git and cogito are already good enough to manage the kernel (if a little rough around the edges yet).
In other words, the price for dumping BitKeeper was pretty low. And so was the risk taken by using it.
And that's exactly the point of free software: nobody can take it away from you. That keeps the risk in using it low.
The risk and cost of using non-free software might be ok if you can live without it. But use free software for important stuff.
A better frontend is already coded. See git-pasky.
It is early days, of course, but this git should be easy enough to use for anyone who's been using cvs, subversion or the others. You do "git commit", "git commit", "git log", etc. And it's fast. On my poor laptop, "git diff" takes 0.1 second over the entire 235M kernel source.
This is the frontend to Linus' git stuff, and may be renamed Cogito to prevent confusion.
svk may be a reasonable compromise. It is a distributed scm, but built on top of the very stable Subversion. It is very fast, even for large trees, despite being written in perl.
It is also quite easy to use svk together with a central Subversion repository, to get the best of both worlds.
Sure, Sun's been a pretty good steward. But that's not the point: java could be doing so much better as free software. A free java would have at least two big advantages:
Sun has basically left some parts of the "standard java libraries" to rot. That applies to Swing in particular: no major changes here the last few years. One example: there is still no support for Cleartype or Xft, so fonts are looking pretty 1997-ish in Swing. And fonts are kind of a big deal in any gui-based app.
But more importantly: free software is more dependable. If Sun should fold, no one knows what would happen to java. If Sun gets into serious financial difficulties, it might stop making the JDK available as a free download. Etc.
That risk would disappear over night if java was free software.
At the very least, the libraries should be opened up. It is fairly easy to create an open source VM (comparatively): java's virtual machine is fairly well specified.
The libraries are much harder to implement: the fine folks at GNU Classpath are working hard to provide a free version of the library (which is used in gcj, kaffe, jikes rvm, etc.). But since large parts of the library are so poorly specified, they will always be lagging "official java" quite a bit.
First of all, gcj is much more than a replacement for javac: it's a complete java VM.
Secondly, it's much more than just a VM, since gcj also is an ahead-of-time compiler (like gcc is for C). That means huge gains in startup time and memory consumption, compared to Sun's VM.
You can tell Swing to use the native LNF (Look'N'Feel) and it will now look like GTK, XP, 2K, Mac
Yes, you can tell Swing. Trouble is: it won't listen:-)
The only native L&F that is even half decent is the one on OS X (written by Apple). The others aren't even close. For starters, Swing doesn't even support native font rendering (meaning that fonts look different, and awful, and without Cleartype/Xft support).
The Sun SDK comes with sources to the standard API classes
The JDK may come with (some) source, but it is not open source (meaning free software). You are not allowed to use Sun's library classes with a free VM (such as Kaffe, gcj, etc.).
Even if the USPTO doesn't employ the brightest of minds, their employees can't be this stupid. There must be some kind of bribe involved (a big one, one would hope).
Basically, this patent covers combining "scripts" (as in perl, javascript et.al) that are usually stored in separate files into a single XML file. It doesn't even have to be kosher XML: the patent says XML "or the like".
This is the kind of patent that you could easily violate without knowing it existed: all you have to do is (1) lump together scripting code in one file that vaguely resembles XML and (2) let a user decide which script to run. That's all
only each distribution of linux supports a different one
The real problem isn't package formats (as your example with Suse and RedHat shows).
It's simply that distributions are different. Pretty much any non-trivial Linux program needs a lot of libraries that are non-standard (as in: not in the LSB). Different distributions make different choices, which is probably a good thing, but it breaks binary compatibility between distributions. This has (pretty much) nothing to do with package formats.
Packages in typical Linux distributions pretty much do the same things as MSI files on Windows, except that they do much more.
1. They describe how to build from source. That is (obviously) a big deal on an open source platform, since it makes builds repeatable, and so not depending on the magical build environment of one company or person.
2. They deal with dependencies: package "foo" can dictate that it needs package "bar" to work correctly, and that it needs package "foobar" version 2.32 or higher to build. This is a Good Thing, as you don't have to find out what the dependencies are the hard way.
This causes some problems from time to time, since distribution X may not have package "foobar", but the real problem here is that distributions are different. This may also be seen as a good thing: package management is a way to deal with diversity.
3. Standardised package management in a distribution makes other Good Things possible, such as automatic installations of all dependent packages, or automatic upgrades, thanks to tools like apt and yum and the dependency information in packages. That means that you can make sure that every program on the system is up-to-date with just one command.
Another really Good Thing is that package managers allow a lot more control over installations: they know which files are installed by which packages. That makes it possible to check, say,/usr/lib for any shared libraries that are no longer in use, or if any files have been altered. Thanks to dependency handling, it is also safe to remove unneeded old stuff (i.e. you don't have to put up with a gazillion old.dlls in c:/WINDOWS/SYSTEM32).
No. -source 1.5 implies -target 1.5. And even if the bytecode is basically the same, jdk1.4 refuses to run code compiled with -source 1.5 (with javac from 1.5.0beta). All you get is a java.lang.UnsupportedClassVersionError.
the JDK 1.5 compiler is 100% compatible with JDK 1.4
Unfortunately, you're wrong.
To use the new language features, you have to use the "-source 1.5" switch with javac from 1.5.0. That makes javac create bytecode that can only be used with JDK1.5 (see the javac docs).
is there any note on how this may impact things like HttpSession or HttpServletRequest attributes, where different data types are essential?
No impact whatsoever; generics is supposed to be totally backwards compatible. So you can still store Objects in a HttpSession, use a plain HashMap (without pointy brackets), etc.
SWT is the future of Java GUIs.
I agree. But, nevertheless, it's a pity that Sun is letting Swing bitrot. I'm still a big fan of Swing's API, flexibility and close-to-perfect crossplatformness.
You're talking about C++.
Generics in Java 1.5 is very different. Basically, Java generics is a way to avoid a lot of ugly casts when using collections like ArrayList and HashMap. That makes code more readable, and will catch more type mismatch errors at compile time. Nothing more, nothing less.
That's a far cry from a "turing complete template/generics system".
I really like the new language features (and will use them in about 5 years when our server is upgraded:-().
But Swing is even uglier than before. Metal still looks very old, but now it looks like someone very old with obscene amounts of make-up on.
The GTK+ look is even worse. It doesn't look like GTK+ at all (I'm not even sure whether it's supposed to be GTK1 or GTK2).
Worse: font rendering is abysmal. Buttons and menus are barely readable using the GTK+ emulation L&F. The Java VM still doesn't use Xft/Freetype, which pretty much makes the attempt at GTK+ emulation useless.
More importantly (in a text editor), it has excellent font support, thanks to GTK+'s fontconfig/freetype support. AWT/Swing basically only supports the quite unreadable Lucida fonts that are included in the JRE -- and no sub-pixel anti-aliasing.
That hurts readability a lot, especially on an LCD monitor.
Slashdot Mirror
But you've got it quite wrong, I'm afraid. And then I'm assuming that you mean java.lang.NoSuchMethodError, and not javax.mail.MethodNotSupportedException which is something else completely.
NoSuchMethodErrors only occur when you run code that wouldn't compile (such as when you remove a method, but forget to recompile users of that method).
And since you refuse to use the compiler, what's a poor runtime supposed to do when you call a non-existing method? Create one for you? Or install a new tuner?
I'm pretty sure that the BitKeeper adventure has been, overall, good for kernel development. Linus and a lot of the others liked it, and felt productive using it.
More importantly, the switch to something else seems to go quite swiftly. git and cogito are already good enough to manage the kernel (if a little rough around the edges yet).
In other words, the price for dumping BitKeeper was pretty low. And so was the risk taken by using it.
And that's exactly the point of free software: nobody can take it away from you. That keeps the risk in using it low.
The risk and cost of using non-free software might be ok if you can live without it. But use free software for important stuff.
A better frontend is already coded. See git-pasky.
It is early days, of course, but this git should be easy enough to use for anyone who's been using cvs, subversion or the others. You do "git commit", "git commit", "git log", etc. And it's fast. On my poor laptop, "git diff" takes 0.1 second over the entire 235M kernel source.
This is the frontend to Linus' git stuff, and may be renamed Cogito to prevent confusion.
It is also quite easy to use svk together with a central Subversion repository, to get the best of both worlds.
This story is a bit old already. See groklaw.
Sure, Sun's been a pretty good steward. But that's not the point: java could be doing so much better as free software. A free java would have at least two big advantages:
Sun has basically left some parts of the "standard java libraries" to rot. That applies to Swing in particular: no major changes here the last few years. One example: there is still no support for Cleartype or Xft, so fonts are looking pretty 1997-ish in Swing. And fonts are kind of a big deal in any gui-based app.
But more importantly: free software is more dependable. If Sun should fold, no one knows what would happen to java. If Sun gets into serious financial difficulties, it might stop making the JDK available as a free download. Etc.
That risk would disappear over night if java was free software.
At the very least, the libraries should be opened up. It is fairly easy to create an open source VM (comparatively): java's virtual machine is fairly well specified.
The libraries are much harder to implement: the fine folks at GNU Classpath are working hard to provide a free version of the library (which is used in gcj, kaffe, jikes rvm, etc.). But since large parts of the library are so poorly specified, they will always be lagging "official java" quite a bit.
Free java! Or at least the libraries.
GCJ still far behind Sun's Javac
First of all, gcj is much more than a replacement for javac: it's a complete java VM.
Secondly, it's much more than just a VM, since gcj also is an ahead-of-time compiler (like gcc is for C). That means huge gains in startup time and memory consumption, compared to Sun's VM.
So, you win some, you lose some.
You can tell Swing to use the native LNF (Look'N'Feel) and it will now look like GTK, XP, 2K, Mac
:-)
Yes, you can tell Swing. Trouble is: it won't listen
The only native L&F that is even half decent is the one on OS X (written by Apple). The others aren't even close. For starters, Swing doesn't even support native font rendering (meaning that fonts look different, and awful, and without Cleartype/Xft support).
The Sun SDK comes with sources to the standard API classes
The JDK may come with (some) source, but it is not open source (meaning free software). You are not allowed to use Sun's library classes with a free VM (such as Kaffe, gcj, etc.).
Even if the USPTO doesn't employ the brightest of minds, their employees can't be this stupid. There must be some kind of bribe involved (a big one, one would hope).
Basically, this patent covers combining "scripts" (as in perl, javascript et.al) that are usually stored in separate files into a single XML file. It doesn't even have to be kosher XML: the patent
says XML "or the like".
This is the kind of patent that you could easily violate without knowing it existed: all you have to do is (1) lump together scripting code in one file that vaguely resembles XML and (2) let a user decide which script to run. That's all
Yes. FC2 has two "stop-ship" features: 2.6 kernel and SELinux. See the schedule.
According to one of SCO's lawyers, in a letter published on Groklaw, SCO only managed to sell three "Linux licenses".
Yes. Three (3).
He says: "At this juncture, I am only aware of a license with Computer Associates, Questar and Leggett & Platt."
I'm betting you can get a good price on a used Linux license from them by now...
The real problem isn't package formats (as your example with Suse and RedHat shows).
It's simply that distributions are different. Pretty much any non-trivial Linux program needs a lot of libraries that are non-standard (as in: not in the LSB). Different distributions make different choices, which is probably a good thing, but it breaks binary compatibility between distributions. This has (pretty much) nothing to do with package formats.
OK, I'll bite...
/usr/lib for any shared libraries that are no longer in use, or if any files have been altered. Thanks to dependency handling, it is also safe to remove unneeded old stuff (i.e. you don't have to put up with a gazillion old .dlls in c:/WINDOWS/SYSTEM32).
Packages in typical Linux distributions pretty much do the same things as MSI files on Windows, except that they do much more.
1. They describe how to build from source. That is (obviously) a big deal on an open source platform, since it makes builds repeatable, and so not depending on the magical build environment of one company or person.
2. They deal with dependencies: package "foo" can dictate that it needs package "bar" to work correctly, and that it needs package "foobar" version 2.32 or higher to build. This is a Good Thing, as you don't have to find out what the dependencies are the hard way.
This causes some problems from time to time, since distribution X may not have package "foobar", but the real problem here is that distributions are different. This may also be seen as a good thing: package management is a way to deal with diversity.
3. Standardised package management in a distribution makes other Good Things possible, such as automatic installations of all dependent packages, or automatic upgrades, thanks to tools like apt and yum and the dependency information in packages. That means that you can make sure that every program on the system is up-to-date with just one command.
Another really Good Thing is that package managers allow a lot more control over installations: they know which files are installed by which packages. That makes it possible to check, say,
The docs are (obviously) not very clear. But in fairness -target 1.4 is the default - unless you specify -source 1.5.
You've confused source and target.
No. -source 1.5 implies -target 1.5. And even if the bytecode is basically the same, jdk1.4 refuses to run code compiled with -source 1.5 (with javac from 1.5.0beta). All you get is a java.lang.UnsupportedClassVersionError.
No, that would be an invention that does exactly what it claims to do, wouldn't it?
Oh, never mind...
No (assuming you mean javac). javac reports "javac: source release 1.5 requires target release 1.5" if you try that.
the JDK 1.5 compiler is 100% compatible with JDK 1.4
Unfortunately, you're wrong.
To use the new language features, you have to use the "-source 1.5" switch with javac from 1.5.0. That makes javac create bytecode that can only be used with JDK1.5 (see the javac docs).
is there any note on how this may impact things like HttpSession or HttpServletRequest attributes, where different data types are essential?
No impact whatsoever; generics is supposed to be totally backwards compatible. So you can still store Objects in a HttpSession, use a plain HashMap (without pointy brackets), etc.
SWT is the future of Java GUIs. I agree. But, nevertheless, it's a pity that Sun is letting Swing bitrot. I'm still a big fan of Swing's API, flexibility and close-to-perfect crossplatformness.
You're talking about C++. Generics in Java 1.5 is very different. Basically, Java generics is a way to avoid a lot of ugly casts when using collections like ArrayList and HashMap. That makes code more readable, and will catch more type mismatch errors at compile time. Nothing more, nothing less. That's a far cry from a "turing complete template/generics system".
I really like the new language features (and will use them in about 5 years when our server is upgraded :-().
But Swing is even uglier than before. Metal still looks very old, but now it looks like someone very old with obscene amounts of make-up on.
The GTK+ look is even worse. It doesn't look like GTK+ at all (I'm not even sure whether it's supposed to be GTK1 or GTK2).
Worse: font rendering is abysmal. Buttons and menus are barely readable using the GTK+ emulation L&F. The Java VM still doesn't use Xft/Freetype, which pretty much makes the attempt at GTK+ emulation useless.
VHS, on the other hand, deserves to die. Now. VHS is just evil.
SWT GTK is unusable under Linux
I beg to differ: it's very usable for me.
More importantly (in a text editor), it has excellent font support, thanks to GTK+'s fontconfig/freetype support. AWT/Swing basically only supports the quite unreadable Lucida fonts that are included in the JRE -- and no sub-pixel anti-aliasing.
That hurts readability a lot, especially on an LCD monitor.