Slashdot Mirror
Gosling Claims Huge Security Hole in .NET
renai42 writes "Java creator James Gosling this week called Microsoft's decision to support C and C++ in the common language runtime in .NET one of the 'biggest and most offensive mistakes that they could have made.' Gosling further commented that by including the two languages into Microsoft's software development platform, the company 'has left open a security hole large enough to drive many, many large trucks through.'" Note that this isn't a particular vulnerability, just a system of typing that makes it easy to introduce vulnerabilities, which last time I checked, all C programmers deal with.
Good thing Linux isn't written in...
Oh. Never mind!
I actually RTFA since it included a sensationalistic phrase like "biggest and most offensive mistakes that they could have made."
.NET platform. I certainly wouldn't call this a huge mistake made by MS.
To me, it sounded like a big advertisement for Java.
It's the developers decision to use unsafe code in the
A hunting rifle can be used to kill people. Does that mean the trigger should only work after inserting a valid and current hunting license?
CowboyNeal is defending Microsoft. Someone take a screengrab, Slashdot's been hacked!
So you mean to tell me that the father of Java won't be slightly bias?
.NET is great (for its target area)
C'mon now. There is no vulnerability. Don't post this sort of crap. Its strictly knee-jerk material meant to bend a few people out of shape and start flames.
J2EE is great (for its target area)
Both are secure, stable and reasonably fast if you are a GOOD programmer. ANYONE who does ANY C or C++ code that will be used in industry needs to ENSURE that they just take a few extra precautions and are aware of secure coding techniques in both languages. Its rather quite simple.
To sum it up: nothing to see here folks.
I don't disagree with Microsofts position. Yes errors are possible, but it's a programming language, and not Microsofts responsibility. With a case like programming it is the programmers responsibility to release code without exploits... c and c++ are fast, they have many advantages other languages don't have (such as Java) if a programmer decides to take advantage of that, with a slight bump in risk, then I say more power to them.
WANNAWIKI Wannawiki WannaWiki WANNAWIKI!
This could have just as easily read "Java Creator Disses Rival Product, Ignores Flaws in His Own."
In Java, everything is an object! Oh...except for the basic types, you need to use object wrappers for those.
I guess he forgot all about JNI. Now don't get me wrong I like java and would not even think about messing with .NOT but quit telling lies, java has the same exact hole.
Got Code?
the company 'has left open a security hole large enough to drive many, many large trucks through.'"
Like, say, a truck about the size of Sun's Java runtime environment.
The coolest voice ever.
This is what really distinguishes Java from other languages. The Java verifier is a sort of theorum prover that examines the byte-code and can guarantee that it does not violate certain rules such as forging the type of a reference or under/over-flowing the stack. Because this is done at the verify stage it is still possible to compile the bytecode down to machine level instructions after that and run at full speed. This is why Java is both safe and fast.
To support C/C++ semantics (ad-hoc pointers) you'd have to throw all that out the window and I assume that's what he's talking about.
Pat Niemeyer,
Author of Learning Java, O'Reilly & Associates and the BeanShell Java Scripting language.
I hate to defend MS on this, but you have to have a certain type of permission to call unsafe code. As soon as you call anything such as that, the whole program becomes immediately unverifiable.
What were in the command language routines BEFORE C/C++?
I did Read the Fine Article and didn't find anything in it worth mentioning. Nothing specific, or even elluded to. What a waste.
New languages such as C# and Visual Basic.NET only produce managed code.
Hey, what about the keyword unsafe in C#? Sheesh.
Unsafe code is not subject to security checks of the .NET virtual machine. To execute unsafe code, you have to specifically grant those rights to the executing program. It is not something automatic.
Applications that require safety (for example running plugins downloaded from the net) simply don't allow those assemblies to be loaded.
Where is the problem again?
Gosling that Java is inherently insecure, as it is written in C.
A: .NET you can write code that harms a computer and deletes files.
.NET you can write code in C++ (which very few folks developing for .net do) and you take the risk of stupid mistakes.
.NET, though .NET makes it a bit easier with plenty of warnings.
In
B:
In Java you can write code that harms a computer and deletes files.
A:
You can write code in C#, in which case it is managed and helps prevent you from making stupid mistakes.
B:
You can write code in Java in which case it is somewhat managed and helps prevent you from stupid mistakes.
A:
Under
B:
Under Java you read Sun's document on "Integrating Native Methods into Java Programs" and write you code in C++ in which case you run risks of stupid mistakes
I fail to see the point of this article. Developers can write imperfect code if they want to. This is true in Java and
Assemblies (.NET DLLs and EXEs) require special permission to run unsafe code. In the eyes of .NET, all unmanaged code or any use of pointers is considered unsafe. This includes every C/C++ application ever. .NET's philosophy on security is clear: .NET assembly is secure except by special request to use unsafe code. Over time, all assemblies should be completely void of unsafe code except for assemblies from trusted sources.
A
For example: The end user can grant unsafe permissions to the Microsoft Managed DirectX assemblies. Anyone could then use these assemblies without needing unsafe permissions. If you trust MS MDX to use unsafe code, and you trust the app you downloaded to use MS MDX, you don't need to give the app permission to use unsafe code.
http://brandonbloom.name
It's the same with C. We should know by now "you cannot use C to handle untrusted data (ie, data from untrusted machines on the net)". All such data need to be handled in a sandboxed system, a system with safe memory access. This means something like Java or similar things.
A lot of people will make posts that say things like "C doesn't cause the problems, it's incompetent or lazy programmers who cause the problems." Whatever. No excuse. That's like saying "we shouldn't need seat belts or airbags; all we need is to make sure that drivers don't make mistakes." Drivers and programmers do make mistakes and that's why we need safety mechanisms in both cases. C provides none. Programming in C is like driving around in a car from the fifties, with no seat belts, no airbags, no head rests, no ABS.
So any decision to extend the use of C is just foolish. What is the purpose of doing this? If people must use horrible legacy code then just use it, but why drag that into new frameworks like .NET?
It does not compute, for me at least.
From the article:
"Of the approximately one thousand developers that Sterling knows, he could only recall one directly developing under the C++ code. Whether this indicates an unwillingness on the part of developers to utilise code that is unsafe is notclear."
Uh, so Sterling only knows 1 regular C++ developer out of 1000? I find that extremely hard to believe, although it is in line with the sensationalist tone of the article...
Doesn't JNI suffer the same problem (but force the developer to shoot themselves in the process from insanity)?
What about all the open-source applications built with C and C++? I.e. virtually all OSS apps?
Gosling is hardly an expert at anything. He has serious NIH syndrome and raises awareness about issues that died decades ago. Only a lay person with no knowledge of programming history would consider anything he says insightful.
.NET is probably true (I don't know however, I don't use that garbage). The issue is so beaten and rehashed that most programmers get nauseous thinking that the last half century of advancements have all been in vain.
Of course, what he says about
Dijkstra Considered Dead
--
...and of course you must be careful not to overwrite the bounds of memory blocks, free a memory block twice, forget to free a memory block,
use a memory block after it's been freed, use memory that you haven't explicitly allocated, etc. We C++ programmers have developed tricks to help us deal with this sort of thing, in much the same way that people who suffer severe childhood trauma develop psychological mechanisms to insulate themselves from those experiences.
which last time I checked, all C programmers deal with.
"Trust the programmer" is the most asinine statement ever put to paper, with the possible exception of "security through obscurity."
We have an operating system so that programmers don't have to do boilerplate file and memory operations themselves, we have good type-safe languages so they don't have to spend time profiling all of their code to make sure it doesn't have any buffer overrun risks.
___
Cogito cogito, ergo cogito sum.
No longer should homes be built using nails. All new homes should be built with really strong glue. Even though nails are faster and easier to work with, a carpenter might accidentally smash his thumb with a hammer. Plus, nails contain metal which may warp your home in the event a huge magnet is placed near the house.
--The Elmer's Glue Foundation for Strength and Security
from the throwing-stones dept. indeed. If .NET is so terrible, why does the creator of Java have to complain in the first place? I think the Java guys should spend some time bettering the look of Java UI's and the loading time of the VM; that way they shouldn't have to be so vocal to succeed. I'm not exactly sure why Sun sued MS to stop it from using the language, but since then IE users went from a non-standard Microsoft VM to Sun's standard but (in my case) slow-loading VM that takes loads of memory, with UI's that often look plain. I'd much rather have the Jellybean Start button on every Web form.
That said, it does seem redundant to have teh C in .NET, now that Managed DirectX (and most likely third-party OpenGL tools), is available. No USB support I know of though. .NET "assemblies" can be restricted to only do certain things (not read your Registry, spawn popup windows and the like) through a permissions applet in the Windows control panel; I don't know how it affects unsafe code though.
You can hold down the "B" button for continuous firing.
Maybe that's because you can't write much of the software that could be vulnerable to that sort of thing in Java at all. When was the last time you saw an operating system written in Java?
Java is an excellent example of a useful tool to help protect Joe Average programmers from certain types of programmer error. However, if you think removing pointers from a language guarantees security, then please consider that many of the most common security flaws are due to things like SQL injection, which Java does nothing to prevent.
Java is also a child's toy that regresses the state of the art by nearly 20 years in the hands of a good programmer, and those are usually the guys who write operating systems, networking utilities, etc. Any competent C++ programmer will be using pointers very little and in tightly controlled areas of the code anyway. C++ is not C, and has much stronger tools for abstraction.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Sunday! Sunday! Sunday!
C++ allowed you to do arbitrary casting, arbitrary adding of images and pointers, and converting them back and forth between pointers in a very, very unstructured way.
.NET and the unsafe keyword for managed code are there to restrict how you use native objects.
.NET handles managed code, which java can't do so easily (remember jini? Me neither) - so what .NET should really do according to Gosling is have a sandbox runtime with no severely restricted access to the native interfaces - to hell with performance compared no native methods? Oh, that'll be just like ummm .. java then.
Unstructured? Yes. A huge security hole? No more than any other language using COM objects. You can write crappy spaghetti code in any language. The type interface for
What Gosling is really criticising is the way
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
which last time I checked, all C programmers deal with.
/.
Yes, they all do, and thank fuck for that, else we would have net worms and trojans and shit spreading through unchecked buffers left right and center.
Don't just tack some bullshit to the end of the story.
The fact is, we do not have to sanity check every 3 lines of code. New languages are called new languages for a reason.
Also, I think Gosling (who has produced a language that 10 if not 100's of millions use) knows a *little* tiny bit more than you about languages, and your highschool hacker C coding isn't something to brag about.
Sorry, but fuck me for stupid one liners on
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
Oh, no! Microsoft supported arguablly most popular and well-used languages on the planet in it's product line! C and C++ give the developer total control and thus you can produce really efficient code. The byproduct is, if you are a human being, you will make mistakes, and since you have maximum control and flexibility with C and C++, these mistakes could be quite big mistakes since there is no lovely Common Language Runtime or Java Virtual Machine there to stop you. That's not a flaw in .NET, thats just a fact. Microsoft supports multiple languages, but never forced anybody to use C or C++. In fact, they are more likely to want you to use C#
Dave Bell
Despite it's origins, C# is a much better language that Java.
In C#, everything is an object, there are no funky "beans" and everything is introspectable. With Java, this just ain't so.
GJC
Gregory Casamento
## Chief Maintainer for GNUstep
There wasn't enough in the article to be exactly sure what Mr Gosling was talking about. But I know that it's quite possible to deploy malicious code into a J2EE server - and I'm not sure what kind of company would not keep check of what is being deployed (read "SDLC").
Type safety doesn't seem to me to be related to security unless you just let anyone install stuff into your production environment. And if you did then people wouldn't need to resort to exploiting that particular weakness.
Oh - you must mean when you call anything in the OS, or reference any one of their former-perfect-solution COM objects?
.NET app from the ground up. It may enlighten MS about the limitations of .NET, the pervasiveness of a good security model, and how to useful componentize an application (and NOT build it as "an integral part of the OS").
Actually, use of a language isn't the trouble, just writing *well* in that language. Even checking the source isn't problem....they do employ an army of programmers, and send them to dozens of "better C" classes, written by gurus they themselves employ.
In the end, it might be the sad support for legacy interfaces that they're stuck with, or the fact that they can't seem to upgrade all of their code fast enough. Whatever it is, MS can't seem to improve their programs without forcing a sandbox to do it, eh? Sad.
Everyone knows that in a C/C++ world, you end up adopting or building a safer framework to avoid letting newb's use the standard C lib like the wild cowboy it was born as. In fact, it's what makes "better" programmers once they learn all these crazy nuiances, down to hand-asm optimizatios. But if you're stuck with tons of code that needs to be refactored (or just completely reengineered) because of past mistakes, there is a breaking point. Applications that *rely* on cowboy tactics are there to hold you up.
SO they release a "whole new OS" every few years or so, and force everyone to jump. They make the kernel bullet proof, and thunk old code. But somehow, something like IE lives on to trick users over those damned ActiveX objects, or marketing gets their fingers into Outlook and makes it auto-run everything. Sad, but MS is a product of many teams pushing different directions - which is to say it's no different than many companies.
Perhas they will learn a lesson from Open Source after all -> many eyes makes for better checking.
As an experiment, I think MS should just re-release IE as a complete
Well, I have a truck... and .Net.... now how can I reproduce this bug!?
Well, show me a single usable Java VM. By usable I mean "not crashing all the time, able to run the same code the same way every time and still containing a decent set of features". I haven't seen one.
.NET is not an answer -- it has an abysmal record in both of these departments).
This is not a flaw of the language itself -- but the fact that after all those years we still don't have a single stable Java environment says a lot.
Java is touted as a tool for writing safe code. Now, how many life-critical applications are written in Java? And how many in C? Hmm...
And for things that don't need an extreme degree of efficiency and/or stability, there always are scripting languages like Perl or Python... (no,
The amount of Java propaganda I perceive declined a lot in the last ten years. For me, Java is a failed experiment. Let's not try to dig up its corpse. Let it rot.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Assuming this is a genuine question and not a troll: it removes the consistency from the type system that was supposed to be one of Java's original selling points, and consequently necessitates hacks involving wrapper types and/or artificial concepts like boxing to write code in Java that could be written quite straightforwardly in other languages.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Just curious... What's wrong with that?
It speaks to the purity of the language. Being able to deal with *everything* as an object is a distinct advantage since it allows you to, potentially, extend basic types into more complex ones and it also prevents you from having to "box" primitives in objects and "unbox" them on the way out.
BTW, JDK1.5 (aka Java 5) has a new feature called "autoboxing" which does the above boxing for you. This doesn't really count as those types being objects, it's more of a kludge than anything else.
This difference means that C#, from an OO standpoint, is a more pure language as opposed to Java which is a "hybrid" OO language.
GJC
Gregory Casamento
## Chief Maintainer for GNUstep
Just curious... What's wrong with that?
It's ugly and non-orthoganal. Look at the Arrays class for example; there are dozens of duplicated methods that are identical except that they take bytes, chars, shorts, ints, etc. as arguments. I'd much rather have everything be a true object; any performance issues can be handled by the compiler, runtime, or Moore's law. Autoboxing helps, but better to fix it for real than with syntactic sugar.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
Sorry if people thought I was trolling, it was a genuine question. I've been using Java for several years now and it clearly has its uses. I never heard of this "type system that was supposed to be one of Java's original selling points", but that could be my own shortcoming.
My impression was that Java is supposed to be a fully object-oriented programming language. If that's not what the project calls for, you should be using a different language instead of "necessitating hacks involving wrapper types and/or artificial concepts like boxing".
I could be wrong, but I find that people descriminate against Java because they misuse it, not because there's some fundamental flaw with it.
- shazow
Gosling is dead wrong. I believe that Microsoft will soon prove they are capable of even bigger and more offensive security mistakes.
Also, the choice to actually use .NET is at least as big of a security error.
I'm an American. I love this country and the freedoms that we used to have.
I think I see what you mean. Thanks for clarifying. Guess I never encountered this.
- shazow
If you want a language that has no "security holes", you'd better build a computer without them too. Some way or another you have to hit the bare metal in the end...
Because of the huge library of commercial software that is written in C++, they have no choice in supporting it if they want to continue their dominance in the desktop arena. Companies are not going to port their software to managed languages anytime soon because they don't HAVE to in order continue to selling their products. Microsoft also sent the message to them that they don't have to, so why would they? Even if they all started the conversion now, it would take many years to get everything converted. Even still there will be applications out there written in non-managed style. The bottom line is that it will be a very long time before everything on a Windows box (minus the OS of course) runs in a 100% managed environment.
"C and C++ allow for buffer overflows. They allow for improper or intentional coding to cause software to try to violate memory space of other functions or programs. They allow for memory allocation without necessarily providing any cleanup later. In the hands of bad, sloppy, lazy, or malicious programmers these traits have always proven to be a problem time and again on many different platforms."
C is not for everyone.
For starters, it's a small language by design.
It was used to write OS code from the beginning.
It assumes you know what you are doing and allows you to break the rules to get it done.
If you want safety go back to Pascal...
try writing povray in java. and once you're done, see how well it performs.
What a big shocker... the "father" of Java says that the .NET runtime and the C# language are terrible and you should use Java instead..
What did you expect him to say "Great job guys, everyone better use that instead of Java! I suck!"
Communism was just a red herring.
Note that this isn't a particular vulnerability, just a system of typing that makes it easy to introduce vulnerabilities, which last time I checked, all C programmers deal with. .NET was sold as a "safe" coding solution because C# was strongly typed and did bounds checking. Also, .NET puts your code in a sandbox. By using a C or C++ library with any "safe" code you make that code now unsafe because there is nothing preventing the virtual machine code of the C or C++ code form doing bad things to the (for example) C# generated code. This is a fault in the language of C and C++. It is true that all C and C++ programmers deal with it and as such I'm surprised more don't seem to understand what these dangers involve or how they can impact code written in a "safe" language (like SML) running in the same space as "unsafe" code like C.
Sam
Allowing C++ programing in .NET, or calling .NET programs from C++?
Frankly I have no F'ing idea of what's this "biggest mistake" to begin with (IMHO, the biggest mistake was bundling IE with Windows).
Man, all sensationalism and no meat. And you know, if MS had decided not to support C++ in .NET, he would have come out saying something like, ".NET must have problems if they can't even support C++ in it." Get real. And like anyone uses C++ in .NET anyway. I mean, if you really like doing things the slow and hard way, I suppose you could, but there aren't that many people that do.
.NET. I mean, it's not difficult to use my managed code, but I'm definitely making a conscious decision to use it. Oh well, pointless article.
Any C++ programmer worth his salt can pick up C# in no time and will realize it's going to save them a ton of time. I still go back to C++ when I need to do unamanged code, and hey, sometimes I have to, but it's pretty infrequent. And it's not like it just transparently blends in with
After reading the comments to this post, I have finally lost my faith in the industry... C was around before your 'secure' languages, and C will be around long after your 'secure' languages become outdated/obsolete.
I'm an amateur programmer... I do stuff for fun, and sometimes for a school project, that sort of thing. I started programming with C/C++ when I was about 8. Since then, it's been hard for me to switch to any other language. Sure, I probably could, if I tried. I have, in the past, produced working Perl and PHP code, and if I put my mind to it, I could probably learn those languages to the same degree that I know C. Now, the relevant part: C/C++ is still the dominant language! Although other languages may be technically better, they cannot compete for portability, libraries, and number of programmers and so on. The only thing that will fix the flaws of C and C++ is a redesign of the two languages with the explicit goal of creating as much commonality as possible between the the C or C++ standard and the "safe" implementation. Certainly, the only other mainstream languages are more suited to web applications, or scripting. C and/or C++ may have flaws, but it's more work to iron them out than it is to live with them.
Like shoes, the let people walk in front of buses and get run over. Can't have that flexibility for all those irresponsible people, no Sir.
You won't get around having to pay attention if you want to accomplish anything worthwhile.
What keeps me going is my inertia.
.NET has two kinds of code: safe and unsafe. Safe code makes the same guarantees as "pure" Java. Unsafe code makes the same guarantees as C, i.e., none. Of course, Java has the same constructs: it also has safe code and unsafe code. Java's unsafe code happens to be written in C/C++, however, which has lots of disadvantages compared to C#'s unsafe construct or C/C++ compiled to a CLR backend.
Gosling isn't the smartest guy around when it comes to programming languages, but even he understands this much. So, we have to conclude that his misrepresentation of the situation is deliberate FUD.
In an efficient market, price equals marginal cost. Marginal cost of software: zero.
I think you mean "efficient and infinitely large", as the efficient behavior only pushes the price down to the marginal cost asymptotically.
Not that I object to the notion in the slightest.
WARNING: there is a trojan on your
And now that JDK1.5 came up with a sort-of solution to a problem that didn't have to exist, it might be actually worth playing with. Or not...
Seriously, if I ever want to deal with boxing and unboxing objects again, I'll go back to casting black magic with templates and RTTI under C++.
This is what really distinguishes Java from other languages. The Java verifier is a sort of theorum prover that examines the byte-code and can guarantee that it does not violate certain rules such as forging the type of a reference or under/over-flowing the stack
You arae kidding, right? Do you seriously believe Java is the first or only language to guarantee runtime safety? Safe languages are the rule, not the exception.
To support C/C++ semantics (ad-hoc pointers) you'd have to throw all that out the window and I assume that's what he's talking about.
C# distinguishes safe and unsafe code. C#'s safe code is as safe as "pure" Java code. You can think of C#'s unsafe code (or its equivalent in C/C++) as code linked in through the JNI interface, except that C#'s unsafe code has far better error checking and integration with the C# language than anything invoked through JNI.
Altogether, C#'s "unsafe" construct results in safer and more portable code than the Java equivalent, native code linked in through JNI.
Pat Niemeyer, Author of Learning Java, O'Reilly & Associates and the BeanShell Java Scripting language.
Well, then I suggest you learn some languages other than Java before making such ridiculous statements.
Majority posts are defending microsoft.
Have you ever been to a turkish prison?
Summary of the article:
.NET."
:P
Java creator: ".NET is insecure because of C and C++. Java is better."
Microsoft developer: "Only if you use unmanaged code. Out of thousands, I only know of one developer using C++
Why would Slashdot even bother with this meatless story? Oh, yeah--page hits for OSTG ad clients.
Not much of a loss here but rather an opportunity for serious developers to concentrate on the UNIX world.
You're right! *goes back to hacking on Mono*
managed programs have been mentioned in previous posts (ie .NET, python...) and how in the future all "desktop" (ie non system) applications are written in one of these "managed" languages.
My problem with that is what are the virtual machines written in? C, C++, Pascal? Probably a non-managed language.
Q: What happens if there is a vulnerability in a "non-managed" application?
A: The "non-managed" application is vulnerable.
Q: What happens if a vulnerability occurs in one of these virtual machines?
A: All of my applications are vulnerable.
I know which one I would prefer.
it is only after a long journey that you know the strength of the horse.
A little off-topic, but I just have to say it now that someone mentioned Gosling...
The "enterprise" label is given to any application that meets the following requirements:
o Must be Java-based.
o Must be a bloated/slow POS that crashes every day making oncall a total nightmare.
o Must have little to no documentation(requires an expensive consultant to install)
o Must cost a lot of money cause if it was cheap it must mean it sucks. Right? uhhh
At least this is true with the company I work for.
I long for the days most webapps were written in scripting languages...
So I'd like to say thank you Gosling for making working as an IT sysadmin suck.
Seriously, how do you imagine that the garbage collection will ever be faster than the native??? I compiled Java to native with gcj and it was actually slightly slower than running inside the VM (IBM's which was quickest at the time). Either was an order of magnitude slower than C++ at the same task. I'm sick of hearing about how unsafe C/C++ is. If Java was so good, we'd be seeing all sorts of stuff popping up written in Java and I'm not talking about dinky servlets and server/browser side stuff only. Everything larger written in Java has failed miserably so far (HotJava, Corel WordPerfect, ...). Java is slower, memory intensive and not very flexible. Get over yourself and learn C++...
I'd much rather have everything be a true object; any performance issues can be handled by the compiler, runtime, or Moore's law.
That would be nice if it were possible. Unfortunately, it isn't (at least on a practical scale, esp. considering that we seem to be at the end of Moore's law). Turning everything into an object in a procedural language like Java would have a tremendous negative impact on performance, since currently there aren't practical optimizations to take care of that. Such a hypothetical language would be an immediate failure, even though it might look ellegant.
In related news, it was also announced that being alife exposes you to the very serious threat of dying. Gosling was quoted as saying that the lack of a proper cure for dying meant that science had failed, and also accused god of an inherently buggy design, demanding that life be stopped immediately so everyone could go back to a safe state of un-existance.
quidquid latine dictum sit altum videtur.
For those of you who haven't looked at C++ in 10 years or so (apparently all of you), things have changed. Modern C++ is completely different from C, and for that matter completely different from C a few years ago. Not much unchecked pointer code to deal with. In fact, NONE, except when you have to interface with a C library, and then that stuff is confined to a single well-tested abstraction layer over the C library.
Why is it that open source type people stay away from C++? The few open source C++ projects I have looked at look like they were written about 10 years ago.
If you're one of those who think C++ is just a big complicated mess, do yourself a favor and take a look at it now. I thought that not too long ago too but then I actually took the time to learn it well and it has completely changed the way I code (even in other languages!). Yes, it is big, and it is complicated, and it is most DEFINITELY not perfect. But it directly has facilities to support some very modern and powerful programming paradigms.
Sorry. This doesn't really cut it. Note the dates on the website. Its been moribund for about 2-3 years (the unfortunate side effects of downsizing useful government initiatives to fund the military/security complex and tax cuts, but that is another sad story).
Of the two "numeric" libraries mentioned on the website only one handles complex numbers and the implementation in java leaves much to be desired (relative to assembly or C). To my knowledge, the Lau Numerical libraries based on algol routines are good and probably the most extensive available in java, but there are numerous performance issues relative to FORTRAN and only some are even marginally optimized to run in parallel.
With the advent of dual core opterons in the near future and the commercialization of grid computing, as a SUNW investor, I'm still hopeful that James Gosling and Sun will step up to the plate here. So far, I haven't seen my fervent hopes come true, but perhaps you know something I don't. If so, I'd love to hear about it.
Investing aside, this is really unfortunate as 1) I love to program in java, 2) my area of interest is in the application of numeric algorithms for bioimaging and 3) I would like to make better use of such in threaded, object oriented/actionlistener/GUI contexts for which java excels. When one attempts to call numeric libraries to produce actionlisteners attached to dynamic graphics calls, even minor performance penalties can notably degrade graphics performance particularly when matrix sizes that result from even NTSC video resolutions.
I'm not too thrilled about invoking JNI as there can be a substantial overhead on calling native code such as BLAS from within java (not to mention that it is complicated, even for relatively simple function calls and of course non portable). This also ignores the problems raised about java's floating point representation and its inability to code for addition and multiplication within a single clock cycle as can be done in FORTRAN. Such problems are especially acute when dealing with eigenvalue problems in which the results contain roots with multiplicity and where ill-conditioning can be an issue for iterative solutions. Obviously, 64 bits will help in such circumstances, but its not really a general panacea.
This is all somewhat off topic, but I am always on the lookout for someone who knows better than I, as I am keen to prove myself wrong (and hence be in the position to write more effective java code).
It is ironic that Sun has move aggressively to grid computing, but has still not fully address limitations within java's numeric routines. James Gosling made some noises about attending to these defects on the forum you mentioned quite a few years ago, but to my knowledge no real response to the criticisms raised in references to be found via the website you cite. At least none that I am aware of.
Turning everything into an object in a procedural language like Java would have a tremendous negative impact on performance, since currently there aren't practical optimizations to take care of that. Such a hypothetical language would be an immediate failure, even though it might look ellegant.
Funny, I seem to have heard of some real, practical languages where every variable is an object.
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
Man, why don't you tell us why you really hate Java.
No, Java is not suitable (or useful) for what an engineer would call a "critical" application. Those applications are coded in C or C++ (or Assembler).
I'm using java because that was the business decision made by my boss (or my boss' boss). So I'm just told what I have to do (what interface the user expects, what system I have to connect to, etc.) But for the company I work for, Java might be a critical part of their business plan.
For example, you won't find java in a heart monitor in the hospital but probably find the server that keeps your health records is done in Java. Whoever is developing the Health record system can (more or less) pass the code to a new developer to continue working on it without expecting the new guy to be an expert on that particular system.
Anyway, this could all be bullshit if sound coding practices are not follow on ANY language.
That is the point of the discussion, if Java is supposed to be fully object-oriented, why are the basic types not objects.
This is about trying to add and int to a List, why do I need to convert (box) the int to an Integer to add it to the List.
There are many object oriented languages like Python, where the basic integer is an object.
I guess Java has int and Integers, because, they copied it from C++ and at the same time disallowing operator overloading.
They broke the no-operater-overloading-law with Strings, where you can add two Strings (which should be a normal object) together using the + operator. Why haven't they added all the operators for the Integer as well.
Just some inconsistencies in Java I have always wondered about when I was programming in it. You should try a language like Python, to see how fun a real object-oriented language should feel.
Oh, yeah, that's why they are taking over the world. How many commercial projects (or free for that matter) are written in Ruby, Smalltalk and Eiffel compared to C/C++, Java and now C# ?
Note: I am not saying they are bad languages. Lisp could be added to the list too (no pun intended). However in order to be really successful, a programming language must combine power with reasonable efficiency (at least for now).
Good programmers can produce good code in any language that doesn't have security holes. Of course they have to be allowed to do so, and not distracted by silly management directives like meeting deadlines. While bad programmers can create massive security holes no matter what language is involed ... and sometimes even deliver these security holes on time. Management just eats it right up.
now we need to go OSS in diesel cars
Java is way way over hyped, not to mention proprietary.
You can program C++ using classes such as std::string in a manner similar to the java string class. This eliminates most of the buffer overrun issues that plague many C programs. But unlike java you can bit twiddle when you need to, ideally encapsulating your twiddling in a class.
Java is simply a straight jacket for programmers, but straight jackets can't prevent logic errors. Your data is still at risk through stupid programming mistakes.
Ahem, in C# everything is an object ??? Excuse me, but that is blatantly false.
I now think that Java represents a belief that object oriented programming is the end point.
C++ is demonstrating there is a point beyond it in which, as might have been expected if you are Stroustrup, where OOP is just one idiom.
the point beyond is metaprogramming.
Java, like Pascal, is based on people taking themselves literally when they say they "have found the proper way to program".
Not that Java is Bad, mind you, but I'm sick of the Java programmers whining about how bad C++ is, when in fact it's still the leader in supporting whatever the machine can do in the most efficient way reasonably possible.
-pyrrho
a pickup.
-pyrrho
Duh, I missed the obvious pun.
I don't like Microsoft just as much as the next Linux user, but come on... Good programmers know how to deal with the problems inherent in C/C++. Not to mention that those problems extending beyond .NET to all C/C++ environments.
Besides, why should anyone listen to the anti-C++ rantings of one of the top dogs in Java world. Just remember that today's security is tomorrow vulnerability.
I have. I've programmed in C, Java and Python, that is why I was wondering what the big deal was. They're all very different languages, I never bothered to compare them.
:-)
I can see the inconsistancies that you're referring to but I guess I just don't question the tool... I use it.
It does take a few extra lines to convert things occasionally, but I never saw it as such a huge deal, I figured they had a good reason for making things the way they did.
Thanks for the simplified explination, though.
- shazow
1) The virtual machines are not written by the same people writing the apps. While you might be a better programmer than those writing virtual machines, as Bugtraq shows, the vast bulk of programmers aren't very good at writing C or C++ programs.
2) Even if there is a vulnerability in the virtual machine, the attacker does not usually have direct access to the virtual machine - the attacker can only go through the app, and the vulnerability might not be able to be exploited.
3) Often a bug in the VM would be found fairly quickly once it gets used by everyone because it's at a low level - it's like having your CPU not do something correctly. Only the really obscure functionality would be untouched - but if they're mostly untouched they're less likely to be problems in practice.
4) If there's a security bug in the VM, you only have to fix one thing- the VM and your apps should still work. In contrast fixing C buffer overflows etc for dozens of different programs is not that easy. Multiply that by tons of different apps by thousands of programmers and you should see the magnitude of the problem.
5) It's an example of specialisation and delegation. Go look up how many vulnerabilities there are in the Perl/Java/Python VMs. There haven't been many announced over the years. The few people who are good at writing VMs write VMs. Those that are crap at programming like me, write in Perl etc and so don't have to deal with keeping track of pointers, allocating enough memory etc, regularly screwing things up so that "an attacker can execute arbitrary code of the attacker's choice".
Unfortunately Java still has to run on an unmanaged OS. Even though the Java language provides a very nice API to a lot of things, it is not as rich as the Windows API. Microsofts API will become more and more managed when MS releases Longhorn. After that it will become increasingly secure.
I cannot see ANY similar advancement for Linux or Solaris. The problem with Java is that there is no Java OS. Even worse, there is no default way to handle Java installations or manage libraries (version management). Don't even mention Java web start please.
A Java programmer who finds it difficult to deploy his standalone applications.
I claim a huge elegance hole in Java.
I do find a few web sites online that have really crappy programming. Various errors occur, ranging from empty content, to corrupted output, to big error messages. The most common programming languages involved (based on the extensions of the filenames) are: ASP and Java. Often these errors happen due to unexpected conditions that just don't get handled properly.
Java may be able to cover up things like bad programmers leaving buffer overflows in socket I/O. But languages like Java and Perl also make it easier for morons to think they can be programmers. Then we end up with web sites and other applications that just don't do the right things at all. But at least they don't have buffer overflows and they might even have been delivered on time.
C/C++ certainly has some flaws. But we've known about them for a couple decades; good programmers know what and how to avoid them.
The real solution is to clean up the ranks of programmers. About 75% of them out there need to find another line of work. I hear Walmart has some openings.
now we need to go OSS in diesel cars
to drive trucks through is called a "bay door." I bet even Sun has bay doors at their offices.
No data, no cry
The arival of .NET is a funny occasion to suddenly realize that C is a fundamental security risk.
because .NET is such a slut.
I guess that's why there's no java native interf...
oh. nevermind.
Like we really need more Rhetoric from Sun... but I'll deal with his concerns anyway.
In order to use "unsafe" code from managed C++ (or unsafe blocks in C#) you must have "FullTrust" security rights, otherwise the code fails to run.
You could shoot yourself in the foot but the runtime is perfectly capable of detecting and coping with corruption of the managed heap (generally by closing down the offending AppDomain.) Of course you can write a COM component in C++ and call it from dotnet, which is (in effect) the same exact thing! (I dare you to try and stop me from trashing Java or dotnet once I'm loaded in process via JNI or COM...)
CAS (Code Access Security) means that no other code can call your "unsafe" methods without FullTrust either, so there is no danger from code running off the web of doing this.
JNI is the same thing, Sun just gets to hide behind the lie since the risks aren't known by or integrated with the platform. At least with unsafe code the runtime is fully aware of that pointer voodoo magic you are trying to pull and can deal with it appropriately.
In other words Game Developer X can hand-tune the rendering algorithm inside the "unsafe" code areas, but develop the rest of the platform in fully managed code, making the development process much easier to write, test, and debug.
(As an aside, thanks to the antitrust ruling Microsoft is not allowed to comment on a great many things, including competitors. I don't know if this falls under that heading, but in many cases Microsoft's employees can't just come out and call bullshit when they see it for legal reasons.)
In conclusion: Sun should shut the hell up.
Natural != (nontoxic || beneficial)
The reason you've probably never seen it, and the reason your code snippet works, is because C# is smart enough to automatically insert box and unbox instructions where appropriate.
If you want to prove this to yourself, try reading the ECMA Standard 335, which covers the topic.
Karma: -2147483648 (Mostly affected by integer overflow)
Yes, CowboyNeal, but do they want to deal with it, and should they deal with it?
For every programmer who reads security bulletins and keeps tabs on the latest string-copying buffer overflow issues and fundamental security principles, there are a hundred who don't know or care.
C is a high-level language that:
Programmers want to be productive -- most want to make things make colourful stuff happen on the screen, not fiddle around with buffer guard code. So the more security can be built into the language and its running environment, the better.
Many languages, such as Python or Ruby, provide security against what I mention in my first bullet, through a virtual machine. They're not impenetrable, and are of course, as dynamic languages, subject to a different class of security holes (eg., string evaluation of code), but they're a step up from the C level.
Other languages, like Java, provide capability-based security models, allowing for sandbox environments with fine-grained control over what a program may or may not do. Java's security system is ambitious, but since most Java apps run on the server these days, it's not frequently used, and except for browser applets, Java code tend to run unchecked.
In a way, Java tries to do what the OS should be doing. Programs run on behalf of its human user, and their destructive power is scary. Why should any given program running on my PC have full access to my documents or personal data? As we're entering an age where we have more and smaller programs, and the difference between "my PC" and "the net" is increasingly blurred. Operating systems need to evolve into being able to distinguish between different capabilities it can grant to programs, or processes -- we need to think about our programs as servants that are doing work for us by proxy.
The same way you wouldn't let a personal servant manage your credit cards, you don't want to let your program do it -- unless, of course, it was a servant (or, following this metaphor, program) hired to deal with credit cards, which introduces the idea of trust. The personal accountant trusts the bank clerk, who trusts the people handling the vault, who trust the people who built the vault, and so on.
In short, any modern computer system needs to support the notions of delegated powers, and trust.
Programmers will certainly never stop having to consider vulnerabilities in code. But painstakingly working around pitfalls inherent in one's language, be it C or indeed .NET -- we need to evolve past that. The users, upon whom we exert so much power, certainly deserve it.
Why do people think of Pascal as inherently safe? If you want to mess with pointers, it's really rather easy. Stick 'em in a variant (union) record, do your arithmetic against another named integer, and there you go. I mean really ...
"Object-oriented programming" is ill-defined. It encompasses a lot of languages that go about it in entirely different ways. To me, the most it can mean is "calling functions with an assumed this pointer." What does OO mean to you? Virtuals? What makes it "real"?
There are benefits to C beyond speed and direct access to memory, hardware, etc. People seem to forget that for us to make software "work together", calling conventions across libraries need to be compatible. Which is why we picked C calling conventions. It's not necessarily the most expressive if you're into fancy things, but it is flexible enough for most everything. My main problem with Java isn't the language -- it's the libraries. Lots of them, packaged in their own special way, not really designed for use by any language.
Languages, most of the time, aren't the issue. We haven't gained all that many 'new' features with new languages, at least not anything we can't easily live without. Access to symbols is an issue, however, and a really important one from the point of view of integration, code re-use, and even making sure you're using trusted/proven code.
Regardless of buffer overflows, you can still write infinite loops, incorrect logic, etc. in just about any language. These language wars are about markets -- they're about money.
Gosling Emacs (written by none other than James Gosling) has many HUGE security holes that you can pilot an aircraft carrier through.
Emacs has a notorious "shell" facility that can actually run a shell and send it arbitrary commands!!!
In fact, there's even a built-in scripting langauge called "Mocklisp" that enables hackers and viruses to totally reprogram the behavior of the editor (and it looks like Lisp, but without any of those confusing lexical closures and list processing functions).
Gosling Emacs is actually spyware, because it has a hidden "keyboard macro" facility that can spy on every character you type! Emacs is also malware, because at any point it can instantly undo any editing changes you've made!
One of the biggest most offensive mistakes is that James Gosling has not fixed these huge security holes in Emacs, after all these years. In fact, many of the security holes have been reimplemented in another notorious piece of communist spyware called Gnu Emacs!
All Emacs should be banned!!!
-Don
Take a look and feel free: http://www.PieMenu.com
Incompetence leads to trouble in any language. For instance, a recursive function which does not enforce a recursion limit may:
- segfault in C
- throw an unhandled exception in python
- churn up 2GB swap in java (or something similar)
In any case, think DoS. The solution is to program competently, regardless of language.
If you want to eliminate java, please fly out to mars and destroy the rovers... they're running code written in java.
and kill your 3G cell phone.
- Bart
Years before Java, James Gosling wrote a "combination macro-preprocessor and theorem prover" named Ace, which was used to compile the rasterop code in X11/NeWS.
NeWS supported all 2^4 rasterop codes, but some were MUCH more commonly used than others. So Craig Taylor and James Gosling came up with a way to write huge pyramids of parameterized CPP macros, that could generate small slow code for uncommon rasterops, and big unwrapped fast code for common rasterops and their permutations (like scrolling up and down).
Eventlly it got out of hand, so for X11/NeWS, Gosling wrote a new C parse tree based macro processor called "ACE", that was more of a "theorem prover" (isn't everything?) than just dumb string replacement like CPP. It could estimate the number of instructions and the speed of the code, and you could advise it how to make the trade-offs in deciding between "fast" and "small" branches of macro expansions. You could write a 2-d raster loop macro several different ways, with alternative ways to expand it, and ACE would decide based on how fast you wanted each raterop variation to run.
Unfortunately, Java never had a macro facility, let alone a "theorem prover" like ACE. Of couse Lisp macros are more powerful, general purpose, cleaner and better intergrated than ACE. Unfortunately, Java's C-like syntax makes it impossible to design a decent macro facility. So instead of having indecent CPP macros like C, Java has no macros at all.
The lack of a built-in macro processing facility is one of Java's major weaknesses, which is one reason that Java simply can't hold a candle to Lisp.
-Don
Take a look and feel free: http://www.PieMenu.com
Or rather, just STFU and simply wait 10 years, learn from whatever mistakes in .Net's design surface, and then introduce Java#!
Attention zealots and haters: 00100 00100
The site is indicative of what's happening with Java numerics as a whole: it's dead. It's not that Java isn't fast enough--it is--it's that the language sucks for actually writing numerical code. Writing numerical code in Java is like doing trigonometric calculations in Roman numerals.
You can choose not to allow the unsafe code blocks with security settings. He just hasn't done enough homework to know what he's talking about.
.Net programmers know a heck of a lot more than he does.
On top of this, allowing unsafe blocks of C/C++ is a good thing when people are porting to a managed language and need integration. It's pretty amazing that you can set a flag and run your old code in the new environment and call it from C#!
My impression of him has dropped significantly. Apparently experienced
Ruby on Rails? Datavision? Basecamp? Instiki?
Take a look at this ad hoc list of Ruby applied. It's a relatively young language, so there aren't as many libraries/apps as something like C or Java, but it's growing.
I don't know where you got your understanding of malloc, and especially free, but it's severely out of date. Knuth published about "Boundary Tags" no later than 1973 (citeseer is down, so no link). Saying that a coalesce operation "can be arbirarily slow" is just FUD. A boundary tag makes free() a fast O(1) operation: check the previous block in memory to see if it's free and if so join, a fast O(1) operation; check the next block in memory to see if it's free and if so coalesce; add free block to free-list, done. Yes, it's not zero work like a GC implementation sort-of is, but "arbitrarily slow"? It's basically at least as fast as malloc().
Allocation requests can hit disk, sure, but so can GC allocations even if they're just bumping a pointer: it all depends on the working set size. GC compaction can reduce fragmentation to reduce working set size, but that is only a big win if there's a lot of fragmentation, and most apps using a good malloc() don't exhibit that much. (It is also possible for a GC to rearrange memory so more in-working-set data is on pages together, reducing the working set page count without changing the total memory used. I don't know of any in-use implementations of this, since you need hardware support to know what objects are more-in-use; generally this is only available at the page level, where it's no help. I think maybe an early microde-based Smalltalk implementation might have done this.)
If your malloc has to walk giant free lists to find an open block, then sure, that can be slow. That's why people use trees of free lists based on size and such to make it more O(log N), and O(1) for small allocations. (On large allocations, actually using the memory amortizes the cost.) Read about dlmalloc, for example.
Furthermore, let's not misrepresent GC. Stop-and-collect GCs have obvious extra costs beyond the free-of-charge free (or lack of need for one). Incremental GCs that don't pause are usually slower overall and only preferred for interactive programs. For example, incremental GCs usually require "write barriers" or "read barriers" which require several extra instruction on every fetch from memory or every write of a pointer variable in memory. This can add up across the entire program. Incremental GCs also tend to be conservative, and only end up collecting things that, say, were garbage at the start of the most recent collection round, and generational collectors allow garbage to collect in later generations for some time, so they don't actually necessarily have a smaller working set than a non-leaky malloc()/free() program.
Another big win in non-GC systems is that you can use pointers that don't come off the heap. That way you can avoid allocation and deallocation and GC entirely. (You can actually do some of this in a GC system too if it's a 'conservative' GC that copes with pointers into the middle of blocks. Those pretty much only get used for adding GC to C and C++, though.) Here are some common ways this happens:
Of course, doing all these things requires that you balance your different types of malloc()s with the correct, matching type of free(). In practice, GC proponents overestimate the diffi
i was thinking more along the lines of Lisp or Scheme. please do your own research, I really don't have time to school a newbie. Java is nothing new. Hell, even pascal had P-code. Welcome to the 1980s and prior. GC is some new technology according to Java people.. what a fucking joke.
Dijkstra Considered Dead
Rule:
If you don't need to spend 5-10% of your development time to speed/size optimizing your program to make it useable, you are not using language/abstractions that is high level enough to your task.
Explanation:
If I use high level languge (say Haskell/OCaml/Clean/Common Lisp) and use all it's abstarction powers, program code will usually be 10-50% of the size compared to same program written in C/C++ (and Even Java). Now that X% (50-90%) of slack will take X% of development time and contain X% of the bugs. It will make the program much harder to change too. You can see that the 5-10% spent into optimization (you can even write the fast parts in C if you like) will pay.
If you don't belive, compare code of gnu-arch arch to darcs. Both are similar version control systems.
Dyslexics have more fnu.
This actually as happened kind of close to what you are thinking. Nails, apparantly, have been decided to be not safe enough for many tasks in home construction. They've been replaced with screws. Now if you've done any kind of construction, you know that a screw does indeed hold much better than a nail. Great, but it's damn overkill. Nails work FINE and have been working fine for centuries.
:P.
Building codes actually have been heading towards this redicilous safety level where everything has to be overspec'd. My parents built a new house receantly and it was just amazing the stupid features that had to be added to meet code. Things that make no difference, things that do not exist on almost all houses in the US (being that most houses are used not new), nevermind the world.
It wouldn't supprise me if they started requiring padded walls and floors so peopel can't accidentally bump themselves and get hurt
Did you ever contemplate that it could be because of the predominance of softwood framing or in some cases stronger joints mean less framing. Walls used to be 3' thick and solid because they didn't know how else to hold up a roof. Also roof trusses are now made to order in factories so need to hold up to transport.
Why use softwood? - The good stuff has been mowed down and what is left is snapped up for exposed or decorative uses.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
Gosling went on to say that programming on computers was far too large of a security hole and that the human brain would be the future realm of Java's "multi-platform" strategy.
No, it is the C code itself. It would also be insecure if you ran it on a C interpreter, although exploits might work differently.
I wouldn't say C++ is insecure by design, since C++ at least allows you to "easily" add high-level data management constructs to the language, so that means at least in C++ you can write safer code, if you want.
C is not safe because it does not allow safe string and vector types, and you cannot even add these without either sacrificing speed or writing weird code.
I don't even want to go into how you can cast any pointer into anything you want.
btw. How secure is Goslings emacs operating system shell ? ;-)
I'm still trying to figure out what people mean by 'social skills' here.
I am not a numerics person but I found this book:
A Numerical Library in Java for Scientists and Engineers
by Hang T. Lau
Champal & Hall/CRC
ISBN-1-58488-430-4
It looks pretty interesting.
That would be nice if it were possible. Unfortunately, it isn't (at least on a practical scale, esp. considering that we seem to be at the end of Moore's law).
Actually, it would, but the implementation would be responsible for deducing that they were arrays and what type, instead of overloading with the types as they do now.
Witness System.arrayCopy() which does take Object arguments instead of using overloading.
If we all believed James Gosling, we would all be writing everything only in Java, We would have rewritten everything in Java. There would be no more software flaws. No more security problems, No more world hunger. Pigs would fly past our windows.
no taxation without representation!
The real point here is not that C is bad or C++ is bad, but that since Microsoft is using the same device to compile C/C++/Java/VB in .Net, then the .Net engine itself could have flaws no matter what "language" you're using, JUST BECAUSE it has to support C/C++.
stuff |
I'm not a GC expert, but I think this is not universally true, in the sense that you can use the MMU hardware to trap writes.
Han-Wen Nienhuys -- LilyPond
I'm not a GC expert, but I think this is not universally true, in the sense that you can use the MMU hardware to trap writes.
Triggering a page fault that has to be passed to a user handler (which is what my textbook recommends - I haven't looked at this outside of that one course) is still slow. Slower than the alternative, which is to do nothing, at least.
There are many reasons for this:
.NET is totally mistaken, because .NET is effectively an operating system inside an operating system. .NET is a sandbox for .NET programs, while Windows is a sandbox for Windows programs. It's a wasted effort. Of course, C# might be a better C++, but that does not make the excuse of a sandbox inside a sandbox. C# could happily be a simple and plain programming language. Source-level compatibility is enough, as the Unix model proves (and Java programs are not totally portable, especially if path references are hardcoded).
1) if the security model changes, the language (run-time environment, compilers) and programs need to be updated.
2) if there is a security flaw, it affects every program written with the language; remember the Java class loader problem?
It is quite feasible to write straight C/assembly and be totally secure, as the Unix example shows us. Security has nothing to do with programming languages.
The direction taken with
CowboyNeal says: Note that this isn't a particular vulnerability, just a system of typing that makes it easy to introduce vulnerabilities, which last time I checked, all C programmers deal with.
That's the point, genius. By making the .NET platform support C, they get the problems that all C programmers deal with. Java doesn't have those problems.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
It's ugly and non-orthoganal. Look at the Arrays class for example; there are dozens of duplicated methods that are identical except that they take bytes, chars, shorts, ints, etc. as arguments. I'd much rather have everything be a true object
Than you'd be using the ArrayList class, which can store any object (including Integer, Float, etc), and has the same capacities.
ArrayList is the standard, basic Java collection class. The Arrays class is a utility class, as can be seen from the fact that all methods are static. It can be seen as a set of utilities for independent arrays of primitive types, but there's no need to use any such array. It's just there to help if you absolutely want to.
Thomas-
Java has several pretty fundamental disadvantages when it comes to serious numerical work, compared to a language like C or C++.
The most obvious is the "everything is an object" principle. If you can't create value types for things like vectors or complex numbers, you're imposing performance overheads for dereferencing before you even start doing any maths.
Moreover, serious maths work often involves large data sets. We work with graphs with many thousands of nodes pretty routinely, which can make fine control of how much memory each node occupies very important even on powerful workstations with lots of RAM. When you're constrained to do everything using indirection and using a limited set of primitive types, this is difficult to impossible.
Then of course there's Java's floating point requirements, which were technically impossible to meet for a long time IIRC. I'm not sure whether they've been fixed even today, but certainly if you require a VM to do a manual series expansion to calculate trigonometric functions according to your strict requirements, while everyone else is using a single FPU instruction and getting an answer that is either identical or off by one in the last binary place, you are not going to be winning in the performance stakes.
The bottom line is that the same things that are strengths for safety/security in general applications -- lack of low-level control and banning dangerous primitive constructs -- can be huge weaknesses when those are necessary to achieve an acceptable result in the real world.
Despite Sun's propaganda, I suspect C and C++ are still considerably more portable than Java. I don't know how you managed to get code only compiling on one machine on one platform. We routinely build our code on something like 15 different compiler/platform combinations, with many more having come and gone in the past, and anything not building on any platform is usually an old compiler failing to support a standard feature properly so we rewrite that code to work around the problem. Java's "perfectly portable" floating point requirements might be an advantage in this area -- we do occasionally see very minor discrepancies in the outputs on different platforms -- but I don't see Java as an advantage for actually compiling your code across different platforms.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
No really. I have only 1 program that uses .NET. I have to say I'm not that impressed with it (though I accept this could be a problem with the program rather than .NET itself). This program I use at work only - the .NET framework is not installed at home as I have no need for it.
Thanks for this reply.
I've been wondering myself what essential properties distinguish an object from a primitive value. If it looks and smells like an object syntactically, then surely it must be an object (doens't matter how it is implemented)?
C#'s primitives clearly aren't objects (they don't live in the heap, etc), however if you can refer to them as one, then they as well might be from the language standpoint. The question is with the automatic boxing do they mimic real objects in all aspects ?
I think the answer is no. They fail in one very important aspect. You can box a primitive variable , creating an object copy of it, however if the variable is modified the copy will not change.
Can you clarify ?
You could use that fact to argue that primitives do not, in fact, destroy C#'s pureness, since they are semantically indistinguishable from ValueType's (I think).
OR, you could argue that the existence of ValueType by itself destroys the 'pureness' of C#. ValueType does require special support from the runtime to achieve its tricks. It's impossible to write your own class, in any dotnet language, that does what ValueType does.
Karma: -2147483648 (Mostly affected by integer overflow)
Note the use of the past tense, "allowed", rather than the present tense, "allow". The clear implication being that C++ and C are obselete languates that no one writes in anymore.
Java does have some performance problems related to numerical computing. Primarily this is due to its cross platfrom nature. In java you are guarenteed to get the same answer on every platform, irrespective of the hardware FP unit. C, C++, Fortran do dot make that gauratee. FP units do produce different results for the same operation (especially trig functions) (The major one is how much accuracy is used for intermediate results in the hardware) and because of this java often has to emulate math functions to get the result you expect.
If you are not interested in cross platform usage and you know exactly what your processor does for all fp operations then you can do without java. (Note many hardware platforms are now complying to international standards for fp (properly rather then the half arsed attempts made in the past))
In general JVM's are not optimized to compile byte code to processor extensions such as MMX/SIMD/Altevec. They could, to a limited degree, be implemented to do this. They currently are not.
Most languages cannot compete (performance wise) with fortran for numerical routines. Much of this is due to the structure of the language which allows compilers to optimise well and produce very performant machine code. Also this is partly due to the sheer amount of time the routines ahve been around and the amount of manual optimization put into them. This is good if you want the ultimate in performance.
Right thats some of the arguments. Figure out what your need and make your choice. (preferably after researching even more before making your decision)
matfud
It also doesn't help with the problem of detecting stores of new pointers into old objects for generational collection.
Yes GC is an old concept but that does not mean it is static. There is a lot of research in GC techniques and optimisations. Its a changing field and producing improvements all the time.
Fortunately, it's not. Maybe I can provide some more context about my design so that he can see how this is a choice that makes the world more, not less, secure.
You can and should write perfectly verifiable code in C++ targeting .NET, perfectly safe code where you're not allowed to use those dangerous casts, etc. It's called
and it's encouraged. And writing verifiable C++ code means a lot more than just writing C# code in C++ syntax (though you can do just that if you like) -- you also get to use templates and automatic destructors and other major C++ power features safely and verifiably.For example, consider one of those other C++ power features: STL. Of course, the plain native STL isn't bounds-checked or verifiable. But we also provide a complete STL/CLR library (previously also called STL.NET) which is fully verifiable. STL/CLR is a library that brings all of C++'s familiar containers, iterators, and algorithms straight to the managed world with full interoperability with the CLI container interfaces. This is what you can do (only) in a language that supports both templates and generics: Have a template, like stdcli::vector, that implements a generic interface, like IList. You can use it as a vector (it is one); code that uses a std::vector today can work seamlessly with a stdcli::vector. You can use it as an IList (it is that, too); C# and VB (and C++) code can happily foreach on it.
And I think I already mentioned this is all completely safe and verifiable.
STL/CLR is an example of how C++ on .NET really brings together the best of both worlds, with no compromises: C++ code gets its usual full STL style of programming and full template specialization and everything else that makes the Standard C++ language and library so powerful. And you can still take one of those container objects and pass it directly to a C# or VB app that can use it naturally. It's safe.
Sure, you can also explicitly disable safe mode and write/call unsafe code too if you want -- in any language. That's not specific to C++; you can do that with C# unsafe and Java JNI. If it's immoral to call into unsafe code when you need to, why does C# have unsafe, and why does Java have JNI?
One thing this discussion does underscore, though, is the design choice difference between the JVM's "one language" and the CLR's "many languages." There's a lot of C++ code out there. Which is better for security -- to ignore that code and tell people to throw it all away because tossing it is good for them, or to give C++ developers an easier migration to take their existing valuable code and make it also be safe and verifiable?
For those interested in some more details, I've written about a number of these issues on my blog.
Cheers,
Herb
Talk about not eating your own dogfood?
It's a very dark ride.
Basically, System.arraycopy() takes Object arguments. Every array in Java is an Object, that's why this works. System.arraycopy() is normally implemented in native code to just binary copy that part of the heap, so it doesn't bother with "types" and stuff like that.
Arrays.sort() and friends, however, are implemented in Java, and need to know the array element types. Whether you should have one method which takes the array as an Object and deduces internally, or you use overloading per array type is an implementation issue. Using overloading means you don't need a cast inside the method, which is nice to avoid.
But the essence is: An array is an Object.
"No it isn't. The P-Code for Java is the way that Java apps are distributed, but on almost all VMs it is translated to pure and optimised native code. This is nothing like the 70s situation at all.
All that has been done here has been enabled by faster machines, the basic concept is still the same. Java still has to spend time translating and optimising the P-Code during run-time. Java is much quicker than a P-CODE interpreter but it still takes time to do stuff at run-time, native apps do this at compile time. Any "security" checking, no matter what the language, will eat up instructions.
"That is not the reason at all! The vast majority of this code is in C for historical reasons."
HoHoHeHeHaHa, you seriously think we should write operating systems and device drivers in Java? Wrong tool for the job, the reason they were, and still are, written in C is because assembly language takes way too much time. The reason people write apps in Java is because it takes way too much time in C for the same portability and security.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
The use of unmanaged code in .NET is unsafe, but, .NET itself has a security policy system which checks to see if unsafe code is actually used. So, Gosling
.NET, is also unsafe. Using the "unsafe" keyword and pointers within C# is also unsafe. Also, since .NET 1.0 SP3, using the compiler services to generate code is also unsafe.
.NET runtime system, which checks security permissions for that application. You cannot ship an unsafe application without the explicitly allowing unsafe content to execute. Unsafe applications cannot be run off of a network drive, nor can they be run off of a web page.
Using the import attribute to talk to a Windows DLL, that code is automatically unsafe. Link with a C++ library and wrap it using the "IJW" managed / unmanaged bridging in C++ for
All unsafe code is trapped by the
Gosling is a super programmer, and, as the inventor of Java, made popular the idea of virtual machines.
This is my sig.
you assume i don't know this. or think it is relevant to what i am saying about Gosling's NIH. neither is the case.
Dijkstra Considered Dead
I would have thought that the 'NIX crowd would be jumping up and down for joy with this revelation.
.NET has supported just C#, VB.NET as the main development languages. However, the way the CLR was MEANT to evolve and be open OPEN to the addition of new native language support.
.NET platform. Is the word OPEN suddenly causing you fear because it happens to be related to something MS did (this time)? :)
:)
For years, you've all been whining and crying about how MS is 'proprietary this and 'closed that -- nad now when they DO decide to open up the CLR with ADDITIONAL language support - now you're whining about security? Gimme a break!
Until now, the CLR in
Yes folks -- PERL.NET, PHP.NET -- and even, (god forbid) Fortran.NET, or COBOL.NET could be seen someday soon.
The support of C and C++ does nothing but open the door for people who otherwise would not have access to the
Java dudes -- stick to the sandbox where you won't get hurt -- bury your heads in the sand if you want -- but don't block the road for people who WANT the power and speed of C, C++ and C#. (I run with knives too -- AND LIKE IT!
.NET and Java are both insecure, because they both rely on too much code written in unsafe languages.
.NET and Java allow any arbitrary application to load unsafe code.
.NET will never be secure with its current architecture. Neither will Java. I am personally convinced that language-based security can be made to work (using a capability security model), but not the way Microsoft or Sun are doing it.
If you want to implement a system based on language-level security using a mixture of code in safe and unsafe languages, as little as possible of the system must be written in the unsafe language(s), and that part must be treated as being in the system TCB.
Some unsafe code is unavoidable if you want the system to be able to use OS facilities on Windows and Unix. However, it must be written by people who know how to write secure code, and gone over with a fine-tooth comb for possible weaknesses.
It is completely disingenuous for either Microsoft or Sun to claim that these platforms are secure, given that their implementations depend on millions of lines of unsafe-language code that no-one is ever going to review properly. Even more so since both
So basically, Gosling's argument is correct:
True, Java is unlikely to be self hosted. But you should remember that compiler desiners are top programmers while majority of programmers are only average (its after all the definition of "average").
// // 100 Lines code with lot's of if () and for () and an enourmous switch () // // // 100 Lines futher code with more if () and for () // and an another enourmous switch () //
And here lies the fundametal problem of modern software development - C/C++ are to difficult for the average programmerer - still there are the most used languages.
You don't agree? I give you an example. A programming language for average programmers should not compile the following code:
int X [10];
X [10] = 1;
Or if it does compile a runtime exeption should be raised. You think everybody would spot that? Well how about:
int X [10];
int Y;
Y = 10;
X [Y] = 1;
The is a statistic that the average Ada programmer spends only 1/10th of its time with a debugger when compared to the average C programmer.
Martin
It is quite feasible to write straight C/assembly and be totally secure,
as the Unix example shows us. Security has nothing to do with
programming languages.
But they are not. At least twice a week I get a security update from SuSE. Usualy a buffer overrun and sometimes an integer overrun.
Now if you think that Algol 60 (yep 1960!) has build in buffer overrun protection it make you wonder. All those update would not be needed when a language was used which provided basic security features.
And indeed the Boing 7E7 Dreamliner Software in witten in Ada - which has both build in buffer overrun and build in integer overrun protection. And guess what: The Airbus uses Ada as well.
Martin
Or else it might have that security hole too.
Java guarentees that your program calculates the same result on every platform? Then why is thread scheduling platform and even JVM dependent? Why is garbage collection platform and even JVM dependent? If you are supposed to write code that doesn't depend on thread or garbage handling differences, then the same can be said for languages like C or Fortran, where you are not supposed to write code that depends on endian or floating point differences and hence C and Fortran are also cross platform.
The truth is that Java simply doesn't take advantage of platform specific optimizations, while other languages do. This is a drawback to Java in its current state. Nothing is stopping somebody from writing a better Java compiler... but then I could have said that back in 1995 too.
The problem is that the garbage collection methods used by Java are over 25 years old!
He's right, but this kerfuffle is blown out of proportion. He's only banging the original "safety" features of Java really hard. C/C++ is less safe than Java, which is a feature to many programmers who want more freedom in what they execute - risk takers. But since most people never change their defaults, even security constraints in .NET that could stop unsafe C/C++ code are rarely applied. That contributes to the lower safety. This is the basic impetus for Java itself, universally accepted. The only controversy here results from Sun's loss of Kim Polese, who masterminded the Java launch marketing, successfully communicating the advantages of code safety, even before it was a daily headline issue. Gosling is very well informed, and quite smart - as is obvious. When you start thinking that a bunch of .NET programmers are a lot smarter than him, you should examine your premises.
--
make install -not war
and give him a pencil and he'll kill much more people. Reference: George W. Bush. All depends on which pencil.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
As I said in another reply to you thread scheduling and garbage collection do not alter the results produced by your code.
The threading model provided by java works as advertised. If you did not take the time to RTFM then its your own fault you got bit.
And as I have said before java can and does take advantage of platform specific optimisations. VM's are capable of compiling bytecode to machine code (after security checks have been performed)
But all of that is pretty much beside the point. Java is popular is areas where you need a language that tries fairly hard to protect developers from themselves. Its not as powerful as C/C++ but with power comes responsibilty and the increased chance of doing something really nasty. It does not matter if you think that java is faster/slower then language x, it has its place.
The code I write is complex (there is lots of it) and using a language that can stop anyone on the development team from making stupid mistakes is a win for us. It is also a win for our customers as they end up with products that are more reliable. Yes they still have bugs but those bugs do not crash the servers (web servers/app servers that is). This means more reliability for them.