, 30 min read
So catching overflows is unrelated to safety, that is, it does not help to prevent bugs and programming errors… is that what you think? Why is it being introduced in other programming languages?
C++ is indeed less safe than Java in most (but not all) ways. However, my point should be quite clear I would hope: Java is safer than C++ but not nearly as safe as a language can be.
Peter M Ashford says: You did notice that your example was from C?
-
The C#, Swift, Rust (etc.) people trap overflows in the name of safety. Java does not trap overflows. (That’s just one example from my list which is meant as a list of examples.)
Either you agree with people who think that trapping overflows is a safety feature, in which case you must conclude that Java lacks at least this one safety feature… Or else you disagree that it is a safety feature and you think that these other language designers are misguided.
The same issue goes for data races. Some languages prevent data races, Java does not. If you agree that preventing data races makes the programming language safer, then you must agree that Java lacks this safety feature and is thus less safe than it should be. Or else you think that preventing data races is not a safety feature.
And so forth.
If you think that unchecked overflows are safe, then I want to hear you argument. On the other hand, nobody cares whether I am right or wrong.
Please offer your insights.
-
Wiktor Wandachowicz says:
In C# programmer decides when to check (or not) for overflows.
See example: checked and unchecked statements
static void Main() {
int i = int.MaxValue;
checked {
Console.WriteLine(i+1);
// Exception
}
unchecked {
Console.WriteLine(i+1);
// Overflow
}
}
-
Looks like a good design.
-
-
Peter M Ashford says: Oh, absolutely not. I really like a lot of the ideas in Rust – like borrow checking – for example. But a lot of the things being listed as unsafe are a little silly – named parameters for example. It’s syntactic sugar and its something that most IDEs make redundant (by displaying the parameter names as you write or introspect the code).
Don’t get me wrong, I think all the features in the article are nice things to have, but if we restricted ourselves to languages that implemented all these, we’d exclude pretty much everything on the top of the Tiobe index which is not really a practical or helpful position to take.
-
It’s syntactic sugar and its something that most IDEs make redundant (by displaying the parameter names as you write or introspect the code).
The problem is not that the user can’t tell which parameter is which… the problem is that someone casually reviewing the code will not spot the problem.
-
Mouse over function – parameters appear.
-
Nikolay says: this comment is so far the only sane thing i’ve read as part of this idiotic article.
Thank you!
Wiktor Wandachowicz says: Maybe you could also mention upcoming change in Oracle licensing JDK 11 for commerial use. Otherwise only OpenJDK 11 will stay royalty-free. As stupid as it may be, this only reason may very well bring down the whole Java platform.
See for example:
https://www.google.com/search?q=change+in+Oracle+licensing+Java+11
-
It looks like folks like Amazon are willing to provide support going forward for OpenJDK…
So it is unclear to me how Oracle’s actions will pan out.
Tomas says: The 4th point is not an issue. If you use an advanced IDE like IntelliJ IDEA from JetBrains, it will show you argument hints. Also, instead of having a method which takes two arguments, you can have a method which takes a single object with clearly named properties.
-
If you use an advanced IDE like IntelliJ IDEA from JetBrains, it will show you argument hints.
All the time when you browse the code, or just when the intern coded it in two years ago?
Luke says: Ada can handle 1 and 4 and has been able to since Ada83.
Modular types will wrap around, other types will raise an exception.
Ada allows data races, but you can control that by wrapping inside a protected object when using tasks.
Ada added “not null” access types (pointers) to handle this, but it’s an afterthought and they’re not “not null” by default.
You can use named parameters and you can write them in any order you like, as long as they are named.
Razvan P says: No general purpose language is safe, or should be safe given the statements in the blog.
Preventing a memory leak as described would prevent the user to allocate memory when needed. Even if C++ still offers the faster memory allocation, allocating/de-allocating memory is not realtime safe (as it can generate an unexpected delay) and shall be avoided.
My two cents on the issue:
– programming languages are generally safe, the problem is that people are not safe.
– people safety can be achieved by better management flows (like implementing CMMI), by educating people and/or by adding redundancy in the development (expensive).
– there are always syntax candies (named parameters is one) the mainstream languages are missing. Still, I can write a perfectly Object Oriented and structured code in COBOL if needed. If you want to write good code, the key is the mindset, not the language.
TheRaven says: There are also issues surrounding fuzzing the JVM that further supports arguments against Java safety. Had initially looked forward to developing software in Java, returning to it after many years, only to find that security as well as real world memory issues plague the language. Quite a bit of wasted time and energy -sad, but had to cut off the romance.
Jorge sainz says: The security with which an application is programmed using any language is relative and depends on the experience of the programmer.
adam felson says: Safe in what manner? Any competent programmer will understand variable volatility and overflows. What are actual unsafe practices such as heap/stack overflows into code and the possibility of executing malicious code injected via buffer overflow(s)?
Fernando Arturo Gómez Flores says: Regarding the safety issues here discussed, how safer/unsafer is C# compared to Java? If I recall correctly, C# has the checked/unchecked statements to prevent arithmetic overflow. Although C# explicitly lets you include unsafe code like pointer arithmetic. C# has memory leaks as well, no doubt, and while it has syntactic sugar to allow disposing objects in a deterministic way, it does not enforce it. C# has named arguments, and C# 8 will add nullable reference types, meaning any object will have to have a valid reference and cannot be assigned null unless specifically indicated by the programmer. On the other hand, C# has dynamic objects, which throws type-safety away.
Any thoughts?
-
My own impression is that C# is generally safer, more modern than Java, for many of the reasons you invoke and others as well. C# makes it easier to get multithreading right, for example.
-
Yawar Amin says:
C#’s dynamic objects does not mean that C# is unsafe in general. It means it provides a specific, explicit, escape hatch for when you need to do something not feasible within the type system. For the same reason, Rust’s ‘unsafe’ feature does not mean that Rust is unsafe, it just means there’s an escape hatch if you need it.
“Memory leaks are memory safe in Rust”
https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
I was hoping you would give some more examples of languages that are very safe, after having pointed out languages that are not. For me, Haskell comes to mind, and you did mention Rust, but what other modern languages are there that have learned from history and avoid these pitfalls that many “safe” languages still have?
I wouldn’t call it modern, (and that’s a good thing in my books), but Ada certainly has a ton of safety features that Java lacks.
Ada is not allowed to have subsets or supper set which is a VERY good thing. There is a subset language SPARK which is very safe. I think it beats Rust.
I do not understand the Modern Language issue. Ada 2012 is a modern language. The language standard is available for free and a very readable document. There are some excellent compilers including a gcc based one.
Yeah…Ada is clearly ‘safe’ and has nearly 40 years of history. And there are plenty of others. But the industry continues to pretend safe languages don’t exist, won’t invest in building on actual experience in this area and pretend our only hope is some future innovation (current incarnation: Rust will save us from all the bugs…).
Pony is: https://www.ponylang.io/
Here is a mathematical proof:
https://www.ponylang.io/media/papers/fast-cheap-with-proof.pdf
And here I thought this was going to talk about array variancy or null-related soundness bugs in generics (not a major problem because it is papered over by generics erasure and compiler inserted casting checks.)
The key benefit of Java’s safety is that correctness bugs do not cause spooky action at a distance.
A broken linked list implementation on the JVM will not cause your password checking code to break.
This is fundamentally different to C++ where a broken linked list implementation can lead to arbitrary memory corruption, overwriting the return pointer and then jumping past the password checking code.
I do agree that memory leaks are a problem. IMO a proper VM for the future should support isolated heaps sort of like Erlang or the Midori project.
Do note that data races on the JVM are specifically limited (and consequently lead to slower code) in a few ways such as that final fields have a storestore fence after them and object references and values other than doubles and longs do not tear and so careful enforcement of Java’s sandboxing is theoretically possible (although often flawed in practise.)
Optional can also be null.
Java is also not safe with variance in generics.
Kotlin is a good example of a language that improves on language safety with generics and null. It doesn’t have nulls (although it’s untagged union None type happens to be named “null”)
None of these issues are the things that spring to mind when language “safety” is mentioned. I think of language safety as exclusively the issue of memory safety. Java is memory safe. You won’t get buffer overrun exploits like you can with C/C++.
A null pointer exception or an overflow is annoying but it’s unlikely to lead to someone hacking your computer.
TL;DR I don’t think your definition of language “safety” matches what most people mean by the word.
Would you say that Java is the safest a language can be? That is, with Java, we reached peak language safety?
Java is so far behind some of the other languages on the market today it’s not even valid to consider it safe anymore. About the only place where it’s safe is buffer overruns, but as the author pointed out simple scaler operations can result in uncaught overflows. Dartmouth BASIC was safer.
A scalar overflow is not going to give a hacker access to your computer. There’s a difference between actual safety of your computer and nice to have language features
A scalar overflow is not going to give a hacker access to your computer.
How sure are you about that?
Despite the name this still seems more like a result of the direct access to the memory (which you dont have in java) rather than the integer overflow.
And sure if you really try hard, any language idiosyncrasy when overlooked, can cause a bug, and any bug can potentially be a security risk if you keep trying really hard.
But this article doesn’t make a single valid point from the first to the last word. Utter nonsense
So Nikolay, is it fair to say that you think that the engineers who design languages that, for example, trap overflows in the name of safety, are misguided?
Would you say that a programming language that prevents data races is not safer?
Would you say that preventing data races is not a safety feature… It is a waste of engineering time on the part of language designers?
Preventing data races is a great feature. Its part of what’s great about Rust. But if not preventing data races is ‘unsafe’ then all the languages on the top of the Tiobe index are unsafe.
Again, not saying that these are not good features to have – totally agree that they are – but when you say a language is unsafe I believe that means memory-safety to most people.
I did not state that Java was unsafe without qualification. Safety is necessarily a relative statement (that’s explicit in my post). Here is my specific claim:
If ‘safety’ is your primary concern, then you have better options.
Do you disagree with this statement?
If you disagree, then you have to believe that you do not have better options. Why not?
all the languages on the top of the Tiobe index are unsafe
Python is up there in the top 3 right now. It has decent safety features. I certainly consider it safer than Java.
Then consider changing the title of the article to “If ‘safety’ is your primary concern, then you have better options (than quite a bunch of languages)”. And not the bombastic click bait that it is now. And please don’t start with a C++ vs Java anecdote, C++ probably is on the top of the “unsafe languages” list, by a margin.
I am not saying anyone doing thing differently than java is misguided or waste of whatever. I might actually even agree that trapping overflow is a good idea. But not in the name of safety, because, it has hardly anything to do with safety.
You keep throwing the word “safety feature”, “in the name of safety” etc. before any feature, but, again i told you you can do that with any language idiosyncrasy. Let me illustrate:
– Duck typing in Ruby is not safe, because people who don’t know what duck typing is can make mistakes or not read the code properly and that mistake might hypothetically sometimes have something do with security.
– in JavaScript, 1 == “1” is true and safety safety safety safety…
I mean you are a genius. Each week you can come up with an article like this and even use the same 4 reasons and just plug different language every time. Then eventually maybe come up with a new unrelated to safety reason for the sake of variety and write about some other languages that lack that feature.