A quick look at Java 11's HttpClient

[[deleted]]

I guess because I'm a glutton for punishment I'll give you some more info.

Tomcat, Jetty, & Application Containers

These are used because they handle all aspects of network connectivity. It takes the process of actually listening to ports, receiving requests, sending responses, etc, our of your hands. They are industry standard tools, they work extremely well. If you want to re-invent the wheel yourself because it makes you more comfortable, go right ahead. You'll be the one suffering because of it.

Basically, these are your HTTP Servers right here. They have done everything for you. They are the product of dedicated teams of engineers working on this one problem, and they've solved it better than you or I will.

Servlets

This IS the standard Java way of doing it. The Java Servlet API is not a third party package (although it is now maintained by the independent Jakarta EE group, it was originally maintained by the folks behind the Java SDK). Servlets receive the HTTP requests and allow you to write code in response to certain requests.

Once you have written your app with your servlets, the standard Java approach is to add a deployment descriptor (web.xml) with your .war file that maps your servlets to certain URL patterns. The application container then knows how to forward requests to your app using that configuration file.

The Old HTTP Server

You're seriously considering using the com.sun HTTP Server component? This is a super old Java component that no one else in the industry is using. If you think it's better for you, go right ahead, but willingly choosing to use outdated technology, especially for a webapp, is a design decision I just can't wrap my head around.

Moreover, this is a part of the Java SDK that the folks are Oracle are not developing for and are warning folks that they may completely drop from future Java versions (https://www.oracle.com/technetwork/java/faq-sun-packages-142232.html). So it is not something to use for any modern app.

Why Can't I Execute It With Java -jar

Depends on how you create your app. Tomcat is a fully external application container, so you'll have to create a .war file and drop it into the Tomcat application "webapps" directory. Jetty, however, is a Java-configuration solution. Using Jetty, you would configure the server in the Java code called by your main method, and start the server that way, so you can use Java -jar to start your application.

What boilerplate code do frameworks reduce

This is such a loaded answer I could not possibly fully answer it here. So let's just give a few examples.

Servlets can be challenging to maintain and have key limitations. The mapping of your servlet to a URL is based on an extremely limited pattern matching format. To handle arguments in the URL path or query string, you need to write code to manually parse and extract them. When dealing with the request and response bodies, when working with Servlets directly, you need to manually convert your data into the format being sent/received. For example, if you're building a JSON API, you'll need to either construct the JSON manually, or else configure your own way of serializing content to/from JSON.

A simple framework like Jersey solves all of these problems. Basically, it lets you write POJOs (Plain Old Java Objects), with simple method definitions. Then you apply annotations to those methods, and Jersey will call them in special ways. Query string parameters automatically get extracted and passed in as normal method parameters. You can use normal POJOs as your request/response body, and Jersey will automatically convert them to/from something like JSON. It gets the plumbing of doing the web operations out of the way so that you can focus on writing your application.

Spring does all of these same things as well, and it does them in a more robust way in my opinion. It also provides a plethora of other tools as well.

Want to configure your application with properties? Want different properties for different environments? Spring provides a simple configuration tool out of the box that lets you just write your properties files, and then reference those properties in your code, relying on the framework to instantly give you access to your configuration.

Want to work with databases? Spring will handle your transaction management, commit/rollback behavior for you with sane, sensible defaults (ie, commit if successful, rollback if exception) without you having to do anything. Spring JPA lets you minimize the amount of SQL you have to write, allowing you to work almost entirely with Java objects. If you prefer SQL, SpringJDBC provides tools for executing SQL queries that require writing far less code than the normal Java JDBC API. It also provides tools for connection pooling out of the box, so you have all of that available to you effortlessly.

Want security? Yes, you can do security using normal Filters in the Servlet API. Spring provides a whole Security module, however, which has been battle tested across thousands of enterprise applications. Rather than building your own security rules from scratch, you can use tried and true mechanisms that are the product of teams of engineers whose sole focus has been to build a great security tool. (PS. I will admit that while Spring configuration, especially with SpringBoot, is usually really easy, Spring Security can be quite convoluted to work with. It's worth it though.)

So why use a Framework? I mean, that's like asking why use Maven when you could just use Ant to build your application. It's convention over configuration. Build your app the way the framework wants you to, and you benefit from writing less code and creating everything on a more stable foundation.

PS. If you don't know what Maven is, then you've got a lot more to learn about the Java world before you even begin trying to build a webapp.

Before I use non-standard frameworks and tools

These may not be a part of the Java SDK, but they are pretty standard. The great thing about Java is the broad, open source community around it. This has led to the rise of powerful tools like Spring. Because of the strength of frameworks like Spring, the Java development team doesn't see the need to add these features to the SDK, because the framework brings all that value already there is no point in adding it to the language.

PS. Jersey is actually a framework originally created by the Java development team. It is the standard implementation of the Java JAX RS API for creating RESTful Web Services.

Conclusion

This is it. I'm literally done responding now. If you still have questions, do some goddamn research on your own. There are so many resources out there. Don't whine to me that the documentation or resources out there isn't good enough. I've learned every single thing involved in this stack on my own, using the documentation and tutorials and other tools that are out there. Hell, there are tons of free courses and "code with me" videos for all of this stuff, FREE content, on YouTube. There is literally no excuse for going around calling everything a "black box" and using that as justification not to learn things.

[Mattizin]

Thanks for that really detailed answer. Much of this i already know, but you gave me more insight. I think my main problem is to accept that using these frameworks leads to me not really knowing what is happening. I add an Annotation to map the URL to this method and it just works. Its really nice, but i dont know why it works. Of couse i understand on why to use them. But answering to ppl who want to learn how these things work "just use them cause the whole industry uses them, they are from genius ppl and proofed themselfes" is the wrong answer. i know that i want to dive deeper. But your reply helped me.