Comment by lateforwork
19 hours ago
You almost never see a list of banned Java features (or even banned C# features). On the other hand any serious C++ development team is going to have a list of banned features. Java eliminated the features that you would want to ban.
This seems factually incorrect and ignorant of history. Java has tons of things which shouldn't be used. Serialization (use Jackson now, not the built-in stuff), date/time (there's an entirely different namespace so you don't accidentally use garbage classes), etc.
C# similarly has old warts that are discouraged now. .NET Framework is a great example (completely different from modern c#, which used to be called "dotnet core"). WPF and MAUI are also examples. Or when "dynamic" was used as a type escape hatch before the type system advanced to not need it. ASP being incompatible with ASP.NET, the list goes on.
They're just languages, there's no reason to pretend they're perfect.
> C# similarly has old warts that are discouraged now. .NET Framework is a great example (completely different from modern c#, which used to be called "dotnet core"). WPF and MAUI are also examples. Or when "dynamic" was used as a type escape hatch before the type system advanced to not need it. ASP being incompatible with ASP.NET, the list goes on.
Almost all of this is incorrect or comparing apples to oranges.
.net framework and .net core are runtime and standard library impl, not languages. C# is a language that can target either runtime or both. Framework is still supported today, and you can still use most modern C# language features in a project targeting it. WPF and Maui are both still supported and widely used. ASP predates .net - c# was never a supported language in it. ASP.net core has largely replaced ASP.net, but it's again a library and framework, not a language feature.
Dynamic in c# and the dlr are definitely not widely used because it's both difficult to use safely and doesn't fit well with the dominant paradigm of the language. If you're looking for STD lib warts binaryserializer would have been an excellent example.
Dynamic is still nice when you’re dealing with unknown data imo. More hygienic to read than dictionary access through string keys for example.
I use it when deserializing unknown message types.
C# can be used in both .NET Framework and modern .NET (ex-core). In fact, it is possible for a C# project to target both .NET Framework and .NET with the exact same code, or to target to .NET Standard, where the same .DLL file can be loaded by both. Since the old Framework is in maintenance mode, some modern language features will not work there, but you can still be productive with the old framework.
Dynamic is largely unnecessary, and it was unnecessary even when it was introduced.
ASP and ASP.NET are completely unrelated. ASP was designed to allow dynamic webpages to be written in VBScript (like CGI). This is not something you want to do in modern languages.
Those are libraries not language features.
So is nearly all of this list.
2 replies →
dynamic is a language feature
Java has so few features that there's not much to ban. Nevertheless Java definitely has language features (in addition to deprecated library APIs, which are many) that aren't recommended today. Off the top of my mind:
* `synchronized` blocks
* raw types
* anonymous inner classes
* checked exceptions
as well as specific uses of otherwise fine language features:
* "AbstractX" style abstract classes when static and default interface methods suffice
* old-style POJO classes when records are a better choice
> Java has so few features that there's not much to ban
Exactly. Simplicity was an explicit design goal of Java.
Most items in your list are fine actually, including raw types and inner classes.
Regarding checked exceptions, it is unfortunate that people don't fully understand it, see here: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...
In C#, you would normally implement rules like this with a custom Roslyn Analyzer or with https://github.com/dotnet/roslyn/blob/main/src/RoslynAnalyze.... It’s fair to say C# projects tend to have smaller denylists than mature C++ projects, but banned APIs definitely exist in mature C# projects.
I think Java has plenty of features that end up implicitly banned at least. e.g. you will really never see a `java.util.Vector` in any modern code base. No one `implements Serializable` anymore in practice. `Objects.equals()` and `Objects.hashCode()` get you through 99% of equals/hash code implementations. The list goes on.
I guess the difference is it's rarely "dangerous" or "hard to reason about" using the old features unlike what I see in the C++ list. Java replaces things with better things and momentum shifts behind them kind of naturally because the better things are objectively better.
I have, many companies have style guides enforced via Sonar and similar tools, what you don't see is everyone putting them on the Internet.
> You almost never see a list of banned Java features ...
The instanceof[0] operator is typically banned from use in application code and often frowned upon in library implementations.
0 - https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.htm...
I've never heard of that being banned. It hasn't been banned anywhere i've written Java.
Similarly I never been in a company that outright banned c++ language of library features[1]. Turns out that different companies are different.
[1] I guess you would get some push back at review time if you used auto_ptr.
Never seen this being banned. Whats the reason?
As a Java programmer I can only think of one thing:
Reflection - unless you really need to do something fancy almost certainly a very bad idea in normal application code.
Other than that it’s either just limiting yourself to a specific JVM version or telling people not to use old syntax/patterns that were replaced with better options long ago.
I would imagine most codebases, even in modern languages, tend to have a list of banned features. Typically you use a linter to catch these.
Unless you develop games in Unity, and have banned C# features like classes or LINQ (because they allocate on heap and Unity garbage collector is bad and make your game to micro freeze / stutter). Sure there are cases where classes are fine (singletons, pooling), but still...