3 ms·

I appreciate the reply, thanks! Perhaps I will try to use vanilla servlets for one of my personal projects. I'll have to start reading the docs!

by Slaul 9y ago

agentgt 9y ago
I have to agree with parent heavily and I used to be a long time Spring advocate since version 1.0. The thing you will find using Java for a long time at any company is you eventually end up with your own framework / stack.... Yeah sure there is some underlying DI or Web framework but a majority of it becomes your framework and workarounds/plugins/extensions for whatever DI/Framework you choose. I used to to think this was a terrible thing but these days I think using less dependencies, autoconfigure magic, and even using older technologies such as the Servlet API are just easier to maintain, understand, debug, stable and surprisingly easier to train new folks on.
- eropple 9y ago
  > The thing you will find using Java for a long time at any company is you eventually end up with your own framework / stack.... Yeah sure there is some underlying DI or Web framework but a majority of it becomes your framework and workarounds/plugins/extensions for whatever DI/Framework you choose. This doesn't match my experience at all. Only really ossified organizations get to this state, even in Java-land. The amount of abstraction I have needed to put on top of Dropwizard in order to do literally everything I've ever needed, from websockets to web pages to file service. The underlying Jersey and HK2 system is simple, well-documented, and straightforward when I've needed to extend it, but these extensions are restricted in scope and easily testable to boot. I see no benefit, in 2017, to using servlets directly. It's certainly not going to be easier to teach a new hire through look-at-the-code or look-at-our-minimal-doc instead of pointing them at the existing documentation and examples of best-in-breed tooling.
  - agentgt 9y ago
    I think you may have misunderstood me a little. I'm not saying go use the Servlet API directly all the time but you damn well should know it since almost all the others build on top of it (including most of Jersey). Particularly Servlet Filters. It seems like every framework has their own take on onion processing a request but servlet filters are actually easier to write then say some Spring framework "Advise". As for Dropwizard... You do know its built on top of all the new JEE stuff like JAX-RS. I am willing to wager it will die and be replaced with something else... but those underlying javax specification stuff (like JAX-RS, servlet api, etc) are still going to be around. You should know those underlying standard APIs. The funny thing about you mentioning Dropwizard is it basically started as someones else stack built by mixing standard libraries.... something companies do all the time. > I see no benefit, in 2017, to using servlets directly. It's certainly not going to be easier to teach a new hire through look-at-the-code or look-at-our-minimal-doc instead of pointing them at the existing documentation and examples of best-in-breed tooling. Until shit breaks, or doesn't fit your exact requirements or the project dies, etc, etc, etc and believe me it does happen in which case you will need to know the lower level stuff. But yeah don't reinvent the wheel.
    - rhubarbcustard 9y ago
      > "Until shit breaks, or doesn't fit your exact requirements or the project dies, etc, etc, etc and believe me it does happen in which case you will need to know the lower level stuff. But yeah don't reinvent the wheel." This.
eropple 9y ago
I wouldn't suggest this sort of self-damage; I've been there and I've made the mistakes. Servlets, as written, are lousy abstractions for HTTP. Worse, where the abstraction breaks to expose HTTP to you, it doesn't really do much in the way of enabling you to do anything you couldn't before. If you want to use the JVM, one: use Kotlin over Java, it is a strict superset and a better development experience across the board. Two: evaluate something like Dropwizard (or even Spring Boot) well before you go near servlets. JAX-RS is not perfect, but it's a lot better than whatever you will home-roll. (Again, been there.)

I appreciate the reply, thanks! Perhaps I will try to use vanilla servlets for one of my personal projects. I'll have to start reading the docs!

by Slaul 9y ago

I appreciate the reply, thanks! Perhaps I will try to use vanilla servlets for one of my personal projects. I'll have to start reading the docs!

agentgt 9y ago

I have to agree with parent heavily and I used to be a long time Spring advocate since version 1.0. The thing you will find using Java for a long time at any company is you eventually end up with your own framework / stack.... Yeah sure there is some underlying DI or Web framework but a majority of it becomes your framework and workarounds/plugins/extensions for whatever DI/Framework you choose. I used to to think this was a terrible thing but these days I think using less dependencies, autoconfigure magic, and even using older technologies such as the Servlet API are just easier to maintain, understand, debug, stable and surprisingly easier to train new folks on.

eropple 9y ago
> The thing you will find using Java for a long time at any company is you eventually end up with your own framework / stack.... Yeah sure there is some underlying DI or Web framework but a majority of it becomes your framework and workarounds/plugins/extensions for whatever DI/Framework you choose. This doesn't match my experience at all. Only really ossified organizations get to this state, even in Java-land. The amount of abstraction I have needed to put on top of Dropwizard in order to do literally everything I've ever needed, from websockets to web pages to file service. The underlying Jersey and HK2 system is simple, well-documented, and straightforward when I've needed to extend it, but these extensions are restricted in scope and easily testable to boot. I see no benefit, in 2017, to using servlets directly. It's certainly not going to be easier to teach a new hire through look-at-the-code or look-at-our-minimal-doc instead of pointing them at the existing documentation and examples of best-in-breed tooling.
- agentgt 9y ago
  I think you may have misunderstood me a little. I'm not saying go use the Servlet API directly all the time but you damn well should know it since almost all the others build on top of it (including most of Jersey). Particularly Servlet Filters. It seems like every framework has their own take on onion processing a request but servlet filters are actually easier to write then say some Spring framework "Advise". As for Dropwizard... You do know its built on top of all the new JEE stuff like JAX-RS. I am willing to wager it will die and be replaced with something else... but those underlying javax specification stuff (like JAX-RS, servlet api, etc) are still going to be around. You should know those underlying standard APIs. The funny thing about you mentioning Dropwizard is it basically started as someones else stack built by mixing standard libraries.... something companies do all the time. > I see no benefit, in 2017, to using servlets directly. It's certainly not going to be easier to teach a new hire through look-at-the-code or look-at-our-minimal-doc instead of pointing them at the existing documentation and examples of best-in-breed tooling. Until shit breaks, or doesn't fit your exact requirements or the project dies, etc, etc, etc and believe me it does happen in which case you will need to know the lower level stuff. But yeah don't reinvent the wheel.
  - rhubarbcustard 9y ago
    > "Until shit breaks, or doesn't fit your exact requirements or the project dies, etc, etc, etc and believe me it does happen in which case you will need to know the lower level stuff. But yeah don't reinvent the wheel." This.

eropple 9y ago

I wouldn't suggest this sort of self-damage; I've been there and I've made the mistakes. Servlets, as written, are lousy abstractions for HTTP. Worse, where the abstraction breaks to expose HTTP to you, it doesn't really do much in the way of enabling you to do anything you couldn't before. If you want to use the JVM, one: use Kotlin over Java, it is a strict superset and a better development experience across the board. Two: evaluate something like Dropwizard (or even Spring Boot) well before you go near servlets. JAX-RS is not perfect, but it's a lot better than whatever you will home-roll. (Again, been there.)