First Impressions of Java
What can you learn from test-driving a language?
While I am a recent graduate of software engineering boot-camp, a Whole Foods Meat Cutter, and sometimes a Medium blogger; I am also a job seeker. If you have searched for work in any technical industry you have looked for jobs that match your skill-set and you have likely had the same realization that I did. That you aren't going to find any positions with requirements that mirror your resume.
Instead, what you find in the requirements section of many of those job postings is a well-packaged, succinct, and clear list of tools and technologies with which you have little to no experience. I’m sure this came as no surprise to you, nor did it to me. When I see a list of skills such as this I closely inspect and take note of each one. These are lists of tools and technologies that are of high value to someone who seeks to improve their own skills and remain relevant in a technical way.
One such item on these lists I often see is Java. Of course, adding experience with this one language is not going to be the difference between getting the interview or not in most cases. But as I consider myself forever a student, I jump at the opportunity to discover what lessons there may be waiting for me doing some work with this language. Ruby and Javascript are my first languages and I will never forget spending months with Ruby only to be greeted with the task of learning and understanding a language that has quite a few stark contrasts to a language such as Ruby. But what is perhaps most surprising is not what makes them different but what makes them the same.
In this article, I want to describe what I gained through working with a new language, what I took from my past experience that helped, and some challenges I met within this venture.
Similarities
Java and Ruby were both developed in 1995 and both remain two of the most popular languages around the world being ranked #3 and #7 respectively on Github’s most used languages. They both span multiple paradigms used to classify programming languages such as imperative, object-oriented, and reflective. This means that in both Java and Ruby you tell the program what to do through statements (imperative), data is represented through “objects” which contain their own data in what are called “fields” (object-oriented), and the program has the ability to “intro-spect” and change its own structure (reflective). Both were designed as general-purpose languages and each of their creators wanted to make a language that is easy for developers to work with. At first, Java looks very similar to C++ or C# for reasons such as declaring primitive types of data for each variable that is created. With Ruby, this is not necessary because Ruby implies the type during assignment but the same underlying principle applies; the variable type is declared before it can be used and in each, the data type can not be changed due the “strongly-typed” nature of each. Another interesting similarity is that they both compiled and interpreted. Both are compiled into what is called byte-code and then those instructions are interpreted via a Virtual Machine.
Differences
Ruby is a dynamic language. To classify a language as dynamic is to distinguish it from a static type language. Dynamically-typed languages are designed to optimize programmer efficiency. This is something that is at the core of the Ruby philosophy and the “programmer happiness” mindset behind it. Dynamically typed means the type-checking is done at runtime. This speeds up the compile time and cleans up the source-code. If the source code is cleaner and simpler it is easier to read and understand. Dynamically typed languages have many advantages that I will be able to cover in this article but one more that stands out to me is the ability to write meta-programming and use code across various modules. This is possible because of the lack of a “Nanny State” typing system. These are huge advantages for the Ruby developer.
Java is statically typed. As mentioned before, this refers to the point at which type-checking is done. In a static language, the types are checked at the compilation phase. It is debated which type leads to better programmer productivity and each programmer is going to have their own opinion. My opinion is the sugary-syntax of languages like Ruby allow you to spend more time on the parts of your code that really do the heavy lifting and less time on the more repetitive tasks. Of course, dynamically typing does come with a cost to run time efficiency. This is in part due to the fact that dynamic languages are compiled at run-time.
For my Java project, I wanted to create a simple CRUD app with the intention of also getting some experience using AWS (more on that in the future) to host it. I decided to use a Java web framework called Spring. In my experience, using a framework gives you a great outline of what a program should look like (usually a rather opinionated outline) for that given language and provides a simple road map to getting a running application of the ground and on the web. Like most frameworks, you start by generating a “boiler-plate” application. Ruby on Rails has an incredibly useful CLI tool to initialize the framework but for Spring I used this Spring Initializr website that allows you to configure a boiler-plate Spring app depending on your Java version and build management tool. Like ruby-gems (Ruby) and npm (Javascript), Java has tools for things like managing dependencies and deployment. The most of popular of these is Maven. It was no surprise to discover a file in the top-level directory of the app that describes versions and dependencies, however, learning the flow of how to manage and install those dependencies correctly and how to deploy the app was another story.
Challenges
Even after the countless times I have installed dependencies and deployed Ruby and JS software I can still be tripped up by random errors in the build process that can be hard to debug. With that in mind, I carefully examined documentation, read articles, and watched tutorials but I was surprised to learn how difficult it can be to find the solution you need for any specific issue. With nearly every step of the process that it takes to build and run my Java Spring project, I encounter issues that warrant some level of self-education before moving on. The point of this build was not the finished project but to get exposure to new and challenging problems and there were plenty. Just the experience of thinking in a new language is challenging enough but as I got further along I had more and more questions. Questions like, how to set up the database, how to start the server, how to map to the database, and lots more. I am using an existing React app and building the API for the client with Java Spring and even with that, it took a week before I had anything close to a working application. I wish I could end this article with a link to the app after its’ completion and deployment to AWS but sadly it is still a work in progress. But soon I will be able to say that I wanted to work with Java and AWS so I build a Java app and hosted it to AWS! There is still so much to learn from this particular project and I cant;t wait to see what funny errors come my way today!
