There are different directions within software development, and consequently they involve different career pathways. While many of them are pretty straightforward, there are also other software engineering vocations which are situated, so to speak, on the edge. If you’ve already decided to learn Java, we should talk about such software engineering jobs as a Java Full Stack developer.

Who Is a Java Full Stack Developer?

The simplest way to define a Full Stack developer is “an engineer who works both on Backend (server side) and Frontend (client side) of the software”.

In job descriptions and in general conversation, a “Full Stack’’ term can be used in order to emphasize specifically (to some extent) that an applicant is expected to reveal broader skills, demonstrating themselves as more T-shaped and proficient in different areas, as opposed to a notion of usefulness of having a rather narrow engineering skill set for working only in a very specific area.

Depending on the project complexity and specifics, Full Stack developers might or might not be in charge of some particular parts of the software.

For example, a company might have a dedicated Database developer who gets down to complicated database specific logic, a web designer (not to be confused with a graphic designer) who performs a fair part of Frontend work, or a DevOps engineer taking over all the deployments and maintenance. All of them take specific tasks off the Full Stack developer’s plate.

Especially in larger companies and teams, a typical Full Stack developer does not work on both parts in a 50 / 50 proportion. Most often this person would work more profoundly in one of the areas (either Frontend or Backend), but also would perform limited tasks in the other area. If we talk about Java Full Stack Developer specifically, most likely that would imply slightly more of an exposure into the Java based Backend.

So what skills do you need to have to become a Java Full Stack Developer? Let’s look closer at it, part by part.

Resources to Become Java Full Stack Developer

1. CodeGym

CodeGym: advanced programming online training platform

As a matter of fact, CodeGym is one of the most advanced online training platforms, and particularly good when you want to learn Java, as it is their principal area of online education. You can start with the most basic courses to get familiar with Java syntax, core concepts, continuing with databases, and your stack of choice up to very advanced chapters.

You also explore an exciting path of learning in a gamified way, you even create your own versions of popular games, such as Snake or Mine Picker. This platform also gives you access to a wide community of fellow students where you can get good support.

2. Java Fundamentals by Pluralsight

Pluralsight: a nice leaning platform with a bunch of high quality Java courses

The Pluralsight has come up with a high quality set of courses for different levels, from beginners through advanced developers, although the number of courses is limited for the latter ones. Nothing odd, just essential learning and support from top level experts. Especially for beginner and intermediate levels, all the important topics have been covered thoroughly, and you can be sure that the end result is you, writing your first apps.

3. Kotlin for Java Developers

Kotlin on Cousera from JetBrains: learn from technology creators

The best way to learn a technology is to listen to its creator. The Coursera course right from JetBrains will help you to get in touch with Kotlin, a modern language interoperable with Java (and in most cases running under JVM), considered (for what it’s worth) an official preferred language for Android development — however, widely used for Backend development these days as well.

Familiarity with Kotlin will significantly expand your job search options, especially if you are looking for more up-to-date stack projects and younger teams, and will benefit your experience a lot.

Backend (Java) Skills

Core Java and Java ecosystem

First things first: to become a software engineer (any kind of it), you obviously need to learn to code in general. Given that your language of choice is Java, you will start by getting a “core” Java skill set: the syntax, basics and concepts of the language.

You might in fact be already done with this, but in case you’re not: variables and literals, loops and if-else clauses, arrays and collections, classes and interfaces, exceptions, multithreading basics, all of these important topics you will learn at the very beginning. The best way of doing that is using a classic “must read” book, or a good online training platform (more about these below).

While finding yourself in the world of Java, it is crucial to dig deeper into the Java ecosystem. Like an airplane without air, Java is not functionable without Java Virtual Machine (JVM) and Java Runtime Environment (JRE) — I’d recommend you to adapt that terminology at very early stages and get a decent understanding of how the Java app works under that hood, of course if you want to end up having it efficient and supportable.

It’s all about practice and even more practice. Think about problems that you’d like to solve programmatically and do that in Java. Perhaps a small calculator of personal finances, a shopping list app, and similar things, yet implementable without too much of a complexity.

Learn to have your data stored

Not so many applications even can be implemented without data persistence, and there are many different ways to store data. This is where all the kinds of databases come in place.

A difference between using a database and just putting some information in files is that a database comes with technologies letting your data get properly arranged, and providing important access and data manipulation facilities: sorting, querying, filtering, searching, defining access control to restrict access when necessary, etc.

There are many words that can be said about databases and database management systems (actual software products standing between a developer and a database). In practice, you can loosely think of two major classes of databases: SQL and NoSQL.

The first one is the most essential and important especially for a Java developer, as it is a first world citizen in all the corporate and enterprise applications, thankfully to reliability and advanced technologies of working with data: probably you’ve heard about such big whales on the scene as Oracle, PostgreSQL, or SQL Server.

You will also hear about relational vs non-relational databases, meaning the way data is organized is based (or not) on relations between different data types. In practice, almost always SQL databases are relational, while NoSQL are almost always not.

At the earliest phases of your learning curve you’ll definitely want to learn some SQL language basics used to interact with an SQL database, and learn to perform the very basic CRUD (standing for Create, Read, Update, Delete) operations on the data of your first applications. A baby step is to do it in the simplest way possible: using a JDBC driver directly.

As you get more proficient, very soon you will further adapt the usage of Object Relational Mapping (ORM) systems: special software libraries which allow you to work with data in a more natural and human readable format, without writing SQL queries explicitly. Undoubtedly one of the most popular and widely used Java ORMs is Hibernate.

What’s your stack?

Once you are successfully getting on with fundamentals, it is time to level yourself up and jump straight into your Backend stack of choice — that is, a principal set of technologies used to write the project. You won’t get away with just core Java, in most medium and large projects you will need to use lots of technologies, frameworks and libraries that fulfill for you the environment to run your app in, provide a lot of standard boilerplate and standard repetitive functionality.

Two major stack options for Java are Spring Framework and Java Enterprise Edition (JavaEE). To be completely honest though, it is not actually correct to compare Spring and JavaEE as interchangeable things, because we’d be comparing apples and oranges: Spring is a set of frameworks, while JavaEE is a set of specifications and standards.

In fact, Spring can be compatible with JavaEE. However, it is typical to put them in the same line, because usually those concepts don’t get intermixed in practice: you either pick the whole Spring thing… or not. As simple as that.

Spring Framework is not just a single piece of library code — it is a big ecosystem for building the backends. It would not be an exaggeration to name it the most popular and dominating stack nowadays, and you will definitely find plenty of job opportunities with projects having adapted it as a primary technology on top of Java. That most important parts of Spring that you’ll face most certainly, include:

• Core Spring components, such as Dependency Injection (DI), Inversion of Control (IoC), and Spring MVC in general. And of course a relatively modern, but widely used and highly appreciated one by the community: Spring Boot. Don’t panic: it just sounds overwhelming, but in fact, these components are very straightforward and well designed to work together, providing a simple boilerplate to put your first Spring web application together and running in an elegant and professional way, with everything needed out of the box, including a servlet container. Your learning curve here will include acquaintance with essential design patterns that Spring apps are built upon (especially Dependency Injection and MVC), you will get familiar with Spring annotations, as well as the behavior of subcomponents they stand for.
• Spring Security. When it comes to authentication, authorization and other user access related things, this framework is right to the rescue. You will find it in any Spring based project which has any sort of access control logic.
• Spring Data. This component might not be used everywhere, but you will definitely see it in some projects. It adds nice abstractions on top of an ORM under the hood, and looks as a solid point in your resume.
• Spring AOP. Will simplify your life at the moment of handling important edge cases, like for example adding a default behavior for all the controller methods, or making the method transactional with just a few simple annotations. A useful tool in every day practice, and a good way to impress your interviewer showcasing that you are more than just another beginner.

JavaEE (Java Enterprise Edition), or more precisely Jakarta EE in its modern denomination, is another elephant in the room with a longer history. As I’ve already said, it is not a framework per se, but rather a set of specifications and APIs, with further software libraries implementing them.

A concept of Enterprise Edition the way you’d think about it and the way you use it, is a little bit different to Spring way, which exactly is the reason we are able to put them on comparison. While Spring implies that you just use the framework, and your app is running on top of only a servlet container (which with Spring Boot used you get out of the box: your app ends up being a single jar file you can run as a service), in the JavaEE philosophy instead, you have an application server, which provides you with a complete environment and all the libraries, as a context your app is running in. So basically to get going with JavaEE stack, you need to:

• Pick the application server. Usually it is a big and expensive Enterprise level software package, although there are LGPL options available. Classic examples include WebLogic, GlassFish and WildFly (ex JBoss).
• Learn the APIs that constitute a part of JavaEE. There are many important of them; here are a few examples of some most essential ones:

— EJB (Enterprise JavaBeans): defines the general structure and a way to write the business logic of your app.

— JPA (Java Persistence API), for working with data persistence using the relational SQL databases.

— JMS (Java Message Service): a spec for queueing, and the pub/sub way message exchange.

— Application UI related techs: JSP (JavaServer Pages) and JSF (JavaServer Faces).

• Pick the libraries that implement some of the above mentioned APIs, which don’t go out-of-the-box with your application server, or which you just need to use. For example, you may want to use:

— PrimeFaces, as a nice templating library and an implementation of JSF.

— Hibernate as one of the major implementations for JPA.

— AWS SQS for messaging, as an implementation of JMS, and so on.

Starting from early noughties and straight into the period of Spring blossom around a decade later, JavaEE approach was a default, and often an only feasible (for the epoch) choice for big companies to get their corporate systems developed. Which is why you often may find this stack widely used on huge, but relatively old systems backing the banks, insurance companies, airlines and so on. They have to be and will be supported for a long time ahead and cannot be easily migrated to any other stack because of their complexity and mission critical nature.

Flip Side of the Coin: Frontend

Am I supposed now to be a designer or something?

A short answer is no. However, you will indeed have to work on user interface (UI) and user experience (UX) to a certain extent, depending on the limitations of your particular role.

You could expect working day to day on an interface of your company’s corporate application, adding or changing some features. Most likely you will not have to develop much of a public facing Frontend. It is also unlikely to happen often that you’d have to create the whole application design — in most cases it will be already available in either graphic sketches, or html templates, in case if you create the application from scratch.

You can also expect to have a designer or a dedicated Frontend developer in the team, in case if the application design is crucial and especially if the software is used by company’s clients, not just as a backoffice tool.

When we are talking about web based Frontend, although there are certain existing alternative approaches, still there is almost no way we can pass by Javascript. This is the main language which is used a lot, both directly and indirectly, and you will certainly need to learn quite a bit of it.

Another important language is Typescript, which provides extra versatility and robustness compared to Javascript, by introducing data types on top of it. Some projects adapt it, some don’t. I would absolutely recommend you to get a bit familiar with it and use it especially on the projects which require data precision and accurateness, such as finance or healthcare related apps.

In some Java projects you may not be facing Javascript directly. This happens when the Frontend is powered by either such an oldie as GWT or similar, which lets you define the UI in Java with further transpiling it to Javascript under the hood. In some cases old fashioned frameworks like Struts 2 or one of JSF implementations also may be designed in a way where the Javascript exposure is minimal — this is especially true for older apps with JavaEE based backends.

Make yourself at home in this vibrant Frontend world

The best way to be competent as a Full Stack Developer today is by being up to date with at least one of the popular frontend frameworks and libraries, on top of Javascript and Typescript.

The first example is Angular. It allows you to stay within a classic style MVP and Dependency Injection paradigm when developing your Frontend, keeping the same approach as if it was your Backend. Components, services, models, the way they are designed make you think of your Frontend as of just a service interacting with other services. Although Angular is slowly losing ground to React over the last few years, it is still a popular choice as a pair for Java Backend in Enterprise style applications.

Next extremely popular tech nowadays is aforementioned React: you cannot ignore it as it is just everywhere. Learning React will open many doors for you. Unlike Angular, it comes with a more straightforward (declarative and functional) way of describing the UI, intermixing between HTML and Javascript within the component code as part of philosophy.

Vue.js is also worth mentioning here: a successful minimalistic newbie taking quite a bit of market share. It is very simple and straightforward, a bit similar to React, but has a less novateur approach (so to say), and is more close to the ground, which is why it attracts practice oriented developers who are not going for a too complicated Frontend logic.

Google Trends reveals an idea of market share among the mentioned techs (sadly not bypassed by the pandemic):

Frontend framework trends

Apart from the modern frameworks, there are a lot of older ones, still used in some projects: Backbone.js, Ember.js, and of course good old jQuery library: the latter is more than alive. You probably will have to learn one of them if you land a Full Stack job in a corresponding project.

Automated Testing and DevOps

Let machines test machines

If there is one common thing that differs a professional Java developer from an average Java developer (not to say a fraud), that would be automated testing skills. There are several kinds of automated testing, but basically, there are two major categories of them: unit testing and integration testing.

Unit testing allows the developer to ensure that every internal application component works correctly when it is fully isolated from other components. For example, instead of fetching real data from a database or a file, it takes input data from a “mocked” or “fake” component providing the same interfaces as it was a corresponding data source (or even from a real database, but specially populated and used only for unit testing).

The input data in this data source is carefully prepared to correspond to all the important use and edge cases of the component. And consequently, the developer knows exactly what component responses are expected for every input, which is the goal of unit testing: run the component against known input data and compare actual output data to the expected.

The component responding correctly (or incorrectly) helps to localize any problem much more easily and avoid an incredible number of lame mistakes and bugs when developing or updating the component, which would be way harder to detect when testing the project as a whole.

Another important side effect of unit testing is that all the components must be independent enough and properly decoupled from other components, which is what allows testing it in isolation, and which is very beneficial in terms of project support and development.

The most important “must learn” Java libraries for unit testing are JUnit and Mockito.

Integration testing is another variety of more high level testing. Unlike unit testing, it is designated to test just the opposite thing: several components working together, or with real external dependencies (databases, APIs, etc.). The idea however is very similar: provide or prepopulate a known input data, and compare the output with expected output data.

Speaking about tools, sometimes it can be the same JUnit used for the integration testing. Sometimes it can be a self-written script emulating requests and reading responses, or creating a little app with a chain of components. In particular cases also external testing suites can be very beneficial for this purpose — for example, Selenium or Cypress. The latter two are also widely used for UI testing in browsers — sometimes you may hear the term “functional testing” defining that.

…And build machines.

An increasing application complexity growth requires much more systematic approach to application components orchestration. This is where DevOps comes into the play.

A rule of thumb in the third decade of our century is that you don’t build, test and deploy your application manually. An advanced CI/CD pipeline has become an inherent sign of a project and company maturity. Tell me that you create a jar file on your computer, you send it in Slack to a single person in the team who knows how to deploy it manually to your server, restart the service and read the logs… And I’ll tell you that you’d never hire an experienced developer to work on your project. Not without giving them a carte blanche for improving that state of things.

A modern approach to project deployment, especially once this project is huge and running over many servers in different continents, is when you do as little manual actions as possible. At the very least, you can just create a pull request on Github, which will trigger building the project, automated tests to run, and automated deployment on merge.

For more advanced projects these chains include way more complicated and advanced actions, which in some cases may be a job for you as a Full Stack developer, or the company may want to hire a dedicated DevOps engineer to do this work.

Even if the latter is the case, you would still benefit enormously from getting familiar with at least a few relevant technologies, which most likely you will use in your day to day engineering work, and first of all these are Docker and Kubernetes.

Docker is a tool for containerizing your application, very widely used nowadays. Without digging too much into technical details, it creates basically a virtual environment (operating system and preinstalled software) for the app, which runs in this context as if it was a real server.

The main benefit of using containers is an ability to define programmatically any required environment very fast and easily, without recreating the whole server or reinstalling all the software on an existing one. Also it allows you to run the app in exactly (well, almost exactly) the same transparently configurable environment everywhere: locally, during testing, and in production.

Kubernetes is a so-called “orchestration” technology, used to put together and run a cluster of containers, either on top of Docker, or another containerization facility. It is very popular nowadays to launch proper numbers of different services forming the part of the app, on top of any real physical architecture and abstracting from it. Familiarity with Kubernetes will give you a huge head start in any job interview.

Software Design and Architecture

These two are arguably going to be the most important phases of the software development process, as long as you grow and lift up your seniority. Being able to see the big picture and think through the problem at hand, and decide on the right architecture and technology stack to implement your app are crucial skills for any software developer, not just a Java developer. However, it is particularly important for a Full Stack, because of increased requirements to split the responsibilities and integration.

Design patterns

A concept of design patterns basically implies that there are some “templates”, or well, patterns, which let you think less about how you are going to organize your code components and the way of their interaction. Instead of having to reinvent the whole architecture, you can think of what well known approaches could work in a given scenario. In the course of time, you will find out that some of the patterns are used literally in every second or first project — for example, Dependency Injection, or Abstract Factory.

A classic book discovering this topic is “Design Patterns: Elements of Reusable Object-Oriented Software” by the famous “Gang of Four”.

Microservices

Microservices is a popular (especially over the last years) architecture approach encouraging the engineer to split the application into several fully independent smaller ones interacting with each other, instead of having a single monolith app. This technique is especially important for a Full Stack Java developer, since Backend and Frontend per se most often constitute at least two (and in practice typically more) independent microservices. Coming back to Spring vs JavaEE comparison, it is worth mentioning that it basically is much easier to carry out the microservice architecture using Spring: JavaEE historically is more designed to be a monolith app.

A highly recommended reading about efficient tackling of this aspect is “Building Microservices: Designing Fine-Grained Systems” by Sam Newman.

REST API

This one is an important concept for a Full Stack engineer, since REST API is one of the most popular standards for Backend / Frontend interaction. In very simple terms, the practice of this standard defines the way you should use HTTP (as the main protocol to communicate with the Backend) methods and URIs to implement the way your Frontend talks to the Backend, always when the latter is built as a standalone microservice providing an API, and the Frontend is a standalone webapp as well.

REST encompasses the practice of mapping the CRUD operations against GET, POST, PUT, DELETE, PATCH and other HTTP methods, to let the Frontend act independently and get what it needs from the Backend. It suggests the way of composing the URIs for different kinds of operations, and even gives you the idea of formatting the underlying payload. You will face a REST based approach on many projects these days. As you can guess, it goes coupled with a need for a good and comprehensive knowledge of HTTP protocol.

Conclusion

Java Full Stack Developer is an advanced, exciting and incredibly versatile role, which attracts open-minded and T-shaped people. Following a simple number of steps, being enthusiastic and consistent at your learning and within your career pathway, you can acquire all the skills necessary to be successful at this role and unleash a big number of job opportunities for any level of seniority.