Full-stack Java®?

What difference does the full‑stack bit make?

A lot of Java books and tutorials stop at the server boundaries or show ancient static HTML output. I think it's important to understand the front-end portion and how it all relates. I think building a complete application including the database and the front-end helps us understand the role we have as Java developers.

In the book I go through this in steps. Building a command line app in pure Java. Then as we proceed we go through a spring boot webservice, thymeleaf then to an SPA in JavaScript which connects back to the webservice. I think this process helps new developers understand the evolutionary process we went through historically.

It's OK if a Java developer dislikes JavaScript, but I think we all need to know it well enough so we understand how everything fits together.

I also think it's very useful to learn more than one language at once. The similarity and contrast between JavaScript and Java helps drive home some of the points.

Full stack is complex to reduce in one book.
For me you can only scratch the surface of each part...

But I see a big advantage of this kind of book because it helps to put the pieces together in a nice way.

I'm wondering if this book cover how to handle security (RBAC) at row and column level in a database.
So far I haven't see anything of that.

Pitty... because it is really painfull to achieve that.

Interested to read the book even without that :-)

Thanks for sharing your knowledge

I just answered in another thread that a big missing part is Spring Security so no RBAC or anything like that. I did discuss security in the end but mostly in terms of vulnerabilities, I feel this is something we need to teach at the ground floor, developers need to understand the risks we're facing.

I chose a sample that doesn't fit too well into the RBAC paradigm (a Wordle clone). I toyed with the idea of creating an "admin backend" to the wordle where I can review statistics and then use that to teach these ideas. Maybe this is something for the second edition of the book.

I agree that fullstack isn't something we can cover in a book, by definition fullstack is more cursory in its view than going deep into a specific field. I think fullstack is a good place to start, we need basic understanding of everything. At least when we get started. Similarly to general knowledge, or lay of the land.

Then the followup book should focus on the field that is more interesting to you within that stack. E.g. Spring Boot, JPA, DBs, Frontend, etc.

Thank you.

My apologies, looks like I posted the following question in the wrong place.  I'm adding here per instruction, but don't know if the author wants to copy his answer (which was very helpful) here too.

Hi, is there any performance considerations using Full-Stack Java versus a LAMP stack?

I think you need to open your own thread for every question. I'm not sure if the answer would be moved or if I should copy and paste it...

Definitely consider security in the 2nd edition. Security is too often considered as a minor "add on" to systems, the result is people's personal data for sale all over the Internet. I was just reading about a major hospital being sued over that.

And definitely a security system should be a well-vetted one like Spring Data. Too many JEE books use a "login page" as their form data entry exercise and user-written security is almost never really secure.

Shai Almog wrote:
In the book I go through this in steps. Building a command line app in pure Java. Then as we proceed we go through a spring boot webservice, thymeleaf then to an SPA in JavaScript which connects back to the webservice. I think this process helps new developers understand the evolutionary process we went through historically.

That is so cool that you traverse the history of Java and the web. Understanding where things originated from always interests me.

Looking between a pure javascript webapp and one with a Java in any part of the stack, is one significantly more performant than the other? What are Java's strengths in the modern web?

Not to be overly direct or rude but I would like to understand your thoughts about, With the abundance of javascript frameworks out there, why should I learn Java?  It feels like typescript, react, and python among many others are stealing the show with modern web apps and maybe Rust and web assembly grabbing a slice of high performance applications. Where does Java fit in and what is it's future?  

To be clear, I don't explain much of the history but go through a similar process to the evolution of said technologies. E.g. from request-response pages and server side templates to more modern SPA.

Performance is one of those words that carries so much within it. First off, in the client side performance is a completely different thing from backend performance. Furthermore, surprisingly performance and scale can sometimes be contradictory. Overly optimizing a solution can end up breaking scalability. E.g. we can just store values in a variable which is more performant than putting them into a scope. But the latter has the advantage of working correctly when we have a cluster (multiple servers that handle the same application).

I have three tips for better performance:
1. Caching.
2. Caching.
3. Caching.

It's always caching. Even at the machine code level we move important stuff to the registers and make sure to better utilize CPU cache. This is very true in client and server code. Typical applications have a bottleneck profile, essentially a limiting factor. Most server applications should be blocked by their database. This means they're properly optimized and the cost of the database is the "speed limit". However, this can be managed via smart caching, better DB code etc. So the profiling data would still show the database taking up 90% of request time, but request time will be 10x faster.

Java's strengths in the modern web IMO are:

1. It's strict - that makes applications built in Java more organized. It also helps in the learning experience as the strictness makes it harder to shoot yourself in the foot and understand your mistakes early on.

2. It's scalable and performant

3. It's deeply observable - the ecosystem for Java management and provisioning is so much ahead of anything else that it isn't a competition. I can connect a Java virtual machine to 3rd party monitoring tools and get richness of information/capabilities that are just unparalleled.

4. It's multi-vendor - There are multiple vendors with competing commercial/OSS solutions that let you adapt to requirements.

5. The Ecosystem is unmatched in terms of libraries etc. Yes NPM has more packages but 95% of them are ridiculous packages that solve tiny things.

6. It's secure - yes, people attack it for the security vulnerabilities that come up more. That's mostly due to the vast amount of legacy in the Java universe. Modern Java applications are relatively secure and if you disable serialization (which is trivial), you would have one of the most secure platforms around.

7. It's deeply documented and that documentation is well organized.


About JavaScript frameworks... I've worked a lot with JavaScript and I feel that it's a problematic language for newcomers. The oddities of the type system make it very hard to properly understand what's going on. In that regard I think developers should learn Java first for most cases as it provides a solid foundation for you to build on top if you plan to go into server programming.

I like Typescript but I often feel it's standing on the chicken legs of JavaScript, it adds another layer of complexity and like most abstractions it leaks. Having said that, when I do frontend stuff I prefer using Typescript over JavaScript.

The important thing about our job is the constant learning process, we need to learn everything there is. If I have a job that needs a language or platform I don't know then I need to pick it up. That's crucial. In a recent job we used Spring Boot for our infrastructure but needed to support NodeJS for some functionality so I spent a lot of time with it. The things I liked about NodeJS are:

1. It's easy to get set up.
2. It's one language across the stack.

Other than that I'm honestly shocked people use it as a platform. It has many packages but that's really just "noise".  You can use it to invoke a webservice or respond to a webhook. But try writing to a database or anything complex and you start hitting brick walls. Verification of your code, even with typescript, is hard. The resulting applications are easy to deploy for simple cases but this quickly becomes a pain which requires sophisticated provisioning like Kubernetes to workaround inherent problems in the platform.

When the code scales up we deal with even worse problems as the tooling (IDEs etc) can't manage everything with the same efficiency of Java.

Rust is great, if you want to write very low level code (operating systems, etc.) you should learn it. I'm conflicted on whether one should learn C first or Rust in such a case. Notice I recommend C and not C++ which is a nightmare...

Web assembly is nonsense. It will make some impact on some niche frontend apps where there's a use case. Some smart people think it will impact the server. I highly doubt it. There's absolutely no technical reason for that and it goes against the trend of making code more efficient. We dumped virtualization in favor of containers to reduce abstraction layers. Why should we add an even worse abstraction layer for no real reason?

The claim of "polyglot" programming is bunk. Yes, we should all learn multiple languages, I agree. But webassembly is about celebrating polyglot which has failed in many past situations. The environment itself is behind the JVM we had 20 years ago. This is one of those nonsense trends driven by VC investment.

Why did you say that moving stuff into registers improves performance? Is it like the old C practice of declaring variables as register and then finding the performance hasn't improved at all? Did you say in the book that without profiling variables, people used to move the wrong thing into the registers?

Totally ;-)

The compiler was usually pretty good at assigning registers so that keyword was generally pretty useless. At that level it's pretty hard to control.

Peter Stampede wrote:

Shai Almog wrote:
In the book I go through this in steps. Building a command line app in pure Java. Then as we proceed we go through a spring boot webservice, thymeleaf then to an SPA in JavaScript which connects back to the webservice. I think this process helps new developers understand the evolutionary process we went through historically.

That is so cool that you traverse the history of Java and the web. Understanding where things originated from always interests me.

Looking between a pure javascript webapp and one with a Java in any part of the stack, is one significantly more performant than the other? What are Java's strengths in the modern web?

Not to be overly direct or rude but I would like to understand your thoughts about, With the abundance of javascript frameworks out there, why should I learn Java?  It feels like typescript, react, and python among many others are stealing the show with modern web apps and maybe Rust and web assembly grabbing a slice of high performance applications. Where does Java fit in and what is it's future?  

I can only agree on that.

For me following are mostly always missing I would love to see covered in a (series of) book(s):

1. Security at service levels are often described with ACL, but mostly never with RBAC or similar concept (ABAC, PBAC, ...)
2. Security at data level (row + column) is almost never considered
3. Security with inheritence concept
4. Time period for security (access day x from till day y)
5. Working hours (from 8h to 17h)
6. Delegation of rights
7. Calendar of rights Delegation (during holidays, etc)
8. Auditing of service access (who did what when)
9. Auditing of data access (who had access to what when)
10. History of changes (who changed what when)
11. Performance, security, audit monitoring at service level
12. Performance, security, audit monitoring data layer level
13. Rules definitions for monitoring (critical level definitions, notifications, ...)
14. AI analysis of monitorings with automatic resolution actions
15. AI analysis of service access (ex: high frequency access to data, abnormal activity, ...)
17. Code readability optimisation (loombok, ...)
18. Declarative programming (annotation for caching, security, logging, auditing, ...)
19. Licensing. How to make optionnal some part of the application, how to secure it)
20. Code obfuscation
21. Microservices with all above included
22. Versionning of (micro)service deployed (ex: service X version 1 and 2 running same time having client v1 and v2 accessing). This allow to update the clients step by step. Mandatory in big infrastructures.
23. DDD + oignon approach with all above included
24. Integration with Graphana (or similar) of all monitored data
25. Maven (or similar) integration
26. Continuous integration (with most used tools)
27. Auto Installation packaging
28. Auto and manual Deployment platform
29. Monitoring platform multi installation

I probably miss lot of points... but this is for me all jobs that a full stack developer should know.
I never found any (series of) book(s) that touch all of this.

Challenge accepted ?

I think that's a bit much and might put fullstack out of reach of everyone. To me fullstack is about "jack of all trades - master of none". That's where it should remain. E.g. it's important to have the ability to do a DevOps task, but it's not necessary to be great at it.

Fullstacks are like a medical GP. They can do everything but then know when to deffer to the expert. I think it's important to have someone with holistic view of the system. Not as a replacement for the expert, as a person who connects all of the pieces together. This enables vertically integrated teams where PRs become feature driven instead of per-tier.

In that sense I think all developers should be "fullstack", it doesn't negate having a specialty (or more than one if you're old enough). We can then assemble PRs that include a complete feature. We can debug an issue that might transcend a specific tier. The team becomes more resilient to the loss of a specific member etc. I think of fullstack as a starting point, not an end goal.

A lot of these things are very job specific and would be hard to teach in a book for the general coderanch. By the time a fullstack developer will finish reading even cursory books on all of these subjects, the information will be out of date.

Registers???

Unless my memory is even worse than I think, the JVM is entirely stack-based and has no registers as such. I would find it hard to make it do specific things with the underlying hardware registers, as well, since that would depend on the JVM implementation, and on the underlying hardware. The TMS9900 CPU, for example, had "registers" that were merely the top of its stack. The Prime series of minicomputers aliased its registers to low RAM locations.

Actually, one of the things I've enjoyed about Java is that I no longer had perpetual guilt about twiddling registers for optimal performance all the time. It gives me more brain space for the more important (algorithm-level) optimizations.

Not that I don't still look to a few low-level stunts even now. Locality of reference, keeping the top of the stack fed with operations rather than swapping different operands in and out, marking "write once" variables as final to assist the compiler's optimiser (and reduce potential bugs), and using method or block-level variable definitions where a more permanent scope (instance or class level) isn't necessary.

Fun fact for Campbell: The "register" keyword was added to C because the early compilers were dumb and generally would otherwise assign register usage by brute force. However in one case I know of it had another usage as well. The Commodore Amiga OS was an amalgam of code from several sources. The core (Exec) was an object-oriented unit written in assembly and/or C. The "DOS" portion of the system (AmigaDOS), where the device and file code resided was an adaptation of the Tripos OS, written in the C predecessor language BCPL (a/k/a the British Cruddy Programming Language). The UI parts were written in-house in Green Hills C.

The fun parts were that A) the BCPL code stack grew in the opposite direction to the C code stack. and B) for various reasons, a number of key services did not pass parameters on the stack, but instead put some or all of them in specific hardware registers. So to facilitate item B, the "register" keyword, augmented by a register ID would be coded.

In the prime of the Amiga years, C OS coding moved from the external Unix machines (Green Hills) to native Amiga and the Lattice/SAS C compiler for Amiga became not only powerful enough to handle everything on the target machine, but smart enough not to need the "register" keyword for optimisation. It became at best, advisory, at worst, ignored. Except, of course, when used to indicate parameter passing via a specific register!

So these days, in C/C++, "register" is pretty much ignored and supported only as a meaningless legacy keyword. Even the $1.50 AVR processors that I mostly work with at the moment don't need them, though they often have scarcely as much RAM as a 1960's IBM mainframe. In their case, the compiling is done on an external machine the same way Commodore originally did for the Amiga using an optimising compiler.

Yes. The JVM is a stack machine. However, the JIT translates the stack operations to platform operations and is pretty smart about assigning registers to do operations that would normally go in the stack. This is sometimes partially exposed in the JVM bytecode as locals, but typically a JVM would go much further and just write very different assembly.

The beauty of the bytecode is that the stack is always balanced for all code paths. That means I can write a JIT or AOT compiler (I'm actually writing another AOT compiler right now) that goes over the bytecode and translates the stack machine to a register based machine. JVMs do lots of other amazing things such as vectorization, although that's very challenging and doesn't happen often.

Thank you Shai,
Your post literally blew my mind, it is amazing. Honestly for that post alone I think I'll buy a physical copy of your book. I'm not kidding.

You confirm many of my doubts about modern web dev. There is a lot of hype out there, and it's hard not to get caught up in the latest craze if you spend any time on social media, youtube, etc. At the end of the day enterprise clients need reliability and all of the 7 strengths you mention mean they're going to stay with Java. No one is completely jumping ship to new dev platforms, likely just moving things to containers, DevOps, SRE, etc. Maybe Enterprises will find other supporting uses for those languages/tools, seeing if they pan out long term. Where I work we have a ton of Python tooling and Python web pages for engineering support tools.

I read that Amazon started out heavily using Perl and has since moved to primarily java (amongst many others).  I feel like this pattern repeats itself a lot, things start in any number of languages to get off the ground and ultimately move to Java for those strengths.

I do also like how much Java has matured over the past 5-10 years. It's inherited a lot from some of the other JVM languages like Scala and Groovy, which is really smart. It hasn't grown chaotically which I feel C++ has. I love the quote from the Primeagen "The best way to describe C++ is features will continue until moral improves."
Not putting any language down, Java has it's own Meme-fest I'm sure, but how Java handles it's critiques is refreshing. It actually improves.

Caching makes a lot of sense I haven't dealt with that side of application dev/devops much but I need to learn more.

Thanks again for your detailed response.

Glad to help. I think Java gets a lot of hate because it's the boring adult in the room.

People want to hang out with the cool kids. Amazingly, Python is older than Java but still holds that "irresponsible youth" mindset.

To be fair, Java isn't clear of problems. It has a lot of complexities due to legacy and due to enterprise necessity. But a lot of the hate comes from people learning Java 1.2 or 1.4 when they were in college. It's a very different language now.

OK, Just wanted to make sure I hadn't missed anything. Again, I'd be hard pressed to see where I could directly influence the register usage of a JVM, especially since the number, usages and types of registers available can vary widely depending on the processor being used and the JVM's designer. Stuff that would land well in an Intel processor machine isn't likely to fit as neatly on a RISC-based ARM CPU, nor on an IBM zSeries system, which has 1 "magic" register, several others that are dedicated by convention to make up for the lack of hardware stack, and that's just the inherited stuff from S/360 and doesn't count floating-point or control registers.

Speaking of JIT, though, one of the wonderful things about JVMs is that they can be designed to monitor performance on high-use code and dynamically rewrite the machine code to function more optimally on the fly. Static compilers like C cannot do that. Older CPUs tended to have fixed clock cycles and conditional jumps often cost significantly more depending on whether the jump was taken or not. A smart recompiler could determine which option ran faster, flip the condition, if needed and relocate the target code to match. More modern processors have pipelines and the calculation gets more complex, but the principle remains the same.

Another thing an intelligent JVM can do is optimise virtual storage usage. A really awful app I once had to deal with involved a sparse matrix being used by BASIC under OS/2. Because the matrix was brute-force mapped to virtual memory, almost every element access forced a page fault, as physical RAM was also in short supply. Java has no fixed pointers at the application level, so the JVM can shovel objects around in RAM relatively easily.

Team OS/2 FTW!

Yes. Our control over registers is limited in the JVM and as you noted also in C. That's a good thing. I was mostly talking from the angle of a JVM implementer and not from an app developer perspective. There are some JSRs to improve vectorization hints which are actually also quite important for performance, but that's super niche. Unless you do heavy math, interpolation and stuff like that you don't really need that.

JIT profiling is sometimes overly promoted as a magical optimization tool. I'm a big fan of JITs but the reality is a bit more nuanced than that. A JIT compilation is often too localized and can't make a huge difference. There's virtual method inlining which is a fantastic optimization but still the JIT needs to do all the analysis in runtime. Some optimizations would just take too long or take up too much code (thus increasing CPU cache misses). Still it's pretty fantastic and in benchmarks I see JITs beating GraalVM which does validate that point.

Java's actually reversing the trend of memory management with Valhalla. We will have localized memory since for some use cases this is much faster. I'm excited about it but also a bit anxious as this can be a big performance problem when used incorrectly.

Shai Almog wrote:…Python is older than Java but still holds that "irresponsible youth" mindset.

It's because Python is irresponsible. It doesn't have the strictness that Java or even C do. A Python app can blow up at unpredictable times because of undetected coding errors or mis-matched data types. It's why I like Python for a quick-and-dirty language, but like JavaScript, don't want it in charge of sensitive or high-performance production systems.

A lot of Java's initial shortcomings was that they were attempting to invent a "better C++". One that would be instantly portable, and one that would - radically - be secure at the machine level. They also looked at the warts that C++ had developed (notably multiple inheritance), and attempted as well to design a language that was "write once/run anywhere".

Plus, this had to run on relatively slow hardware. I'm convinced that one of the big reasons that Ada never took over was because around 1990 I discovered that a mid-sized Ada compilation could fail on blatant syntax errors, but take longer doing so than it would take for me to do a complete compile-and-build of a Fortran program on my 4MHz Z80A floppy-based system. Ada was ahead of its hardware. Java was just barely in time.

And of course, since then, Java has been expanded to cover extended I18N functionality, improved threading and I/O processing, and added syntactic sugar such as templating and lambas. that they were either not brave enough to carry over initially from C++ or outright stole from other language platforms.

And all this done in a very rigourous backwards-compatible environment, unlike some of the nightmares I had with Microsoft, where you'd design and build an app using the latest tech and a week later, the tech had been broken by new changes in the system paradigm.

100%.

In my talks I often say that the rise of Kubernetes correlates with the rise of NodeJS and Python.

Kubernetes is a workaround to the fact that you just can't write large applications with these platforms. It manages a lot of small ones. It also deals with their unreliability in a brute force way. Essentially, throwing PODs at the problem.

OS/2 made me really love Linux. I was supporting OS/2 and learning Linux at the same time and the things I appreciated about Linux were that it put all of its configuration in one place (/etc) and one format (text), and that its error messages often contained hints as to what might be wrong. Unlike "IEC141I - EROPT = ABE OR AN INVALID CODE", which was mainframe-ese for A) the tape drive is on fire or B) a COBOL programmer coded the wrong record length.

How much monitoring and optimisation a JVM should do is, of course, dependent on what its expected usages are and (of course!) the cost of implementing, debugging and maintaining it. I'm just excited that it's possible to do so many things.

Right now, vector processing and massively-parallel processing in general are of especial interest, but one of the advantages of a virtual environment is that it's easier to adapt to new concepts in general. Quantum computing, various non-von Neumann architectures, etc.

I still have scars from permgen memory and what it did to Tomcat webapps.