You didn't exactly give any good reasons in your post, as well as your post seems to be trolling for the pro-microsoft idiots to bite, and the the pro-linux idiots to bite back.
It seems to me that the reasons for doing such a thing are glaringly self-evident. As far as pro-Microsoft vs. pro-Linux, this article is addressing a central issue of interest to both camps. And gee, I thought Slashdot was a forum for discussion and opinion... I presume those who aren't interested in such topics wouldn't read the article or comments.
Yup, it seems as if you are trolling, as you have added nothing to the discussion.
Did someone else advocate the US government boycott Microsoft software? If so, the mark should have been "redundant". If not, then I did add something to the discussion, no?
Although, perhaps you are on the boader of flamebait and trolling.
I'd have voted flamebait,
or just linux moron...
Perhaps Slashdot needs an "Opinionated" mod, which could either be a +1 or -1 depending on which way the moderator felt it should go...;-)
299,792,458 m/s...not just a good idea, its the law!
should immediately be banned for use by US government entities.
On thinking about this a bit more, it seems an immediate ban would cause quite a bit of chaos (possibly not more than the government deserves, however).
A more realistic approach would be a planned transition where a minimal amount of Microsoft software (bundled on new computers) was purchased, and the government must transition to a non-Microsoft platform within, say, three years.
Seems eminently reasonable to me. And talk about an economic stimulus package...:-)
299,792,458 m/s...not just a good idea, its the law!
OK, whoever just modded the parent post a troll was a moron. Please reply and try to defend your position (which you just implicitly took) that my idea is tacitly unreasonable.
Why should the government give billions of dollars a year to a known monopolist (who is singularly unrecalcitrant), thereby further entrenching the monopolist and discouraging competitors?
That is the untenable position, in my view.
299,792,458 m/s...not just a good idea, its the law!
Yes, the athlon has shadow registers, but that doesn't obviate the need for more physical registers.. The shadow registers are used to enable superscalar execution..
Yes, the Athlon extracts parallelism from the incoming instruction stream.
The point is simply that there is more than one way to skin a cat. No one ever would have thought that x86 would scale so well or be so competitive with RISC. (Alpha was/is great, and I'll never understand why DEC/Compaq dropped the ball so badly there...)
when a program needs to deal with more variables then registers are available they still need to spill data onto the stack (into ram) which is AMAZINGLY slow.
Don't you mean L1 cache?
Your reference box, eh? Since you're breaking your NDA just to tell us you have one (I presume), why don't you enlighten us as to the clock speed on that puppy?;-)
Regardless, a 50-fold improvement in calculation speed is unlikely to be the result of additional registers... It would more likely be the SIMD type instructions, which use additional registers even in IA32.
299,792,458 m/s...not just a good idea, its the law!
Re:Compiled for 64 Bit...and Programmed for 64 Bit
on
If I Had a Hammer
·
· Score: 2
Applications need to be programmed and optimized to make use of the extra registers, extra info paths, extra instructions available on the new platform.
Obviously you're not aware of how the Athlon works, among other things.
Internally, it has many more registers than four. x86 instructions only reference four registers, but internally the Athlon uses it's full set to speed up the code, as well as exploiting several types of parallelism.
For higher level languages, it is even less of an issue. There may be some impact on my Java code as to whether "int" or "long" has faster operations, but I'll guarantee that all my code using "double" will fly. The best part is that I won't even have to recompile! =)
The other thing I'll gain is that all of my dynamic allocations will have much larger memory limits. The virtual memory limit per process for the first Linux port to Hammer is 511 GB.
299,792,458 m/s...not just a good idea, its the law!
Re:How was the test performed on linux
on
If I Had a Hammer
·
· Score: 2
(Seriously though, I hope they haven't left the extended paging bug in)
Since that bug is already fixed on current Athlons, I seriously doubt it'll be a problem with Hammer.
299,792,458 m/s...not just a good idea, its the law!
We trust the people enough to sell lethal firearms to anybody who walks in off of the street.
Yes, after a criminal background check and a waiting period in most states. In my state there is also a requirement for a firearms training certificate, obtained by taking a test.
I hope you don't need a new gun fast someday...
All that said, the idea of somehow building "copy protection" into computer hardware is moronic beyond words. Fools.
Once again, rather than addressing the real issue (commercial content is far more expensive than it should be), the media companies are circling the wagons and trying to protect their cash cow. It's not going to work. They dynamic of the PC is too powerful.
What _really_ needs to happen is for an aggressive, well funded Internet entrepreneur to set up a web site that
a) signs up hot new talent.
b) distributes music content online at reasonable
cost (say $0.50/song).
c) distributes music content on CD/DVD etc. at
reasonable cost (say $5/CD).
d) sets up radio stations to play digital content
straight off the internet onto the airwaves or the internet.
e) runs its own content on it's own internet radio stations.
e) has a very attractive package for the artists.
There should be plenty to go around, since this would be a very lean, mean operation compared to the media companies.
I guess this would really be more like an mp3.com done right...the trick would be to be quickly perceived as a better deal for the artists than the traditional record companies. Once the buzz got going, it would do great I think. It would take major capital up front for advertising etc. though.
299,792,458 m/s...not just a good idea, its the law!
nVidia is notoriously bad at this; their DirectX drivers are quite stable, but OpenGL blue screens left and right (especially with a lot of detail in the scene graph).
Total FUD. NVIDIA has been quite good about OpenGL support. I've played several of the first-person shooters (Quake, SoF etc.) using NVIDIA hardware and haven't had a single OpenGL related problem. Also, a person I have a lot of contact with at work uses SolidWorks (a nice 3D CAD package for Windows) which is exclusively OpenGL display with both consumer and professional level NVIDIA cards under Win2K. He hasn't had a single card-related crash, and he has some very complex models.
You should also read some of Carmack's recent.plan updates. If anyone knows how to stress an OpenGL implementation, it's him. A direct quote: 'Nvidia's OpenGL drivers are my "gold standard", and it has been quite a while since I have had to report a problem to them'. That is stellar praise from an ISV. Also you should give NVIDIA credit for it's great OpenGL support under Linux and MacOS X.
In short, if you're seeing blue screens using the NVIDIA OpenGL drivers, you very likely have a hardware problem. Otherwise, they are very good.
Now, with OpenGL 2.0, if they have to support three different API's, isn't driver quality going to suffer even more?
How so three different APIs? There will be OpenGL and Direct3D. What other one do you count?
Oh well, ATI has been getting a lot better recently, I guess we can always switch to them.:-)
Good luck...and do read Carmack's.plan carefully first.
299,792,458 m/s...not just a good idea, its the law!
I don't view Java as a religion - I view it as a technology, which, if adopted across the board, could drastically improve computing (particularly software development, and the quality of software in general). Java also encourages platform independence, and thus solid alternative platforms to Windows. C#/CLR aren't really an alternative, they are simply a (quite transparent) attempt to 'embrace and extend' Java into a component of the overall Microsoft Monopoly.
Therefore, yes, in my world view Java+JVM=GOOD, C#+CLR=BAD. It's really very simple.
You Java people are like a fucking internet death cult.
The true "Internet death cult" (as in "Death to the Internet!") is Microsoft with it's "Windows Everywhere" mentality. If Microsoft succeeds (and.Net is a cornerstone in this strategy), the Internet will become a giant hose spewing money into Microsoft's coffers. I'm sure that will be good for the computer industry! (he says sarcastically)
In my humble opinion, the only people who are pro-Microsoft to any degree at this point are fools or uninformed. Microsoft is anathema.
By the way, it's too bad you couldn't address any of the substantive points I made. Pretty weak.
299,792,458 m/s...not just a good idea, its the law!
OK.. I am a Java fan... (recently this has been changing though.)
Sorry to hear that, I hope I can persuade you a bit back towards the good side of the force...;-)
I have mixed feelings with JDK 1.4.
I'm mostly ecstatic about it. =)
The assert facility is OK.... i don't like the fact that they added an Assert keyword but I don't get to make the decisions.
I wish they had done a better job of support DBC, but it should still be useful. I'm not too sure what it bought over just using existing "assert" hacks, which can also be compiled completely out.
There is also some controversy.
Perhaps in the minds of some...
The Log4J people are upset because there is now a 'stanard' Java package for logging. IMO the 'standard' package is inferior to Log4J in many situations.
I'm not sure what the complaint is here. If Log4J is superior (I've not looked at the logging API yet), it should still attract lots of users. Regardless, there is no way for Sun to extend the core JDK without potentially stepping on the toes of some developers. I don't see an easy way around that problem.
The regexp package is not all it is cracked up to be either. I would recommend Jakarta ORO or Jakarta Regexp.
Again, I can't comment on the technical merits of one versus the other. However, again I'm not sure what your problem is. There are alternative packages, which are better. Great, then use them! The core packages are essentially developed by committee, and are only one approach to the given problem domain. There are many tradeoffs in library design...
As far as that... it runs GREAT on Linux. Probably the most SOLID VM I have ever run.
That sounds great! I'm just about to install it.
They did break some stuff with legacy code. If you ever named a class 'URI' your code will now fail to compile because they put this class in the java.net package which everyone imports anyway.
That is not "breaking something". That is the reason Java has namespaces. Not a big deal at all.
As far as C# vs.Java. I am really impressed with the CLR/CLI stuff.
I'm not sure why...care to clarify? Have you read the comments about CLR based languages all being different skins of C#?
I'm also not sure why people seem to feel it's impossible to interface Java to legacy languages. People do it all the time using JNI.
Right now, as it stands, Java is a proprietary language. Unless we see SUN Open Source Java (or push it through a standards committee), we *may* see a JDK 1.5... but no one will use it.
Sun has made noises about open sourcing Java at some point. If it'd just release the compatibility tests as open source, that would go a long way. (It is currently perfectly fine to 'clean room' Java, as gcj is doing. You just can't call it "Java" without essentially licensing Java and getting the compatibility tests.)
Regardless of Sun's timing in releasing Java as open source, you're completely out of your mind if you think interest in Java is going to significantly lessen because of the introduction of C#/CLR. C# and the CLR are both fledgling technologies, where Java is quite proven and robust. I just read about the first CLR security exploit, and I expect many, many more. Heard of any with JVMs lately?
C# and the CLR only run on small computers and operating systems compared with the high availability big iron that runs Java. Also, Java has penetrated small devices very effectively, with over 100 million Java enabled cell phones to ship this year, very significant embedded penetration, and instruction set support for Java bytecode in all the new generation of ARM chips such as Xscale. Microsoft is caught in the middle (granted the middle covers a lot of ground;).
Despite all the rhetoric to the contrary, I advise you to expect big things from Java on the desktop as well. Sun is quietly staying the course, and is making big improvements to client side Java with every release. Since Java supports Windows, MacOS and Linux, it is a very attractive way to deploy applications (we'll see when C# achieves this milestone;). Earlier releases coupled with slower computers were painful, but things have improved to the point where Java is perfectly usable for lots of applications. Linux + Java is a potential Microsoft killer, make no mistake about it and Microsoft knows it.
My final point for today regarding the "open" nature of C# and the CLR is that quite a lot of the C# class libraries available under MS Visual Studio are not included in the standard. This includes the GUI libraries, so as things stand you can use Java today to write completely cross-platform GUI based programs. It will most likely be a cold day in hell before Winforms are available anywhere but Windows. I'm betting Microsoft's legal team will make sure of it. We'll see if Mono gets far enough to be a test case.
Sigh, now the long wait begins for JDK 1.5.;-)
(Reptile looks cool, I'll check it out later.)
299,792,458 m/s...not just a good idea, its the law!
Phillips should sue unless these are clearly marked as something different from CDs. Phillips has already made it's position clear on this issue.
Content providers using copy-protection like this are fools. All they will do is drive their customers underground to find unencumbered content that the customers can use on whatever media/player they desire, as provided by fair use.
299,792,458 m/s...not just a good idea, its the law!
I've seen lots of posts claiming that "Java doesn't have operator overloading, so it doesn't qualify" (I'll ignore MI, since I think interfaces are a reasonable substitute).
However, operator overloading is simply syntactic sugar and can be supplied either through an advanced IDE (I may look at jEdit to see how hard it would be to implement there) or through a preprocessor (jpp is one such preprocessor, though it seems hard to find on the net these days).
When doing operator overloading, it would be good to eliminate temporaries if possible. If a 'c' array object already exists before the assignment, it would be nice if "c = a + b" generated "c.assign(a.plus(b))" rather than the naive "c = new Array(a.plus(b))", which causes heap thrashing and unnecessary overhead. My guess is that this kind of optimization would be easier with an IDE type approach. (I hope that made sense!)
299,792,458 m/s...not just a good idea, its the law!
One clarification. Potentially unsafe code in Java, such as deleting files, must be written to explicitly request permissions from the Java security infrastructure. Code that does not ask permission will not run in a sandboxed environment. Java's security infrastructure is not tied to running in a browser or other hosted environment--the user can change the permissions for running any piece of Java code, anywhere on the system.
The default behavior for Java applications, though, is no sandbox.
299,792,458 m/s...not just a good idea, its the law!
First, Java can run C code using JNI, just not by default in the browser sandbox. Any Java application can use JNI. This is the direct comparison with the "unsafe" keyword in C#. The main difference here is it is much less easy to mix unsafe code throughout your project in Java.
Second, Java can do "unsafe" (in the generic sense) things like delete files, just not by default in the browser sandbox.
Finally, a signed Java applet running in the browser sandbox can request additional privileges outside the sandbox, but it is up to the user to grant them.
I hope that helped.
299,792,458 m/s...not just a good idea, its the law!
You say that mIcrosoft has dropped hints that it will not permit cloning of the Winforms classes. Can you be specific?
What is it that Microsoft has said/done to create this impression?
As I recall there was an article on news.com that quoted the President of ECMA as saying there were not and could not be licensing fees for ECMA standards, while Microsoft seemed to be saying there were elsewhere in the article. I couldn't find that exact article, but this one seems to cover most of the issues. Note that WinForms is absolutely not part of the ECMA standard. Also note that in this article Microsoft says clearly that there may be license issues between their software (even the ECMA standard) and Free Software licenses.
One especially pertinent snippet from the article:
"Part of the ECMA (standardization process) provides a forum for us to license the intellectual property you will need to have to implement the standard," Goodhew [a Microsoft product manager] said. "It's up to the implementers to make sure whatever license they choose to use is compatible with the ECMA licensing terms."
I hope de Icaza has looked over the "ECMA licensing terms" very, very carefully. They don't cover the GUI functionality regardless.
299,792,458 m/s...not just a good idea, its the law!
Hey! It's Glock27 - the Sun's brainless Java posterchild!
Hey! It's another pathetic AC troll, making an ad-hominem attack! *yawn*
Try and add a little more substance to your argument...why is ECMA certification desirable for Java? Will I see some tangible improvement, somewhere? There is already a well-defined, published standard for the Java language.
I'm not holding my breath for a response...
299,792,458 m/s...not just a good idea, its the law!
Slashdot Mirror
It seems to me that the reasons for doing such a thing are glaringly self-evident. As far as pro-Microsoft vs. pro-Linux, this article is addressing a central issue of interest to both camps. And gee, I thought Slashdot was a forum for discussion and opinion... I presume those who aren't interested in such topics wouldn't read the article or comments.
Yup, it seems as if you are trolling, as you have added nothing to the discussion.
Did someone else advocate the US government boycott Microsoft software? If so, the mark should have been "redundant". If not, then I did add something to the discussion, no?
Although, perhaps you are on the boader of flamebait and trolling.
I'd have voted flamebait, or just linux moron...
Perhaps Slashdot needs an "Opinionated" mod, which could either be a +1 or -1 depending on which way the moderator felt it should go... ;-)
299,792,458 m/s...not just a good idea, its the law!
On thinking about this a bit more, it seems an immediate ban would cause quite a bit of chaos (possibly not more than the government deserves, however).
A more realistic approach would be a planned transition where a minimal amount of Microsoft software (bundled on new computers) was purchased, and the government must transition to a non-Microsoft platform within, say, three years.
Seems eminently reasonable to me. And talk about an economic stimulus package... :-)
299,792,458 m/s...not just a good idea, its the law!
Why should the government give billions of dollars a year to a known monopolist (who is singularly unrecalcitrant), thereby further entrenching the monopolist and discouraging competitors?
That is the untenable position, in my view.
299,792,458 m/s...not just a good idea, its the law!
There is too much of a potential conflict of interest.
Besides, think of the innovation it would spur in the software industry! ;-)
299,792,458 m/s...not just a good idea, its the law!
I'd respond, but I'm encountering syntax errors.
299,792,458 m/s...not just a good idea, its the law!
It is also very fast, and is a stunning display of Linux capability.
299,792,458 m/s...not just a good idea, its the law!
Yes, the Athlon extracts parallelism from the incoming instruction stream.
The point is simply that there is more than one way to skin a cat. No one ever would have thought that x86 would scale so well or be so competitive with RISC. (Alpha was/is great, and I'll never understand why DEC/Compaq dropped the ball so badly there...)
when a program needs to deal with more variables then registers are available they still need to spill data onto the stack (into ram) which is AMAZINGLY slow.
Don't you mean L1 cache?
Your reference box, eh? Since you're breaking your NDA just to tell us you have one (I presume), why don't you enlighten us as to the clock speed on that puppy? ;-)
Regardless, a 50-fold improvement in calculation speed is unlikely to be the result of additional registers... It would more likely be the SIMD type instructions, which use additional registers even in IA32.
299,792,458 m/s...not just a good idea, its the law!
Obviously you're not aware of how the Athlon works, among other things.
Internally, it has many more registers than four. x86 instructions only reference four registers, but internally the Athlon uses it's full set to speed up the code, as well as exploiting several types of parallelism.
For higher level languages, it is even less of an issue. There may be some impact on my Java code as to whether "int" or "long" has faster operations, but I'll guarantee that all my code using "double" will fly. The best part is that I won't even have to recompile! =)
The other thing I'll gain is that all of my dynamic allocations will have much larger memory limits. The virtual memory limit per process for the first Linux port to Hammer is 511 GB.
299,792,458 m/s...not just a good idea, its the law!
Since that bug is already fixed on current Athlons, I seriously doubt it'll be a problem with Hammer.
299,792,458 m/s...not just a good idea, its the law!
Cool, Twirlip of the Mists is on Slashdot! =)
299,792,458 m/s...not just a good idea, its the law!
Yes, after a criminal background check and a waiting period in most states. In my state there is also a requirement for a firearms training certificate, obtained by taking a test.
I hope you don't need a new gun fast someday...
All that said, the idea of somehow building "copy protection" into computer hardware is moronic beyond words. Fools.
Once again, rather than addressing the real issue (commercial content is far more expensive than it should be), the media companies are circling the wagons and trying to protect their cash cow. It's not going to work. They dynamic of the PC is too powerful.
What _really_ needs to happen is for an aggressive, well funded Internet entrepreneur to set up a web site that
a) signs up hot new talent.
b) distributes music content online at reasonable cost (say $0.50/song).
c) distributes music content on CD/DVD etc. at reasonable cost (say $5/CD).
d) sets up radio stations to play digital content straight off the internet onto the airwaves or the internet.
e) runs its own content on it's own internet radio stations.
e) has a very attractive package for the artists. There should be plenty to go around, since this would be a very lean, mean operation compared to the media companies.
I guess this would really be more like an mp3.com done right...the trick would be to be quickly perceived as a better deal for the artists than the traditional record companies. Once the buzz got going, it would do great I think. It would take major capital up front for advertising etc. though.
299,792,458 m/s...not just a good idea, its the law!
Oh yeah, and all operating systems besides Windows XP are obsolete.
ROFL.
By the way, the funniest quote in the article was:
Microsoft has some ideas (on how to break the independence on HTTP)
Now that was a Freudian slip... ;-)
299,792,458 m/s...not just a good idea, its the law!
Well, to answer my own question, on Freshmeat there appear to be one or two.
Have fun!
299,792,458 m/s...not just a good idea, its the law!
Total FUD. NVIDIA has been quite good about OpenGL support. I've played several of the first-person shooters (Quake, SoF etc.) using NVIDIA hardware and haven't had a single OpenGL related problem. Also, a person I have a lot of contact with at work uses SolidWorks (a nice 3D CAD package for Windows) which is exclusively OpenGL display with both consumer and professional level NVIDIA cards under Win2K. He hasn't had a single card-related crash, and he has some very complex models.
You should also read some of Carmack's recent .plan updates. If anyone knows how to stress an OpenGL implementation, it's him. A direct quote: 'Nvidia's OpenGL drivers are my "gold standard", and it has been quite a while since I have had to report a problem to them'. That is stellar praise from an ISV. Also you should give NVIDIA credit for it's great OpenGL support under Linux and MacOS X.
In short, if you're seeing blue screens using the NVIDIA OpenGL drivers, you very likely have a hardware problem. Otherwise, they are very good.
Now, with OpenGL 2.0, if they have to support three different API's, isn't driver quality going to suffer even more?
How so three different APIs? There will be OpenGL and Direct3D. What other one do you count?
Oh well, ATI has been getting a lot better recently, I guess we can always switch to them. :-)
Good luck...and do read Carmack's .plan carefully first.
299,792,458 m/s...not just a good idea, its the law!
Then, point out the scads of Beowulf clusters and Linux/Unix based systems.
Finally, inform the rep and your management that you've chosen to use the more cost effective, higher performance and standardized choice...Unix.
If management resists further, do a cost analysis. That'll convince them.
299,792,458 m/s...not just a good idea, its the law!
I'm being trolled, but...
Guns may be used to maim/injure/kill in self-defense, which goes quite counter to the tone of your argument.
Guns are also used to procure inexpensive food in many areas. Unless you're a vegetarian, you have no moral superiority here (actually less IMO).
Don't throw statistics at me either, since personally I'm far from the norms. ;-)
Statistics are only relevant to large samples. When the sample involves people, the statistics may often change rapidly given education.
There is also an argument in that guns may be used for recreational purposes (target/competitive shooting). That also goes counter to your argument.
Finally, like it or not, proficiency with guns aids the national defense here in the US. Look at the history of the great snipers. Most were hunters.
There are many entirely ethical arguments in favor of private gun ownership.
299,792,458 m/s...not just a good idea, its the law!
"Supports leading mobile operating systems such as Windows CE, Symbian OS, Palm OS and Linux."
also
"Use high-level programming languages such as C/C++, Java etc."
Mmmmm, another nice mobile Java platform. =)
299,792,458 m/s...not just a good idea, its the law!
I don't view Java as a religion - I view it as a technology, which, if adopted across the board, could drastically improve computing (particularly software development, and the quality of software in general). Java also encourages platform independence, and thus solid alternative platforms to Windows. C#/CLR aren't really an alternative, they are simply a (quite transparent) attempt to 'embrace and extend' Java into a component of the overall Microsoft Monopoly.
Therefore, yes, in my world view Java+JVM=GOOD, C#+CLR=BAD. It's really very simple.
You Java people are like a fucking internet death cult.
The true "Internet death cult" (as in "Death to the Internet!") is Microsoft with it's "Windows Everywhere" mentality. If Microsoft succeeds (and .Net is a cornerstone in this strategy), the Internet will become a giant hose spewing money into Microsoft's coffers. I'm sure that will be good for the computer industry! (he says sarcastically)
In my humble opinion, the only people who are pro-Microsoft to any degree at this point are fools or uninformed. Microsoft is anathema.
By the way, it's too bad you couldn't address any of the substantive points I made. Pretty weak.
299,792,458 m/s...not just a good idea, its the law!
Sorry to hear that, I hope I can persuade you a bit back towards the good side of the force... ;-)
I have mixed feelings with JDK 1.4.
I'm mostly ecstatic about it. =)
The assert facility is OK.... i don't like the fact that they added an Assert keyword but I don't get to make the decisions.
I wish they had done a better job of support DBC, but it should still be useful. I'm not too sure what it bought over just using existing "assert" hacks, which can also be compiled completely out.
There is also some controversy.
Perhaps in the minds of some...
The Log4J people are upset because there is now a 'stanard' Java package for logging. IMO the 'standard' package is inferior to Log4J in many situations.
I'm not sure what the complaint is here. If Log4J is superior (I've not looked at the logging API yet), it should still attract lots of users. Regardless, there is no way for Sun to extend the core JDK without potentially stepping on the toes of some developers. I don't see an easy way around that problem.
The regexp package is not all it is cracked up to be either. I would recommend Jakarta ORO or Jakarta Regexp.
Again, I can't comment on the technical merits of one versus the other. However, again I'm not sure what your problem is. There are alternative packages, which are better. Great, then use them! The core packages are essentially developed by committee, and are only one approach to the given problem domain. There are many tradeoffs in library design...
As far as that... it runs GREAT on Linux. Probably the most SOLID VM I have ever run.
That sounds great! I'm just about to install it.
They did break some stuff with legacy code. If you ever named a class 'URI' your code will now fail to compile because they put this class in the java.net package which everyone imports anyway.
That is not "breaking something". That is the reason Java has namespaces. Not a big deal at all.
As far as C# vs .Java. I am really impressed with the CLR/CLI stuff.
I'm not sure why...care to clarify? Have you read the comments about CLR based languages all being different skins of C#?
I'm also not sure why people seem to feel it's impossible to interface Java to legacy languages. People do it all the time using JNI.
Right now, as it stands, Java is a proprietary language. Unless we see SUN Open Source Java (or push it through a standards committee), we *may* see a JDK 1.5... but no one will use it.
Sun has made noises about open sourcing Java at some point. If it'd just release the compatibility tests as open source, that would go a long way. (It is currently perfectly fine to 'clean room' Java, as gcj is doing. You just can't call it "Java" without essentially licensing Java and getting the compatibility tests.)
Regardless of Sun's timing in releasing Java as open source, you're completely out of your mind if you think interest in Java is going to significantly lessen because of the introduction of C#/CLR. C# and the CLR are both fledgling technologies, where Java is quite proven and robust. I just read about the first CLR security exploit, and I expect many, many more. Heard of any with JVMs lately?
C# and the CLR only run on small computers and operating systems compared with the high availability big iron that runs Java. Also, Java has penetrated small devices very effectively, with over 100 million Java enabled cell phones to ship this year, very significant embedded penetration, and instruction set support for Java bytecode in all the new generation of ARM chips such as Xscale. Microsoft is caught in the middle (granted the middle covers a lot of ground;).
Despite all the rhetoric to the contrary, I advise you to expect big things from Java on the desktop as well. Sun is quietly staying the course, and is making big improvements to client side Java with every release. Since Java supports Windows, MacOS and Linux, it is a very attractive way to deploy applications (we'll see when C# achieves this milestone;). Earlier releases coupled with slower computers were painful, but things have improved to the point where Java is perfectly usable for lots of applications. Linux + Java is a potential Microsoft killer, make no mistake about it and Microsoft knows it.
My final point for today regarding the "open" nature of C# and the CLR is that quite a lot of the C# class libraries available under MS Visual Studio are not included in the standard. This includes the GUI libraries, so as things stand you can use Java today to write completely cross-platform GUI based programs. It will most likely be a cold day in hell before Winforms are available anywhere but Windows. I'm betting Microsoft's legal team will make sure of it. We'll see if Mono gets far enough to be a test case.
Sigh, now the long wait begins for JDK 1.5. ;-)
(Reptile looks cool, I'll check it out later.)
299,792,458 m/s...not just a good idea, its the law!
Content providers using copy-protection like this are fools. All they will do is drive their customers underground to find unencumbered content that the customers can use on whatever media/player they desire, as provided by fair use.
299,792,458 m/s...not just a good idea, its the law!
However, operator overloading is simply syntactic sugar and can be supplied either through an advanced IDE (I may look at jEdit to see how hard it would be to implement there) or through a preprocessor (jpp is one such preprocessor, though it seems hard to find on the net these days).
When doing operator overloading, it would be good to eliminate temporaries if possible. If a 'c' array object already exists before the assignment, it would be nice if "c = a + b" generated "c.assign(a.plus(b))" rather than the naive "c = new Array(a.plus(b))", which causes heap thrashing and unnecessary overhead. My guess is that this kind of optimization would be easier with an IDE type approach. (I hope that made sense!)
299,792,458 m/s...not just a good idea, its the law!
The default behavior for Java applications, though, is no sandbox.
299,792,458 m/s...not just a good idea, its the law!
Not for at least two usages of the word "safe".
First, Java can run C code using JNI, just not by default in the browser sandbox. Any Java application can use JNI. This is the direct comparison with the "unsafe" keyword in C#. The main difference here is it is much less easy to mix unsafe code throughout your project in Java.
Second, Java can do "unsafe" (in the generic sense) things like delete files, just not by default in the browser sandbox.
Finally, a signed Java applet running in the browser sandbox can request additional privileges outside the sandbox, but it is up to the user to grant them.
I hope that helped.
299,792,458 m/s...not just a good idea, its the law!
What is it that Microsoft has said/done to create this impression?
As I recall there was an article on news.com that quoted the President of ECMA as saying there were not and could not be licensing fees for ECMA standards, while Microsoft seemed to be saying there were elsewhere in the article. I couldn't find that exact article, but this one seems to cover most of the issues. Note that WinForms is absolutely not part of the ECMA standard. Also note that in this article Microsoft says clearly that there may be license issues between their software (even the ECMA standard) and Free Software licenses.
One especially pertinent snippet from the article:
"Part of the ECMA (standardization process) provides a forum for us to license the intellectual property you will need to have to implement the standard," Goodhew [a Microsoft product manager] said. "It's up to the implementers to make sure whatever license they choose to use is compatible with the ECMA licensing terms."
I hope de Icaza has looked over the "ECMA licensing terms" very, very carefully. They don't cover the GUI functionality regardless.
299,792,458 m/s...not just a good idea, its the law!
Hey! It's another pathetic AC troll, making an ad-hominem attack! *yawn*
Try and add a little more substance to your argument...why is ECMA certification desirable for Java? Will I see some tangible improvement, somewhere? There is already a well-defined, published standard for the Java language.
I'm not holding my breath for a response...
299,792,458 m/s...not just a good idea, its the law!