sh and ksh are separate for a reason. Solaris sh (more so than other sh's) is *very* stripped down -- no tab completion, no command history, etc. -- so that there are no side effects. When you hit tab, you get a literal tab. That makes it harder for hackers to place little "easter eggs" and make "!!" expand to "rm -rf/"./lib and/usr/lib are separate for similar reasons./lib holds system libraries, while/usr/lib holds user-installed libraries. It makes threat containment easier.
WTF are you talking about?
I have a sparc solaris 8 server (set up by Sun people) and it has/lib linked to/usr/lib and/bin linked to/usr/bin.
I also have tens of linux computers with several distributions and none of them have those directories linked.
This is the sort of stuff Schwartz is talking about when he mentions military-grade security.
You do not know what you are talking about. Military grade security is support for mandatory access control and other features that may grant the system a B1 or higher rating by the US government.
AFAIK, the only Solaris version that claims to have military grade security is Trusted Solaris 8, and I do not know if those features are being open sourced.
I don't even know if it is even certified as B1 or higher.
SELinux (developed by the NSA) includes extensions for supporting MAC and other military grade security features.
Military grade security has nothing to do with having a stripped down version of/bin/sh.
Linux has stressed usability over this sort of security (which I don't mind), and, interestingly enough, linking sh to ksh and linking/lib to/usr/lib makes Solaris more Linux-ish. Also, many hardcore Solaris admins would regard it as a security hole and, if you're running the servers for the NSA or Wall Street, it probably is.
Linux distributions don't usually link/lib to/usr/lib. Solaris does.
GCJ and Kaffe are not implementations of Java since what they implement is only a subset and has not passed compatibility tests.
OK, but nothing prevents them from distributing it, right? so what is the problem?. I understand the goal of these projects (at least, GCJ) is to provide a complete Java environment. GCJ, in fact, only misses certain parts of the standard library, but the support for all the language features is pretty complete (of course, 1.4 language features, I hope they never implement the atrocity that is Java 2/5/1.5 but that's a different discussion).
The Java platform cannot be legally reimplemented without meeting Sun's compatibility requirements and without obtaining licenses for several of Sun's patents
Obtaining the license is no problem.
From the Java language specification:
Sun Microsystems, Inc. (SUN) hereby grants you a fully-paid, nonexclusive, nontransferable, perpetual, worldwide limited license (without the right to sublicense) under SUN's intellectual property rights that are essential to practice this specification. This license allows and is limited to the creation and distribution of clean room implementations of this specification.
Your implementation has to pass the compatibility tests, though.
There are several clean room implementations of Java (GCJ, Kaffe, TowerJ, Jeode and others I forget). I don't know which ones paid Sun though.
I think you have to pay if you want to use the trademark name Java.
"You are mistaken. The electoral council in Venezuela didn't allow the counting of the paper trail. In fact, there was at least a voting site where the operators (called table members in Venezuela) were arrested by the military just for opening the boxes with the votes in order to count them."
Could you provide a reputable source supporting this, ideally not one of the hatchet jobs like Thor Halversson's for the opposition. The odds are pretty slim of Chavez losing an election.
This is a well known fact. What we call in Venzuela "un hecho público y notorio" (a notorious, public fact).
Nobody will deny this.
I'd agreee evoting should be done away with in general but if you are going to keep it you have to have a paper trail and do truly random audits.
Then we agree. The problem with "truly random audits" is: who can guarantee they are truly random?, especially if electoral authorities are biased.
But the damning thing about evoting is there HAS TO BE A PAPER TRAIL. There is an interesting case study in Venezuela which recently had an election involving Hugo Chavez, who is reviled by the Bush administration, and was under constant accusation of trying to rig elections. They used all or mostly evoting machines, BUT they all had printers and a paper trail. The opposition tried to levy charges of election rigging but they simply didn't stick.
You are mistaken. The electoral council in Venezuela didn't allow the counting of the paper trail. In fact, there was at least a voting site where the operators (called table members in Venezuela) were arrested by the military just for opening the boxes with the votes in order to count them.
The only ballots ones that were officially counted were selected by the government controlled electoral council using a suppossedly random number generator program controlled by the electoral council themselves.
Besides, what's the point of E-voting?
It doesn't speed up the voting process. In fact, it can slow it down significantly, as was demonstrated in the venezuelan referendum, where the average time in queue for a simple Yes/No vote was about 8 hours (by far, the longest ever in a venezuelan election).
E-voting can only speed up the counting of the votes, but at the cost of not giving a serious guarantee of the transparency of the process.
The only way to prevent rigged elections is the public counting of the votes immediately after the voting process is finished. Period. Anything else is an act of faith by the voters.
And no, a machine automatically "counting" the votes is not a public counting even if the machine is not phisically hidden, no matter what the venezuelan electoral counting chief says.
Another serious flaw was pointed out by Jimmy Carter on Larry King last night (you can revile him all you want but he does know good and bad electoral process). The U.S. and assorted other international election monitors push hard for elections to be run by impartial, nonpartisan officials
It's curious. Jimmy Carter didn't complain that the venezuelan electoral council was completely biased towards the government. And he didn't complain about the council forbidding the manual counting of the ballots. But he said "Let's count every single vote in Florida when his party was declared loser there".
I thought python was interpreted. In fact I have never used it. As you say I should have checked first. My bad. I know also Jython, which compiles to the JVM.
Mr Eastman and Mr Kodak would have been proud There was no Mr. Kodak. Only Mr. Eastman. Kodak is a made up name for use as a trademark on one of their camera products. The name was so successful, they added the word to the company name.
Who speaks for Free/Open software (like Perl, Python and any other bytecode language)?
AFAIK, Perl and Python are not VM based languages. They are interpreted, but not compiled into bytecode for a specific VM. I don't know, however, if the patent applies to interpreted languages too. If it does, it may even apply to language, because compiled languages are interpreted by a Real Machine.
Maybe the point is that it makes it easier for old code to run within the new JVM? Many applications (especially complex ones like application servers, Corba orbs and even IDEs) usually don't run in newer releases of the JRE. They always require small changes because the libraries and other things change. I remember clearly a version of weblogic that ran on jre 1.3.x did not run on 1.4.x. Was that a big problem? No. You ran it with the old version. BEA shortly released a version that did run on 1.4. It is that simple. Nothing prevents anyone from having multiple JVMs in the machine. In fact this happens all the time. For example, some IntelliJ IDEA versions only run within the JRE bundled with them. I do not see why they couldn't make generics right and at the same time provide support for previous releases. The compatibility didn't even need to be perfect, because it has never been.
Where I can't see eye to eye with you is on the for loop comparison. Would you at least agree that C#'s syntax
foreach(int i in myList) {.... }
I agree it is easier to understand than Java's construct. And I agree it is not as flawed as Java's generics/autoboxing because it does not introduce counter-intuitive behavior or side effects. What I don't like about the Java version is that, to be used with an arbitrary class, it requires the class to implement certain specific interfaces. The language is supposed to be independent from the standard class library (except, perhaps for the special class Object). To tie the language definition to a specific interface is wrong, IMHO. But I will admit that if generics were done right and autoboxing were removed from the language, I would not have problems with the new "for". I would simply not use it. I would still consider Java a great language because its core wouldn't be flawed.
Regarding me being a fan of Microsoft products, I will admit that I quite like C#, and am really looking forward to.NET 2 which will address a lot of major shortcomings. As much as I hate MS, I admit C# is a good language. In fact is very similar to the old Java. C# 2.0 will be a lot better than Java, since it will not be as crippled as the new Java is. But I don't like.Net. It is very unfortunate that C# is too tied to.Net, since the next version will be an excellent language (with some features that I don't like, but not flawed like Java is now). I am very upset that my favorite language, which had things that I did't like but that wasn't flawed conceptually, is now a broken language. Yes, the new features will work in most cases, but there is a non-trivial minority of cases where the flaws will strike and make the life hard for everyone.
Implementing generics the 'Right Way' would have required making the JVM incompatible with any previous versions. Java lives on its ability for the programs written for it to always work, no matte the platform, and getting rid of that was not an option, period. If they did it the 'Right Way' then nobody would really want to switch to the new VM and compiler. Thus, they went with the 'Wrong Way'.
This is the reason. But it is not a very valid one. The standard library changes from version to version and it is typical that complex applications like applications servers and IDEs (and some simple apps too) do not work in newer releases. And of course, new code doesn't work in previous JVMs.
Not yet, but when someone at Sun gets the Bright Idea(tm) of rewriting the class libs to use all the new syntactic sugar, you will have no choice but to Submit or Die(sm).
Guess what. A large part of the library is using the poison, er... sugar.
Did people start complaining about C being shit when C++ was introduced? No, they just continued to use C instead. Or use C++ ignoring the features they didn't like.
First of all, C++ is not the newer version of C. It is a different language.
Second, the problem is not that you do not have tu use feature you do not like. The problem is that if those features are broken then the language is broken and this is the case with Java.
Generics haven't been implemented in the best possible way (thus hurting performance and giving the reflection anomaly), but they are nevertheless much better than no generics, and provide much more than 'syntactic sugar', rather provide compiler-time type checking where none was before, and make the code significantly more descriptive. Anyone with experience using C++ who has had to use Java knows that they were sorely needed, and now they're finally here and I for one am not complaining.
I am complaining because there is no valid reason not to have a decent generics implementation in Java. Backwards compatibility? new compiled code won't run on previous JVM versions, so that wasn't a valid argument.
Sorry, but when you make this claim you lose _all_ credibility in my eyes. How can
int total = 0; for(int i: mySet) {
total += i; }
be harder to read than
for(Iterator it = set.iterator(); it.hasNext();)
Integer integer = (Integer) it.next();
int i = integer.toInt();
total += i; }
Well maybe it is just me, but I think the first one is much harder to understand. There is no doubt about what the second does. Of course, the second was harder to write, but not harder to understand. Note that all examples people provide about how great generics and autoboxing are simply prove my point. Generics should have supported primitive types. If they had done this autoboxing would not be needed. Autoboxing will be primarily used for putting primitives into collections. The cosequences are: 1) Performance suffers, because a List of integers will not be as efficient as a list of int's. If you want efficient libraries for primitives you have to write them in a non-generic way.
2) While autoboxing problems will not hit you if you only use it to add them to the inefficient Object based collections, it introduces a mechanism that has all sorts of counterintuitive behavior if used for other purposes (comparisons with greater than, less than and == being just a small example).
Your problem is that you think I am against the idea of generics. Of course I'm not. But I AM against the idea of a broken implementation of generics that has a broken implementation of a counter-intuitive mechanism for pretending that they support primitives.
Just because _you_ don't see the point of something doesn't mean anything in my book sorry. A lot of people much cleverer than you _do_ see a point to them. Personally, I tend to be rather sceptical of such things, but having used attributes in C# can see how they bring real value in certain situations (such as when fields in a class map to a DB or XML, and attributes can be used to describe this mapping in cases where for example the field names differ).
I do not see justification for introducing extreme complexity in a language (as annotations do) for justifying a simple application such as XML or OR mapping. I think that could be handled with tools like XDoclet, which I do not like, but since it is not part of the language, I have no problem with other people using it for their applications. Anyway, I doubt many of the people who promote annotations are more clever than many people who oppose them (myself included). Such applications could perhaps should probably use configuration files.
Regarding enums, the point you raise is cause for some concern, but again they are something badly needed and having them, even if slightly flawed, is on balance better than having none and having individual coders make their own far poorer implementations of the concept when they need enums themselves.
I think enums were needed. But, as with generics, why couldn't they make a simple, good implementation as many other languages do. No. They came up with something that is fundamentally broken. Yeah, it works in most cases, but the flaws are there and have the potential of hitting any appli
As far as experience tells me, short code is almost always more readable than long code (except for abusive use of regexps and such stuff). Java 1.5 new features are great because they make your code shorter, hence more clear.
Dismissing something as syntactic sugar is just silly. Java generics may be not perfect, but they make code shorter, therefore clearer.
it is not that they are not perfect. They are completely broken. I am not against adding generics to Java. But, I prefer Java without generics than with the crappy implementation they came up with. If they had implemented generics properly I would not be complaining. I would be very happy instead. First of all, they should have supported primitives in generics. This could have eliminated the need for autoboxing. They instead went for a crappy implementation of generics and then another crappy workaround (autoboxing) for not having made a good generics implementation. And you are wrong saying that language constructs that are shorter are automatically clearer. By that logic, Perl would be one of the clearest languages of all.
Maybe you enjoy having to manually cast each time you use a container like ArrayList, or to manually write your own class ListOfT each time you want to use a list of elements of T type. I dont. Generics make my life easier, Im glad they included them.
You belive they make your life easier. When you have to deal with the errors of the implementation you are going to see how easier it is.
I fail to see how autoboxing can make your code any significally harder to read. Its like saying method overloading should be banned because it makes code harder to read as it makes it impossible to determine what a method does only by its name.
I am not a big fan of method overloading, but I certainly would have prefered method overloading instead of the pile of broken crap they came up with. As to how clear Autoboxing is, please explain the clarity of this:
Integer a = 2; Integer b = 2; boolean flag; flag = a>=b;//true flag = a<=b;//true flag = a==b;//false
I fail to see how that is clear. Why is it clear that == should not be used for comparing objects, but >= and In general, no one is forcing you to use any of this new features. If you find people using them, it is probably because they are USEFUL.
If I find people using them it will be because: a) they are ignorant and don't understand how broken Java generics and autoboxing is. b) They have no choice because they have invested a lot in Java and now the standard library is rewritten using templates as will several other tools too (probably for one of the two reasons).
I hate the fact that some people refuse to accept something can makes code clear if it doesnt stick to their own dogmas on programming styles.
I hate the fact that some ignorant people just fail to see how broken something is and criticize knowledgable people (and I am not talking about me, but many experts whose opinion I share) because they point out the flaws of something they believe is good.
>> Java generics don't provide any performance benefit
On the contrary, they provide the ability to write code faster, to understand code faster and to maintain code more easily, leading to fewer bugs, and thus less testing, and thus faster deployment. That's a hell of a cost saving - more than enough to buy a slightly faster CPU, if you're really concerned about runtime performance.
Yeah. Just use crappy algorithms because they are faster to program. You can buy a faster CPU to make bubblesort faster.
Anyway you seem to be talking about the benefits of generics in general.
I agree that generics (when implemented properly) are great. But Java's implementation is simply broken. C++ generics are correctly implemented. C# generics will be correctly implemented. Working with generics is or will be great in those languages. Java generics are broken. The type parameter information is nor really part of the code generated by the compiler. For example, you cannot construct a List using reflection because that type does not exist. When you have to interact with other code you'll suffer the consequences of this bad design.
>> Autoboxing: this feature removes clarity from the language.
I must have misunderstood this one. I thought it was simple auto-translation from primitives to their object equivalents (e.g. Integer to int and vice versa). Personally I have no clarity issues with
List listOfNumbers = new List(); listOfNumbers.add(5); System.out.println ("Number added = " + listOfNumbers.get(0));
Sure, that's a shite example, but it's late at night. There's autoboxing going on in that add(5) call; I don't think it's hurt clarity at all.
What about this one?
Integer i = new Integer(2); Integer j = new Integer(2); assertTrue(i >= j);// success assertTrue(i = and myList and then call myList.add(5) wihtout mysterious things going on behind the scenes. Almost all uses of autoboxing will be for dealing with primitives in container classes. Something completely unnecessary with a good Generics implementation.
>> Enums
That's certainly a potential issue when dealing with object references using an Enum pattern; I haven't tried that scenario in 1.5 so not whether that'll be a problem. Of course, if you rely on.equals() instead of == (as you generally should for all class types) then I'd expect Enums loaded from different class loaders to still be.equals() equal and thus your problem wont arise. Good spot though, I'll have a play and experiment with that one.
In case you don't know, equals() fails with classes loaded in different classloaders. The real fully qualified name of a class in Java includes the ClassLoader as a prefix. So equals will fail. The reason for this is that class with the same name but in different classloaders are potentially different versions. That is why you can have J2EE applications that use different versions of the same library in the same application server. The only way to make equals() work is using reflection and comparing the names of the clases. I understand that with Java 2 version 5 version 1.5 enums equals() will fail with different classloaders. I haven't tested it, though.
>> Annotations: I really don't see the point of this.
It's an exceedingly powerful addition to the language, albeit one I'm far from certain I'm happy about.
At least you have your doubts about the value of this atrocity. This feature adds inmense complexity to the language and will benefit only a handful of projects which have existed anyway without such support IN the language specification.
>> New for: This simply makes the code harder to read.
I'm going to challenge that. Yes, maybe harder for read the first time(s) you come across it, but after that, every bit as simple as the curre
No one said you must use these new features.
I will try as hard as I can to avoid them. But look at the new documentation for the class library. It's rewritten using generics. In the future it will be very hard to avoid these new features. The class library uses them. Third party libraries will start to use them.
How can you program in Java without using the standard library?
Java was a good, simple language. You may not have liked it, but you couldn't deny it was a simple language with an elegant C-style syntax.
Now they added a lot of features that are nothing but crappy compiler sugar. Most of them badly implemented.
Generics: They couldn't make it worse here. You cannot use reflection effectively because the type parameter information is not stored in the compiled class file. There are many ways to circumvent the type "safety" provided by the templates, especially if you are mixing code from older versions. This is one of the worse implementations of generics I have seen. I hate Microsoft with a vengeance, but they are implementing generics in a sensible way in the next version of C#. See this for an interesting discussion comparing Java, C# and C++ generics.
With java generics you can compile this:
class MyClass<T> { T[] anArrayOfT() { Object[] arr = new Object[10]; //add whatever you want to arr. return (T[]) arr; } }
Of course, you cannot assign the return value to a T[] because it is really an Object[], so, where is the type safety?
All this is without mentioning that Java generics don't provide any performance benefit (which you would naively expect because you believe that you do not have to cast anymore).
Java generics are just compiler sugar for automatically generating casts.
Autoboxing: this feature removes clarity from the language. You do not know what is really going on. And you never know when you are going to be surprised.
Enums: They coud have made a very good typesafe implementation using internal integer values orsomething simple like that. Instead they make them as clases. At first they look like they work fine, but if you start workking in contexts where several classloaders are used (e.g. application servers) then the enum is going to be loaded in both classloaders and comparison of apparently equal values will fail.
Annotations: I really don't see the point of this. It's just more complexity. It seems it is only useful to help some complicated and probably not very well desinged tools.
New for: This simply makes the code harder to read. The original, C like "for" construct was very clear and was very understandable both for arrays and collections. Now in order to use a fundamental construct (a "for") your code has to implement some new interfaces. This is pure crap.
Static imports and variable length parameter lists: I think these are well done. I have nothing against these.
It looks like they wanted to add novelty features, but in order to avoid make the appropriate JVM specification changes, they implemented everything as compiler sugar.
It just doesn't work.
Maybe the fact that Java is now managed by a comittee instead of a few people who do know about language/compiler design has something to do with this.
Maybe they are just trying to make it "easier"for those who don't know how to program. Again, it doesn't work.
Something more or less like this happened when C++ was standarized. They came up with an overly complicated monster language, but at least the specification was not a broken one, just complex.
They could have added pass of parameters by reference (at least for primitives), which would have been very useful in real world situations. But instead they decided to add a ton of crap.
Java is doomed now. Too bad it was my favorite language. Now I have to look for another language. Maybe D?
Yet Opera accounted for 2.5% of hits, and doesn't work with GMail. Pretty interesting stats, I'd say.
I have a friend who managed to use Gmail with opera 7.60b1 changing the identification of the browser to mozilla and activating cookies.
Summary: Two people in unhappy marriages are bored to tears in Tokoyo. We know they're lives are boring because the director bores us to tears watching them do nothing. The fall in love (but never consumate it) and are dreading going back to their normal lives. Suddenly at the last second, the guy wispers something (inaudible) to the girl and they both go magically smiley happy back to thier normal lives.
Man, you actually watched that crap until the end!
It's one of the most boring movies I have ever seen. You must be very strong to stay awake all that time.
I rented a pirated version of it (the usual way to rent current movies in my country) and after about 30 or 40 minutes I fell asleep.
Nevertheless, I don't complain about it. I only spent $1 to rent it and it helped me sleep earlier that day.
IIRC, this atrocity was nominated for the Oscars. I don't know what criteria they use these days....
Slashdot Mirror
sh and ksh are separate for a reason. Solaris sh (more so than other sh's) is *very* stripped down -- no tab completion, no command history, etc. -- so that there are no side effects. When you hit tab, you get a literal tab. That makes it harder for hackers to place little "easter eggs" and make "!!" expand to "rm -rf /". /lib and /usr/lib are separate for similar reasons. /lib holds system libraries, while /usr/lib holds user-installed libraries. It makes threat containment easier.
/lib linked to /usr/lib and /bin linked to /usr/bin.
/bin/sh.
/lib to /usr/lib makes Solaris more Linux-ish. Also, many hardcore Solaris admins would regard it as a security hole and, if you're running the servers for the NSA or Wall Street, it probably is.
/lib to /usr/lib. Solaris does.
WTF are you talking about? I have a sparc solaris 8 server (set up by Sun people) and it has
I also have tens of linux computers with several distributions and none of them have those directories linked.
This is the sort of stuff Schwartz is talking about when he mentions military-grade security.
You do not know what you are talking about.
Military grade security is support for mandatory access control and other features that may grant the system a B1 or higher rating by the US government.
AFAIK, the only Solaris version that claims to have military grade security is Trusted Solaris 8, and I do not know if those features are being open sourced.
I don't even know if it is even certified as B1 or higher.
SELinux (developed by the NSA) includes extensions for supporting MAC and other military grade security features.
Military grade security has nothing to do with having a stripped down version of
Linux has stressed usability over this sort of security (which I don't mind), and, interestingly enough, linking sh to ksh and linking
Linux distributions don't usually link
Didn't Street Fighter II Turbo (from Capcom) use the same code?
I remember using it to put the game in ultra fast mode (ten stars).
GCJ and Kaffe are not implementations of Java since what they implement is only a subset and has not passed compatibility tests.
OK, but nothing prevents them from distributing it, right? so what is the problem?. I understand the goal of these projects (at least, GCJ) is to provide a complete Java environment. GCJ, in fact, only misses certain parts of the standard library, but the support for all the language features is pretty complete (of course, 1.4 language features, I hope they never implement the atrocity that is Java 2/5/1.5 but that's a different discussion).
The Java platform cannot be legally reimplemented without meeting Sun's compatibility requirements and without obtaining licenses for several of Sun's patents
Obtaining the license is no problem.
From the Java language specification:
Sun Microsystems, Inc. (SUN) hereby grants you a fully-paid, nonexclusive, nontransferable, perpetual, worldwide limited license (without the right to sublicense) under SUN's intellectual property rights that are essential to practice this specification. This license allows and is limited to the creation and distribution of clean room implementations of this specification.
Your implementation has to pass the compatibility tests, though.
There are several clean room implementations of Java (GCJ, Kaffe, TowerJ, Jeode and others I forget). I don't know which ones paid Sun though.
I think you have to pay if you want to use the trademark name Java.
"You are mistaken. The electoral council in Venezuela didn't allow the counting of the paper trail. In fact, there was at least a voting site where the operators (called table members in Venezuela) were arrested by the military just for opening the boxes with the votes in order to count them." Could you provide a reputable source supporting this, ideally not one of the hatchet jobs like Thor Halversson's for the opposition. The odds are pretty slim of Chavez losing an election.
This is a well known fact. What we call in Venzuela "un hecho público y notorio" (a notorious, public fact).
Nobody will deny this.
I'd agreee evoting should be done away with in general but if you are going to keep it you have to have a paper trail and do truly random audits.
Then we agree. The problem with "truly random audits" is: who can guarantee they are truly random?, especially if electoral authorities are biased.
But the damning thing about evoting is there HAS TO BE A PAPER TRAIL. There is an interesting case study in Venezuela which recently had an election involving Hugo Chavez, who is reviled by the Bush administration, and was under constant accusation of trying to rig elections. They used all or mostly evoting machines, BUT they all had printers and a paper trail. The opposition tried to levy charges of election rigging but they simply didn't stick.
You are mistaken. The electoral council in Venezuela didn't allow the counting of the paper trail. In fact, there was at least a voting site where the operators (called table members in Venezuela) were arrested by the military just for opening the boxes with the votes in order to count them.
The only ballots ones that were officially counted were selected by the government controlled electoral council using a suppossedly random number generator program controlled by the electoral council themselves.
Besides, what's the point of E-voting? It doesn't speed up the voting process. In fact, it can slow it down significantly, as was demonstrated in the venezuelan referendum, where the average time in queue for a simple Yes/No vote was about 8 hours (by far, the longest ever in a venezuelan election).
E-voting can only speed up the counting of the votes, but at the cost of not giving a serious guarantee of the transparency of the process.
The only way to prevent rigged elections is the public counting of the votes immediately after the voting process is finished. Period. Anything else is an act of faith by the voters. And no, a machine automatically "counting" the votes is not a public counting even if the machine is not phisically hidden, no matter what the venezuelan electoral counting chief says.
Another serious flaw was pointed out by Jimmy Carter on Larry King last night (you can revile him all you want but he does know good and bad electoral process). The U.S. and assorted other international election monitors push hard for elections to be run by impartial, nonpartisan officials
It's curious. Jimmy Carter didn't complain that the venezuelan electoral council was completely biased towards the government. And he didn't complain about the council forbidding the manual counting of the ballots. But he said "Let's count every single vote in Florida when his party was declared loser there".
Once I heard a very knowledgeable person say something like:
"Standards are like toothbrushes.... Everybody has one and nobody wants to use any of the others' "
The Venezuelan National Electoral Council is the champion in this category.
No
I thought python was interpreted. In fact I have never used it. As you say I should have checked first. My bad.
I know also Jython, which compiles to the JVM.
Mr Eastman and Mr Kodak would have been proud
There was no Mr. Kodak. Only Mr. Eastman.
Kodak is a made up name for use as a trademark on one of their camera products. The name was so successful, they added the word to the company name.
Who speaks for Free/Open software (like Perl, Python and any other bytecode language)?
AFAIK, Perl and Python are not VM based languages. They are interpreted, but not compiled into bytecode for a specific VM. I don't know, however, if the patent applies to interpreted languages too. If it does, it may even apply to language, because compiled languages are interpreted by a Real Machine.
There was a version of Pascal called UCSD Pascal, which was VM based.
Maybe the point is that it makes it easier for old code to run within the new JVM?
....
.NET 2 which will address a lot of major shortcomings. .Net. It is very unfortunate that C# is too tied to .Net, since the next version will be an excellent language (with some features that I don't like, but not flawed like Java is now).
Many applications (especially complex ones like application servers, Corba orbs and even IDEs) usually don't run in newer releases of the JRE. They always require small changes because the libraries and other things change.
I remember clearly a version of weblogic that ran on jre 1.3.x did not run on 1.4.x. Was that a big problem? No. You ran it with the old version.
BEA shortly released a version that did run on 1.4. It is that simple. Nothing prevents anyone from having multiple JVMs in the machine. In fact this happens all the time.
For example, some IntelliJ IDEA versions only run within the JRE bundled with them.
I do not see why they couldn't make generics right and at the same time provide support for previous releases. The compatibility didn't even need to be perfect, because it has never been.
Where I can't see eye to eye with you is on the for loop comparison. Would you at least agree that C#'s syntax
foreach(int i in myList) {
}
I agree it is easier to understand than Java's construct.
And I agree it is not as flawed as Java's generics/autoboxing because it does not introduce counter-intuitive behavior or side effects.
What I don't like about the Java version is that, to be used with an arbitrary class, it requires the class to implement certain specific interfaces.
The language is supposed to be independent from the standard class library (except, perhaps for the special class Object). To tie the language definition to a specific interface is wrong, IMHO.
But I will admit that if generics were done right and autoboxing were removed from the language, I would not have problems with the new "for". I would simply not use it. I would still consider Java a great language because its core wouldn't be flawed.
Regarding me being a fan of Microsoft products, I will admit that I quite like C#, and am really looking forward to
As much as I hate MS, I admit C# is a good language. In fact is very similar to the old Java. C# 2.0 will be a lot better than Java, since it will not be as crippled as the new Java is.
But I don't like
I am very upset that my favorite language, which had things that I did't like but that wasn't flawed conceptually, is now a broken language.
Yes, the new features will work in most cases, but there is a non-trivial minority of cases where the flaws will strike and make the life hard for everyone.
Implementing generics the 'Right Way' would have required making the JVM incompatible with any previous versions. Java lives on its ability for the programs written for it to always work, no matte the platform, and getting rid of that was not an option, period. If they did it the 'Right Way' then nobody would really want to switch to the new VM and compiler. Thus, they went with the 'Wrong Way'.
This is the reason. But it is not a very valid one. The standard library changes from version to version and it is typical that complex applications like applications servers and IDEs (and some simple apps too) do not work in newer releases.
And of course, new code doesn't work in previous JVMs.
Not yet, but when someone at Sun gets the Bright Idea(tm) of rewriting the class libs to use all the new syntactic sugar, you will have no choice but to Submit or Die(sm).
Guess what. A large part of the library is using the poison, er... sugar.
Did people start complaining about C being shit when C++ was introduced? No, they just continued to use C instead. Or use C++ ignoring the features they didn't like. First of all, C++ is not the newer version of C. It is a different language.
Second, the problem is not that you do not have tu use feature you do not like. The problem is that if those features are broken then the language is broken and this is the case with Java.
Generics haven't been implemented in the best possible way (thus hurting performance and giving the reflection anomaly), but they are nevertheless much better than no generics, and provide much more than 'syntactic sugar', rather provide compiler-time type checking where none was before, and make the code significantly more descriptive. Anyone with experience using C++ who has had to use Java knows that they were sorely needed, and now they're finally here and I for one am not complaining.
I am complaining because there is no valid reason not to have a decent generics implementation in Java. Backwards compatibility? new compiled code won't run on previous JVM versions, so that wasn't a valid argument.
Sorry, but when you make this claim you lose _all_ credibility in my eyes. How can
int total = 0;
for(int i: mySet) {
total += i;
}
be harder to read than
for(Iterator it = set.iterator(); it.hasNext();)
Integer integer = (Integer) it.next();
int i = integer.toInt();
total += i;
}
Well maybe it is just me, but I think the first one is much harder to understand.
There is no doubt about what the second does.
Of course, the second was harder to write, but not harder to understand.
Note that all examples people provide about how great generics and autoboxing are simply prove my point.
Generics should have supported primitive types. If they had done this autoboxing would not be needed.
Autoboxing will be primarily used for putting primitives into collections. The cosequences are:
1) Performance suffers, because a List of integers will not be as efficient as a list of int's.
If you want efficient libraries for primitives you have to write them in a non-generic way.
2) While autoboxing problems will not hit you if you only use it to add them to the inefficient Object based collections, it introduces a mechanism that has all sorts of counterintuitive behavior if used for other purposes (comparisons with greater than, less than and == being just a small example).
Your problem is that you think I am against the idea of generics. Of course I'm not. But I AM against the idea of a broken implementation of generics that has a broken implementation of a counter-intuitive mechanism for pretending that they support primitives.
Just because _you_ don't see the point of something doesn't mean anything in my book sorry. A lot of people much cleverer than you _do_ see a point to them. Personally, I tend to be rather sceptical of such things, but having used attributes in C# can see how they bring real value in certain situations (such as when fields in a class map to a DB or XML, and attributes can be used to describe this mapping in cases where for example the field names differ).
I do not see justification for introducing extreme complexity in a language (as annotations do) for justifying a simple application such as XML or OR mapping.
I think that could be handled with tools like XDoclet, which I do not like, but since it is not part of the language, I have no problem with other people using it for their applications.
Anyway, I doubt many of the people who promote annotations are more clever than many people who oppose them (myself included).
Such applications could perhaps should probably use configuration files.
Regarding enums, the point you raise is cause for some concern, but again they are something badly needed and having them, even if slightly flawed, is on balance better than having none and having individual coders make their own far poorer implementations of the concept when they need enums themselves.
I think enums were needed. But, as with generics, why couldn't they make a simple, good implementation as many other languages do.
No. They came up with something that is fundamentally broken. Yeah, it works in most cases, but the flaws are there and have the potential of hitting any appli
Dismissing something as syntactic sugar is just silly. Java generics may be not perfect, but they make code shorter, therefore clearer.
it is not that they are not perfect. They are completely broken. I am not against adding generics to Java. But, I prefer Java without generics than with the crappy implementation they came up with.
If they had implemented generics properly I would not be complaining. I would be very happy instead.
First of all, they should have supported primitives in generics. This could have eliminated the need for autoboxing.
They instead went for a crappy implementation of generics and then another crappy workaround (autoboxing) for not having made a good generics implementation.
And you are wrong saying that language constructs that are shorter are automatically clearer.
By that logic, Perl would be one of the clearest languages of all.
Maybe you enjoy having to manually cast each time you use a container like ArrayList, or to manually write your own class ListOfT each time you want to use a list of elements of T type. I dont. Generics make my life easier, Im glad they included them.
You belive they make your life easier.
When you have to deal with the errors of the implementation you are going to see how easier it is.
I fail to see how autoboxing can make your code any significally harder to read. Its like saying method overloading should be banned because it makes code harder to read as it makes it impossible to determine what a method does only by its name.
I am not a big fan of method overloading, but I certainly would have prefered method overloading instead of the pile of broken crap they came up with.
As to how clear Autoboxing is, please explain the clarity of this:I fail to see how that is clear. Why is it clear that == should not be used for comparing objects, but >= and
In general, no one is forcing you to use any of this new features. If you find people using them, it is probably because they are USEFUL.
If I find people using them it will be because:
a) they are ignorant and don't understand how broken Java generics and autoboxing is.
b) They have no choice because they have invested a lot in Java and now the standard library is rewritten using templates as will several other tools too (probably for one of the two reasons).
I hate the fact that some people refuse to accept something can makes code clear if it doesnt stick to their own dogmas on programming styles.
I hate the fact that some ignorant people just fail to see how broken something is and criticize knowledgable people (and I am not talking about me, but many experts whose opinion I share) because they point out the flaws of something they believe is good.
>> Java generics don't provide any performance benefit
On the contrary, they provide the ability to write code faster, to understand code faster and to maintain code more easily, leading to fewer bugs, and thus less testing, and thus faster deployment.
That's a hell of a cost saving - more than enough to buy a slightly faster CPU, if you're really concerned about runtime performance.
Yeah. Just use crappy algorithms because they are faster to program. You can buy a faster CPU to make bubblesort faster.
Anyway you seem to be talking about the benefits of generics in general.
I agree that generics (when implemented properly) are great. But Java's implementation is simply broken. C++ generics are correctly implemented. C# generics will be correctly implemented. Working with generics is or will be great in those languages. Java generics are broken. The type parameter information is nor really part of the code generated by the compiler. For example, you cannot construct a List using reflection because that type does not exist. When you have to interact with other code you'll suffer the consequences of this bad design.
>> Autoboxing: this feature removes clarity from the language.
I must have misunderstood this one. I thought it was simple auto-translation from primitives to their object equivalents (e.g. Integer to int and vice versa). Personally I have no clarity issues with
List listOfNumbers = new List();
listOfNumbers.add(5);
System.out.println ("Number added = " + listOfNumbers.get(0));
Sure, that's a shite example, but it's late at night. There's autoboxing going on in that add(5) call; I don't think it's hurt clarity at all.
What about this one?
Integer i = new Integer(2);
Integer j = new Integer(2);
assertTrue(i >= j);
assertTrue(i = and myList and then call myList.add(5) wihtout mysterious things going on behind the scenes.
Almost all uses of autoboxing will be for dealing with primitives in container classes.
Something completely unnecessary with a good Generics implementation.
>> Enums
That's certainly a potential issue when dealing with object references using an Enum pattern; I haven't tried that scenario in 1.5 so not whether that'll be a problem. Of course, if you rely on
In case you don't know, equals() fails with classes loaded in different classloaders. The real fully qualified name of a class in Java includes the ClassLoader as a prefix. So equals will fail.
The reason for this is that class with the same name but in different classloaders are potentially different versions.
That is why you can have J2EE applications that use different versions of the same library in the same application server.
The only way to make equals() work is using reflection and comparing the names of the clases.
I understand that with Java 2 version 5 version 1.5 enums equals() will fail with different classloaders. I haven't tested it, though.
>> Annotations: I really don't see the point of this.
It's an exceedingly powerful addition to the language, albeit one I'm far from certain I'm happy about.
At least you have your doubts about the value of this atrocity.
This feature adds inmense complexity to the language and will benefit only a handful of projects which have existed anyway without such support IN the language specification.
>> New for: This simply makes the code harder to read.
I'm going to challenge that. Yes, maybe harder for read the first time(s) you come across it, but after that, every bit as simple as the curre
No one said you must use these new features.
I will try as hard as I can to avoid them. But look at the new documentation for the class library. It's rewritten using generics. In the future it will be very hard to avoid these new features. The class library uses them. Third party libraries will start to use them. How can you program in Java without using the standard library?
Now they added a lot of features that are nothing but crappy compiler sugar. Most of them badly implemented.
With java generics you can compile this:Of course, you cannot assign the return value to a T[] because it is really an Object[], so, where is the type safety? All this is without mentioning that Java generics don't provide any performance benefit (which you would naively expect because you believe that you do not have to cast anymore).
Java generics are just compiler sugar for automatically generating casts.
Maybe the fact that Java is now managed by a comittee instead of a few people who do know about language/compiler design has something to do with this.
Maybe they are just trying to make it "easier"for those who don't know how to program. Again, it doesn't work.
Something more or less like this happened when C++ was standarized. They came up with an overly complicated monster language, but at least the specification was not a broken one, just complex.
They could have added pass of parameters by reference (at least for primitives), which would have been very useful in real world situations. But instead they decided to add a ton of crap.
Java is doomed now. Too bad it was my favorite language. Now I have to look for another language. Maybe D?
Yet Opera accounted for 2.5% of hits, and doesn't work with GMail. Pretty interesting stats, I'd say.
I have a friend who managed to use Gmail with opera 7.60b1 changing the identification of the browser to mozilla and activating cookies.
Summary: Two people in unhappy marriages are bored to tears in Tokoyo. We know they're lives are boring because the director bores us to tears watching them do nothing. The fall in love (but never consumate it) and are dreading going back to their normal lives. Suddenly at the last second, the guy wispers something (inaudible) to the girl and they both go magically smiley happy back to thier normal lives.
Man, you actually watched that crap until the end!
It's one of the most boring movies I have ever seen.
You must be very strong to stay awake all that time.
I rented a pirated version of it (the usual way to rent current movies in my country) and after about 30 or 40 minutes I fell asleep.
Nevertheless, I don't complain about it. I only spent $1 to rent it and it helped me sleep earlier that day.
IIRC, this atrocity was nominated for the Oscars. I don't know what criteria they use these days....
Equality is commutative. (A = B) (B=A). This is nonsense.
Except in asymptotical notations (Big-O, Big-Theta, Big-Omega).
n^2+n=O(n^2)
n^2+1=O(n^2)
But not viceversa.
Otherwise you could say br n^2+n=n^2+1