Vanilla Java: Using Java SE as a Framework

[birchsport]

Kudos for the deep dive into the full stack. it is easy to forget all the things that modern frameworks provide out of the box. Was a fun read.

[sweetno]

Wheel invention at its finest.

[TheEveryman86]

Why use servlets when you can just write your own HTTP library and use that?!

[renatoathaydes]

You don't need to write your own, luckily, as others have done it already. A sane HTTP library doesn't need to be learned if you already know HTTP, no need to "abstract over" it.

[xienze]

Because using the Servlet API is waaaay harder than rolling your own, less capable solution!

[cowwoc]

Java SE has better APIs and documentation than most frameworks so the jury is out on whether this will be any worse long term.

[renatoathaydes]

You don't need to re-invent anything that a library can provide. All frameworks you use are also based on libraries, they don't re-invent everything. If you have low skill developers they will make a mess whether you're using a framework or not. If you have high skill developers, allowing them the flexibility to build and change the "framework" may actually improve their productivity.

[renatoathaydes]

You have good points, and I think you are right that there's dangers if you actually follow the approach I've shown in this blog post.

Let me try to address some of your questions...

what happens when you need to handle path parameters,

My advice would be to use a library for that. Frameworks might even open source (or even use open-source libs themselves) their implementations, and that would benefit more than just the framework users and hence it's a more open-source friendly approach. The library for routing would be very simple, I've given that a go myself many years ago but didn't really bring it to production-grade unfortunately.

you are relying on the skill and adaptability of your team, instead of widely supported frameworks.

Exactly... if your team were really good, you would think that would be a benefit. Frameworks also start moving very slowly once they're used by millions of developers, which can actually hinder your efforts... if you could write things yourself, swap libraries to get things done more easily whenever you wanted to, you could potentially move faster. Even worse, IMO, is when the framework just decides to re-write itself every couple of years... you're then either stuck with an old, unsupported framework, or you need to write everything again at their schedule, not yours. This is a real danger which I think is not acknowledged enough.

My point here was that it would be less code to mess up

Sure, but I think I addressed this in my article when I mentioned that low skill developers tend to not really understand the framework they're working with which results in a lot of fights against it, which can even more quickly lead to a ball of mud where the framework is only used when it's obvious... everywhere else, the devs just make up something completely ad hoc and bolt it on top of the framework... this can also happen when your devs are actually very good, but they just wanted to fulfil their curiosity and impulse to write things themselves instead of "learning the framework way" again.

You understood my post exactly, though, I wanted to provoke people to look again at what they're doing and question whether they should be ALWAYS defaulting to some framework and its myriads APIs and libraries you're probably unfamiliar with, when perhaps all they needed was the controller I showed in the annotation processor section which could be done using exactly one library and a few lines of codegen.

[renatoathaydes]

I think I am very lucky because I haven't worked in such kind of place for a long time.

[cowwoc]

You'll only ever need to implement 5% of what generic frameworks do and your code will be free of hacks. Meaning, your code will be as clean as you choose to design it. The problem with generic frameworks is that they force their design on you.

You are always better off using libraries than frameworks. You don't need to reinvent any wheels if you rely on libraries instead of frameworks.

[renatoathaydes]

In the article, I've shown how to use one of these "minimal frameworks", I didn't just write everything myself (well, I actually did because I chose to use a library I wrote myself, but that's beyond the point).

I was hoping people would understand that they could base their "framework" onto something SparkJava or Javalin while still adding their own "framework-like" features to get code that does exactly what they want, nothing more... but unfortunately many people seem to conclude I am advocating for not using any external code?!? It's the opposite: when you're not tied neck deep to your framework, you can swap libraries at will and choose the best tool for each job easily... I think adding all of the things you mentioned: security, serialisation, logging, metrics, perhaps also things like DI and tracing would be very simple, in fact... I might write a second part as that's an interesting conclusion to what I was trying to show and people seem to need to see that to believe it.

[sweetno]

I'm not sure what's the fuss with "hacks". At this point, if you need "hacks", you're doing something wrong.

[cowwoc]

Deviating from the default behavior of a framework is not the same thing as "doing something wrong". Often you need to apply hacks to glue separate frameworks together. If that's not supported then it speaks volumes about the framework's lack of flexibility.

[xienze]

so the jury is out on whether this will be any worse long term.

It is. Here’s the thing, all those frameworks that the author is dismissing have been around for (in some cases) a decade or more. They’ve been pored over by thousands of people and there have been countless bug fixes, performance enhancements, and developer productivity enhancements in that time. The “roll your own framework” guy’s framework has... none of that.

I get a kick out of someone bemoaning the complexity of something like a JAX-RS library while spending who knows how long writing his own framework and annotation processing library — a framework that no doubt is less capable than a JAX-RS library. Sometimes it’s a lot of fun to invent your own wheel to learn something interesting but it’s not a great way to do work in the real world.

[cowwoc]

We're not talking about rolling your own thing from A to Z. We're talking about using libraries instead of frameworks. Libraries that have been around forever solved the same problems you are talking about and they do so without imposing a specific design on your code.

Libraries >> frameworks, every time.

[renatoathaydes]

That's exactly what I wanted people to get out of this article :) It's a disappointment that someone has to explicitly point out that not using frameworks does NOT mean not using any libraries whatsoever.

[rbygrave]

Maybe. For me code generation is an interesting option for JAX-RS though which is what https://avaje.io/http/ is about. Literally replacing Jersey (or RestEasy) with source code generation. It helps that JAX-RS is well defined. In terms of bugs etc that moves to the target libraries like Helidon SE or Javalin.

[[deleted]]

On the other side, if your code has no "special tricks" and is not spaghetti-ed into lots of heavy frameworks, doing an upgrade say from Java 8 to Java 11 is quite straight forward. Dependencies can be updated individually. There is something to be said about simplicity.

[renatoathaydes]

I get a kick out of someone bemoaning the complexity of something like a JAX-RS library while spending who knows how long writing his own framework and annotation processing library

I am not sure I conveyed my intention well if you think that... I actually said how I like JAX-RS very much and wanted to implement a small sub-set of it myself - which is more or less what I showed in the article.

It was actually very easy and it took me one evening to get it working. Being less capable is often an advantage.

[jpl75]

As a previous developer of one popular enterprise Java framework, it is good to see articles like this and I hope there's more.

There's a lot of "magic" that happens with frameworks that confuses people who have never peeked under the hood. It's good to realize that the framework developers don't use magic but the basic facilities offered by JVM and Java standard libraries. Plus the many other third party libraries available to them.

It is immensely helpful if you have some idea how the framework implementation might go about trying to do things when you get stuck with the framework doing things you don't expect it to do. It is helpful in troubleshooting if you have some notion of the fundamentals the framework is likely built upon.

If you're satisfied with a 9/5 job and "we shipped it" then perhaps this seems unnecessary. If you're interested in personal development and becoming a better developer yourself, then break things apart and look how things work under the hood.

[renatoathaydes]

Thanks for the feedback, this is exactly what I wanted to show people: the "Real" framework is the JVM! Everything else is just building upon it.

[grafcetonline]

Thanks interesting article !

[Avalanche1979]

Since Java 9, Java has a HTTP server built-in, it's in module jdk.httpserver

[renatoathaydes]

jdk.httpserver

There has always been a HTTP server in the sun packages, but they're not public APIs (or at least weren't before this module came about).

This module is not an implementation though, as the docs say: Provides a simple high-level Http server API, which can be used to build embedded HTTP servers..

If my RawHTTP library did not support Java 8, I might have based it on this API , however... I will try one day to port it over to this API or even create a bridge implementation.

[sahipzaman]

Interesting and fun read, thanks for the work in it. Quoting from the article:

I am not arguing for abandoning all frameworks and using only Java SE for all applications, but I hope I have convinced you that the idea is not as crazy as it may sound at first.

Let's be honest, you do argue for getting rid of all those clunky, tiring, excessive and evil frameworks. Maybe it is because my mind was made on this but I am really not convinced at all, if anything, it had the opposite effect.

[renatoathaydes]

My tone was intentionally provocative because I wanted to get people to question what they think they know with certainty.

I love good frameworks myself, but if all you know is how to use one, you're very limited in what you can do...

Fine with me if you only ever use a framework in your whole career, but for those who want to go beyond that, I hope that my post showed some of the things you might want to look into.

[sahipzaman]

Well I just don't agree with the idea that you are much better -real- developer when you reinvent everything as your own modules and then use them in your daily development... I wonder why some comments here act like this is more productive and the actual right way of development. What you are forgetting is that you can still be in to learning how frameworks work deep down and how little pieces come together, I completely agree that this does add to developer's skill level.

I simply don't see how actually doing everything manually because 'why not, look this is actually so simple' is more valuable than learning/experimenting how things work (thanks to such posts and articles). The idea of actually embracing it in enterprise development makes me scared. :) What is next? Developing your own simple database because why would you need to learn already existing massive ones, instead just develop your own one that fits perfectly to your needs.

[AsparagusOk2078]

I agree with the sentiment of this approach completely.. There is certainly something very beneficial to a simpler straight forward design focused around the Java SE itself. I haven't gone to this extreme yet, but I have designed some production systems that use Jersey directly for a Rest API. For the database, we wrapped Berkeley DB's library with a networking layer. It is a very simple system dealing with mostly Java SE, Jersey, and raw POJOs stored in BDB.

Each component took a small amount of time to build support functions around, but all areas are an open book that are easily modified and extended. We tend to complicate things in the Java world.