I will be going over some of my experiences, observations and annoyances of having to switch to Java. These are opinions based on having worked with Java for more than 2 years, as well as having developed in C# for more than 3 years before that.
I would like to add a minor disclaimer to this post to avoid misunderstandings. I will be stating both positives and negatives on the Java ecosystem which are my opinion, and my opinion only. These opinions are subjective, and might not align with your experiences, which is certainly a possibility.
I simply do not want this post to invoke a flame war, as I think this is a topic that can be talked about in a non-harming way.
The decision to switch was made due to company where I was employed not seeing the business value in continuing to develop applications in C#. This choice was also facilitated by the fact that there was an in-house framework written in Java that the business believed to be delivering more value for customers at the time.
Having written primarily C#, having to switch to Java was hard. I was forced to learn a lot of things from scratch, and leave C# behind.
I've always thought the language or framework with which you develop is merely the tool you make the product with. If the tool is the best tool to create this product, you should be using it. The problem here is that at the time I did not agree with the business' beliefs of having to drop C# due to X being better.
I had 'learned' Java before in school, it's a common language to be taught in higher education, so generally I knew what I was getting into.
After a few weeks, there were quite a few things that were jarring to me which I will be explaining next.
There's still so many projects in the wild on Java 8. Honestly, there's a big difference between Java 8 and for example Java 11 in terms of productivity.
Set.of()
which were mostly introduced in Java 9.Optional.ifPresentOrElse()
methodNew projects were generally started on Java 11 due to compatibility reasons, even though Java 17 has been an LTS release since September 2021.
Having worked with C# there's some obvious things I missed in Java:
->
. It took a while getting used to this as I was used to using =>
from C#, JS and TS.Lombok
that hooks into your IDE and build tools to generate these getters and setters for you. Lack of features such as:
??
or the is null
construct)as
EntityViewElementBuilderService
interface paired with the EntityViewElementBuilderServiceImpl
implementation.
Impl
to their classes when they implement a certain interface. This is however four letters you do not want for your already long class name. I
to the interface and not postfixing the implementation. The I
prefixing also helps with searching directly on the interface, which comes in handy if you were planning on trying to search every implementation of this specific interface that you just found in an instant by looking for IHazCookiez
.There's a ton of good tooling in the Java eco-system, let's get into it.
Every project I have worked on used Maven
. I am sure Gradle
works just as well, but I haven't had any experience with it yet.
Maven has a lot of going for it, it uses a pom.xml
which contains management declarations for dependencies, repositories and plugins. The pom.xml
is very comparable to the .csproj
files in C# projects, bar it being a bit more verbose.
The only annoyance I've had is you usually have to mvn clean
to get a dependency change working or even have to use the IntelliJ refresh button
for things to get picked up properly.
This might just be an IntelliJ thing so YMMV.
There's multiple Java IDEs out there. In a work setting I've only worked with Jetbrains' IntelliJ
which has served me well. I have toyed around with Eclipse
and Netbeans
before but unfortunately they did not feel as complete als IntelliJ to me.
I've used Jetbrains' C# counterpart called Rider
before and actually prefer it over Visual Studio for web development.
In general IntelliJ just works for everything you need in Java development. It truly is a product built by Java developers for Java developers, and it shows.
There's some quirks though:
Every Java project I have touched in a work setting was made with Spring Boot
. This means I cannot form an opinion on other alternatives such as the more lightweight Jakarta EE
or new 'cloud native (Darn it's easy slapping the cloud nomenclature on anything new) Quarkus'
.
Spring Boot
does a lot things. It allows you to get started REALLY quick. But there's a catch ... or two:
Maybe, but also maybe not. It's true that adding these annotations works fast, it feels like a fire-and-forget process. But there's two problems with this:
Beans
in its DI container. Scanning together with some reflection usage is slow, and hinders startup time.When things get advanced, things get lost in the woods.
Beans
. It's just not fun having runtime errors of Beans that are missing on which you are depending.Beans
can be ordered. Debugging wrong ordering is a PITA.Spring magic issue
, having this kind of registration makes it hard to click through to related Beans
which inevitably makes 'trying to understand code you haven't written' harder.There's a ton of integration libraries for Spring boot which allow you to get started really quickly. Most of them hook into your existing library with zero configuration (AutoConfiguration
heh). This also means you yourself are not defining or directly calling an entrypoint for this library. Unfortunately, this makes it hard to understand the internals of the library, as you need to find the appropriate Configuration
class in which the entry point is defined which then leads you to actual implementations that allow you to understand what the library is actually doing.
If it wasn't clear by now, I personally like methods such as .AddSomeIntegration(someIntegrationOptions)
as you would see in your average C# web project. These kind of methods lets the developer click through and lets him/her access external code quickly.
My grievances with the Configuration
and the way the DI works does not take away the fact that there's an entire ecosystem out there, ready to plug into your applications in a pretty seamless way.
Bluntly said, the startup times of Java projects are pretty bad.
Java Virtual Machine (JVM)
takes a while to start up. This is also one of the reasons why Java is not that great in serverless solutions as cold starts feel extra cold.If you are a web developer and you are into trial and error development
, you will not like developing in Java. I have had projects that took 5 minutes to build and run, which results into my attention span getting lost me going on a toilet or coffee break. Some of you might think I'm an impatient person, when it concerns having to wait to see my code changes, I am.
Debugging Java projects is perfectly fine. You can follow the call stack, evaluate and manipulate variables during debugging.
The only mildly difficult thing in Spring projects in particular is the usage of AOP. AOP results in proxy objects which make debugging hard, as you usually have to unproxy
them (if possible) to get the actual implementation.
Java makes a ton of sense business-wise.
A Java LTS version usually gets 5 years+ support, this means limited support work (as in amount of times you need to upgrade) to upgrade to the next version. The way C# and .NET (Core) is evolving, you are forced into a faster update and maintenance cycle, as the support lifetime for an LTS release is only 3 years.
Java is known for being rock stable as it has been a staple in the industry for years. It's easy to hire for as it's a language that gets taught often, or apparently to migrate to.
Is it possible for a C# developer to become a Java developer?
Is it a smart move for an organization to switch tech stacks or drop a certain tech stack?
How did switching to Java influence me personally and professionally?
full-stack engineers
). Personally I think most software engineers would rather like to be an expert at one technology stack with some secondary aspects next to that single technology stack.Would I recommend making a tech stack switch like this?