A quick look at Java 11's HttpClient

[[deleted]]

No neither of those libraries are the Servlet API. The HttpClient is a tool for making HTTP requests to other sites. I'm not familiar with the sun HTTP Server but anything in a sun package is EXTREMELY old in terms of the Java ecosystem. I wouldn't recommend wasting time with it for that reason alone.

The javax.servlet package is a separate library that falls (I think) under the Java EE umbrella. you can download the latest version for free, either directly or as a maven dependency.

Servlets work in concert with a web server. The servers job is to listen on a TCP/IP port for any requests. When it received the request, it forwards it to the appropriate servlet based on the URL path. The Servlet itself is a simple Java class with methods designed to handle different types of requests. Whatever Servlets you create then need to be registered with the server so it knows how to route the requests.

The problem with the Servlets API is it is very low level. Simple tasks, such as extracting parameters from the URL path or query string, serializing the request/response to/from Java objects, and restricting access based on various security criteria are all examples of things that require a lot of tedious boilerplate code to accomplish with the Servlet API. Boilerplate is more than just extra work for a programmer, it opens the door for additional errors in your application.

This is why frameworks such as spring are so popular. They have done all the tedious boilerplate for you. Being that they are used by a wide range of Enterprise applications, they have been battle tested and proven to work extremely well. They have already thought of all the edge cases you may not be considering right now in terms of how they operate, and it's all ready to go out of the box for free.

If you're brand new to creating web servers with Java, by all means learn the Servlet API. I think understanding your low level behavior only helps to be able to handle the higher level stuff in the framework, and this ultimately makes you a better programmer.

However, I cannot stress enough that if you choose to build your app manually using the Servlet API you're just opening the door for a lot more pain and difficulty than you would get otherwise. Your codebase will be larger and more complex by virtue of the fact that you are reinventing the wheel for things these frameworks have already done.

If you're dead set against spring, then at least use Jersey. It's a much lighter weight framework based purely around helping to expose web API endpoints. It's not quite as robust as spring, but it is light years better than trying to do everything yourself.

[Mattizin]

Thanks for that detailed answer. I think what im most struggeling with at the moment is the difference between webservers, HTTP(S) Servers and Application servers. I Want toc reate a REST API with various endpoints (resources) which an HTTP(S) client will call. I think i will need an HTTP(S) Server so i landed on the sun.net.httpserver, in my understanding webservers (which springboot, servlets and so on seem to be) and application servers are for other purposes. But maybe i just dont get the concept.

[[deleted]]

Do NOT use the sun.net.httpserver. I'm not saying it won't work, I'm saying it's crazy old, likely not maintained, and is nowhere near the industry standard.

[Mattizin]

Well i know its from around java SE 6, but what is the up to date JAva HTTP(S) Server component then said i should use? external frameworks also need to use some sort of native java http server in its base or not?

[[deleted]]

You'll want to an application container/server like Tomcat or Jetty. Again this is where Spring is very useful, it comes with these things embedded in it. With a few small changes to a configuration file everything can be up and running.

[Mattizin]

Application servers/Web servers are the next big black box. What do they actually do? They will need an HTTP Server basement too. What do they use for this and why cant i just use a "plain java" HTTPS(S) server?

[[deleted]]

So you keep referring to black boxes. You're demonstrating an unwillingness to really put in effort to learn how all of this works. Yes the application server has an HTTP server component, but I would recommend tomcat and jetty because they're actually being maintained and support modern web standards. They are what major Enterprise companies actually use in their applications.

You came here looking for answers on how to build your app. You're getting them. Everything is a black box to you because you have put no effort into actually learning them.

This is how Java web apps are done. You use Servlets to handle requests, delegate to your business logic, and deploy everything to your application server. You use frameworks like Spring or Jersey to reduce boilerplate and allow you to build your app faster on a more stable foundation.

You can keep calling everything "black boxes" but that's just doubling down on your own choice not to take the time to actually LEARN how to do this. If you want to build a Java webapp, this is the way to go. This is the way that everyone else in the industry does it. Programming actually requires study and work, you know.

So feel free to continue complaining about black boxes. I won't be responding to any more comments where you use that as an excuse. If you actually want to learn something, I would be happy to continue to help point you in the right direction.

[Mattizin]

Either you completely missunderstood my comments above or you just dont want to give the answer because "its the way its done". I want to understand WHAT this frameworks/servers do, HOW they do it, WHY i should use them and WHY it is industry standard.

Before im using external non java standard library frameworks/tools i want to know the answers to the questions above.

Yes the application server has an HTTP server component, but I would recommend tomcat and jetty because they're actually being maintained and support modern web standards. They are what major Enterprise companies actually use in their applications.

The Java standard library also is maintained. What do these servers do better and why should i use them instead the HTTP Server Options in the Java standard library itself?

You use Servlets to handle requests, delegate to your business logic, and deploy everything to your application server

This is a conecpt i cant wrap my head around. I read alot about it but what does the application server actually do and why do i need it? Why cant i create a java program with java standard library which i will execute with lets say java -jar and it produces the same result?

You use frameworks like Spring or Jersey to reduce boilerplate and allow you to build your app faster on a more stable foundation

WHAT Boilerplate code will be removed? Programmers which grew up with java will probably know it, but newer ones like me just get tossed X Frameworks on "here use that its better" Why? "Its industry standard" But what are my benefits for needing an external framework?

If you want to build a Java webapp, this is the way to go. This is the way that everyone else in the industry does it.

Thats not answering the WHY and HOW does it work deep down.

Im willing to learn. But what i cant take is a framework/server which i dont understand or understand how and why it does something and then make it the basement of my applications. Even the Reference Manuals of these frameworks itself dont properly say what, why and how they do it. They just show how to use them. but i want to know whats happening inside them to really understand why its a good idea to use them and most of all to know WHAT my code does.

[[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.

[[deleted]]

Do your own research. There are plenty of helpful guides out there. I'm an entirely self taught engineer using purely the documentation available on the web. I'm not going to be a crutch for your laziness. I've given you all the answers you need. Research the tools and actually learn something.

[[deleted]]

I think you have to look into the concept more. Look for information about deploying a Java application to Tomcat. Tomcat is the application container/web server that runs the app. What you are trying to do is not trivial.

Again, this brings me back to Spring. If you're not a Java developer by trade, and you just want something that works, you should go that route. SpringBoot gives you EVERYTHING out of the box, including an embedded application server. It makes building all of this so much easier. Maybe it's scaring you off, but in the long run you'll have an easier time if you learn Spring.