Full Stack Java

DZone 's Guide to

Full Stack Java

While Android is effectively Java, it's heavily based on XML — and it requires quite a lot of work in order to get it right.

· Mobile Zone ·
Free Resource

Over the past few years, I've spoken and presented at a lot of conferences. 10 years ago, when I would go to a Java conference, I would say that the split in the Java developer community was 40% server, 15% mobile, and the rest in desktop (totally made up numbers based on anecdotal "vibes" at conferences). Today when I go to conferences almost all of the developers build server code and a few do Android work...

It seems that JavaScript has taken over the mantle of full stack from Java (I use Java as a synonym to the JVM so Kotlin, Scala, etc. are all in this boat with us).

Despite some conflicts over the past year in the enterprise developer community, Java still has a strong track record on the server side, and we've tried to fill that gap on the client side — especially for mobile apps.

While Android is effectively Java, it's heavily based on XML and requires a lot of work to "get right," leaving very little time to dance around thru the tiers of an application. Another pain point is design. On mobile, this is absolutely crucial!

I've put in a lot of work to create gorgeous apps using Java. Check out the live demos and full source code for these apps:

This (material screens) took me one to two days to build:

Material styled mobile app built in Java and working everywhereBuilding a great looking demo isn't enough, though. We need to build complete startups based on Java. Java developers need to have the ability to build apps like this with the full server side at production grade within weeks, not months, in order to be competitive in today's market of Lean startups and Agile enterprises.

Challenge Accepted

I can build a kick*ss native mobile app in Java that will include the server side, look good, and be production-grade in the store within two to four weeks. While it's not rocket science, there is still a lot of work involved in building a proper production app. (Notice that I'm not talking about some template where 90% of a specific use case is already implemented.)

The fact that I can do this relatively easily relates to my experience in Java and programming in general, so this might not scale as effectively in book form or even in a course or video. I'd like to do all of those, but at this time, I don't think they will be as effective. 

When I was getting started in the professional programming world more than 20 years ago, I already knew how to program reasonably well. However, what made a huge difference were the amazing mentors I met along the way who taught me amazing things. Mentorship is a two-way street. Today, as I mentor programmers, I get back a better understanding both of the material and the student issues.

That's why I spend 90% of my time doing support. It's not the most fun job, but it helps me keep my fingers on the pulse of the community.

Moving Forward and Asking Questions

I've been working on a boot camp program for developers where I can closely mentor a small group of programmers so they can build kick*ss apps and deploy the whole thing without much of a hassle. There are a lot of challenges. For example, how do you balance good and solid architecture with time constraints measured in weeks?

Normally, weeks is just the time we spend on the whiteboard in Java land.

There is also the dark world of mobile app development, which includes so many pitfalls in the native layer, signing, provisioning, etc., all the way to the store.

These are all "simple," but often, when we sit in an ivory tower, everything looks easy and perfect — which is why this boot camp is something I'm personally really looking forward to.

So, here is what I want to know from you guys: 

  • Do you think full stack Java is a worthy and important goal?
  • What are the top questions you have when looking at something like this?
android, app development, full stack java, mobile

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}