JavaEE vs Spring

[kfrajer]

Kevin,
Can you comment what is the meaning of working with JavaEE and choosing something like Spring? I understand they are used for web technologies. Spring Boot seems to be easier to use. What are your thoughts about JavaEE? What about Jakarta EE?

I take the opportunity to share this performance talk that I thought is worth to share:

The Trouble with Memory with Kirk Pepperdine .

Finally, I learnt that Java SDK has officially forked about two years ago. For instance, there is AdoptOpenJDK which is fully supported by an UK community (don’t quote me on this). How do you see ppl learning these technologies in the future. Would there be a preference to learn one over another?

Kf

[Kevin]

JavaEE is a set of libraries and tools designed for creating Java servers.

Spring is a framework that runs on top of JavaEE.

I’ve used Spring, but IMHO it’s overkill for everything I’ve needed to do. I could see it being useful for a team of developers working on a full product, but I haven’t really needed it for my purposes. (Static Void Games was written in Spring, and it probably caused more headaches than it solved.)

If you want to explore frameworks, I’d personally start with Struts:

Struts

OpenJDK has been around for a while. From what I understand, from a developer’s perspective it’s not really much different from regular Java. The difference is in the underlying implementation. So it’s not like you have to learn one over the other. The difference is more important when you have to worry about licensing and deployment. (I’m not an expert so I could be getting that wrong, but that’s my understanding.)

[kfrajer]

Thanks for the insight. I think there is a lot of pain regarding transition to Java 9 and Java 11 and which Java to use. Probably for small projects is not such big deal to transition between SDKs. I will check struts. By the way, kudos for your GCP series.

Kf

[Kevin]

Heh thanks. Yeah apparently Java 9 contained a bunch of changes that broke backwards compatibility.

I’ve been learning that lesson over and over again as I’ve been putting together the Google Cloud tutorials. Right now App Engine only supports Java 8, so if you have a newer version of Java, lots of weird things happen.

[Philip]

Heyho Happy Coding,

though this topic has been dead for a year, Spring vs JavaEE comes up again and again, and I have a thought or two about it not covered in this discussion, to which I’d really like to hear other peoples opinion.

Spring is overkill for smaller projects

From one perspective, I fully support this statement. When choosing a framework, one should go by the software requirements and try to find a technology stack that meets these requirements on-spot. Too much and too little will cause headaches and extra amounts of work.

That said, I’m often in a different position towards such projects. For instance: I work in a team where ages ago people started with “just what’s needed”. I’m talking about a process that took upwards of fifteen years. They got stuck at some point, because their chosen stack didn’t grow easily. Adding new features and packages, or upgrading to newer versions, was too difficult for the resources (time, personnel, etc.) at hand. It’s not just the technical integration of new technology, it’s also the demand of new skills that come with them.

During my market-analysis, and whenever I dived into new technologies, I encountered the same advice: Start small. What those two words don’t say is: even if the tech-stack is an overkill.

Spring is a ‘magic’ toolbox

It has a ton of services running per default. Nevertheless, when a student and I tried to deploy a little MVC web-app, including a database, a server in the local network, user-authentication and CRUD functionality (with a minimum of design), we were done in a day. Mark we had no previous experience with Spring before that. I did the same in a .NET environment (desktop, web and mobile), and though the first few implementations took more time than seemed appropriate, it became easier over time until our implementations of new features were fast for the complexity involved. That worked out because at that point the project had grown, the framework was no longer overkill and we were accustomed to its features, knick-knacks and quirks.

I personally prefer this approach, because projects tend to grow over time. The more time you spent on them, the more ideas you and your customers will develop. Usually you’d want to use approaches like prototyping to field-test your ideas and explore what else could be useful for the business domain. But in my experience, the customers and even the developers unconsciously specialize on the tech-stack used for the prototype, making it harder to pick a different one afterwards.

But perhaps I’ve deluded myself. I am not immune to that. It worked for me because it is what worked best with the given circumstances of my team and customers. Nonetheless, to me it seems like a good general principle to start small with new frameworks like Spring, and not only look at the softwares requirements, but also at the experience and skills you as a developer, or your team in general, can gain from it.

Addendum

All that said, I should mention that I still wasn’t able to introduce Spring in my team.

In big projects you will encounter the difficulties of administrating, maintaining and supporting the software after or even at the first roll-out. Who will do it? What is the target infrastructure and its scale? What platforms exist? What kind of developers will be available? Who will do the administration and maintenance? These are questions for an enterprise-architect, but they may come up in “smaller” circumstances as well. In fact I have to consider some of these myself when choosing a tech-stack. However, in the case of JavaEE vs Spring, and in our situation, JavaEE has won out, because it’s more established and better known that Spring.

[Kevin]

Thanks @Philip! I definitely agree with everything you said, and I should also say that the advice I’d give to somebody starting out learning about server-side development is a little different from the advice I’d give to a team of 10 full-time engineers working on a team.

Another thing that occurred to me as I read your post is that my guess is it’s easier to convert a project that uses Java EE to Spring than it would be to go the other way around, just because Spring does so much for you. That means if you decide to use Spring now, you might be stuck with that later, whereas if you “start simple” you can still add the complexity later if you need it. I don’t know how convinced I am by my own argument, but it was what I thought when I read your post.

A lot of this comes down to personal preference anyway, so the best advice I can give anyone is to try everything: try Java EE, try Struts, try Spring, try anything else you can find. Write a hello world server in each, and see which one you like the best.

You can read as many opinions as you want, but in the end the only one that matters is yours (or your team’s, if you’re working with other people).

[Philip]

Thank you @Kevin!

Your reply makes a few things visible to me.

• You can get stuck both ways

  • IMO that indicates it’s not a technical problem, but, again, a human one

• I would always side with “start simple”.

• It’s easier to convert from JavaEE to Spring than the other way around

  • (I meant to ask you that next to confirm or negate my suspicion, but you’re a step ahead of me )

I need to elaborate this on my background, though this will go on for a bit. Please forgive me should I step over the limits of this topic in the process, it’s all still related to the JavaEE vs Spring question!

I am trying to apply all this directly to the situation I am working on at the moment. To tell the truth: It’s a company that does not work in the software industry, but needs individual software development in-house. In a nutshell: I can’t just do what I like, but I have to make choices about what’s best for whoever else is going to get in touch with my projects eventually. While I can’t ask those “whoevers” - we don’t have an enterprise-architecture yet to support such schemes.

In all this, I guess I underestimated my own progress. Two years ago, it was the simplest way to use a toolkit like Spring or .NET, where I can get the whole system out-of-the-box, and then start modifying it into what I need for the requirements.

Today, and building on your tutorials (I think I mentioned in another thread that I am starting from scratch on purpose), I realize I don’t need this approach anymore, though it still influenced my view about Spring.

In my situation, I am just now realizing that the technology is not solving the problem. I pick Java because the people “in reach” are mostly familiar with this language (as opposed to c# and PHP). But what I really need to come up with is an architectural solution.

Here’s were I’m going :

I need systems with user authentication in a web-environment who will read and write data. There will be a notification system within the app and per e-mail. The UX has to be convincing, but that’s my least concern. The data comes from various sql databases (oracle, mysql, mssql) which switch structure and systems sometimes. I can’t use frameworks outside of JavaEE, so I have to come up with an OR-Mapping that is at best pluggable, at least modular. And in between web-ux and db-or-mapping sits my business-logic, which needs to be some sort of RESTful microservice.

With the help of your tutorials and this conversation, I think I begin to see a way through all this. We don’t know where our systems will eventually be deployed. Usually I’d be happy with a RESTful-API, but for this unknown variable I want to go a step further and make a microservice that is deployable in a VM or a docker container. I’ve looked into java web sockets for this, but assume a standalone java server like tomcat for that container/vm would do the trick as well.

The microservice is giving me headaches at the moment, because I haven’t figured out yet how or-mapping works in java when I’m not able to use hibernate, and as indicated above, I need to evaluate how far I can or should go to make the whole DAL modular and exchangeable. With a minimum of coding, or none at all. The microservice would be a combination of said DAL and business-logic, providing the API over http.

Thanks goodness we are talking web-app, so at least the view/ui (client-side) is secured by HTTP standards - I don’t crack my head about this one.

I am not sure if I was able to bring across my situation as clearly as necessary, so if there are any more questions: please ask!

closure and questions

All the frameworks are not out of question per-se, my company just “strongly discourages” them. I have to talk systems, because my customers don’t really know yet what they need from the software; we need software to figure out what we need, so requirements and software-solution have to develop synchronous with the business processes my bosses are trying to implement. I have to accept that a default architecture for how to do DAL, business-logic and web-client is my best option.

What is the simplest way to accomplish that?

Personally I begin to fancy the idea of java apps like what I saw here at oracle. The problem then would be the protocol between publisher and subscriber. Suppose my DAL is the publisher for the REST-API, then anyone who’d want to “plug in” a new db needs to know this protocol and work according to it. Should I use messaging? Or URL-sockets (to make the DAL itself a RESTful API)? Is there some other way I am not even aware of? I know I tend to make things more complicated than necessary. (even posts…)

My projects run the “risk” of being outsourced at some point. That kinda dictates to use JavaEE to make frameworks like spring and hibernate optional instead of dictating them to whoever has to pick the people / companies for outsourcing. But since I have to get started with this all on my own, the simplest solution has to be preferred. So if Spring, Struts or whatever else saves me a month or six of work, I really should use that.

However, I need to see all perspectives before I can take a step.

Thanks so much for helping me out with this!

[Kevin]

Wow, that sounds like a big job. I’m not sure I’m going to be able to give you great advice, and it sounds like you already know your context way better than I do.

So I’ll just focus on one thing that I think will apply no matter what: the best thing I can suggest is to try a bunch of different things out, and see what makes the most sense to you. Spend a couple days putting together a “hello world” server in each of the options you’re thinking about using, and then evaluate how you feel about each one.

I’ll also ask a question:

I need systems with user authentication in a web-environment who will read and write data. There will be a notification system within the app and per e-mail. The UX has to be convincing, but that’s my least concern. The data comes from various sql databases (oracle, mysql, mssql) which switch structure and systems sometimes. I can’t use frameworks outside of JavaEE, so I have to come up with an OR-Mapping that is at best pluggable, at least modular. And in between web-ux and db-or-mapping sits my business-logic, which needs to be some sort of RESTful microservice.

How much of this do you need right now versus how much of this do you think you’ll need a year from now? In other words, what does your minimum viable product need?

It’s good to be forward-thinking, but it’s also important to avoid feature creep. I would focus on what you need now instead of worrying about stuff you might need in the future.

Of course, all of that is just my two cents. I’m not exactly a professional expert in this stuff. I can put together a website for my own personal use, and I work as a software engineer, but what you’ve described would typically be handled by a whole team of people who specialize in different parts of it. So the best I can say is to focus on the parts you know you need right now, and figure out the rest later.

Good luck! Keep us posted!

[Philip]

Thanks for the feedback and insights, those “two cents” will do a lot for my not losing my head in all that. Because here at work is where I made my first steps as a coder ever some five years ago, it’s hard for me to tell how big or small everything really is. I’m used to and also limited by knowing how things run here, exclusively. So, in a human way, it’s good to have such feedback from time to time, too.

After my post I looked back at your first answer, and realized there was already a major advice to my situation, which you mentioned again:

Create a Hello World Server in each of the options.

I will allocate time to do that.

Thanks for reminding me of the MVP and avoidance of feature creep. These are important to me, but I’m prone to “getting creative”, and suddenly there’s more than the MVP. (Or a beautiful solution that does nothing for the problem. )

As Andy Hunt said: Everything is Code. You helped me identify the risk of feature creep and gave me a reminder to define the MVP. Since requirements and architecture designs are text, and text is code, I’ll do a TDD approach. Meaning I’ll use the MVP to frame and restrict my evaluation process. Not a Definition of Done, but something to test every scrap if it does what I need and only what I need.

I will put the features I’ve listed on a timetable, dividing them by “now” and “later”.

With all that at hands, I can put the “Hello World”-Server test to unfold its full potential.

---

This certainly went way off topic, but I’m grateful for the excursion.

It’s good to talk to someone about these things, so I might indeed come back to Happy Coding with my ideas and evaluations. But perhaps in a separated thread next time around.

[Kevin]

All of that makes perfect sense. And yeah it definitely helps to have somebody to talk to!

I’d love to hear more about what you end up deciding!

[Philip]

Since you asked so nicely:

I’ve decided to create a documentation of Architecture Guidelines, targeting the idea of a minimalistic Java EE Tech-Stack. These guidelines are now my simulation of the enterprise architecture I’m missing so badly. Whenever I get new insights into what business or infrastructural restrictions we have, I can update these guidelines and start working on my projects from there.

It’s like my very own anti-corruption layer, but on the level of company communication.

It’s grown into a 14 page monstrum, and still isn’t even done yet. I wish I could show you, but it’s in German and probably not conform with compliance, even if I remove all indications of what decisions point to which end of our organization.

Within this document, I’ve divided these sections:

• Database / Data-Sources

• Data Access and Sanitation

• Business Logic (WebAPI)

• Presentation Logic (WebSite/GUI)

Because I’ve decided to go as modular as possible, I outlined each of these parts as a Subsystem.

It took weeks of work, but in the end I got a wholesome concept on a very high abstraction level. It describes dependencies, concerns, risks and chances with each layer. It is also naming the most important standards and patterns for this or that layer, supposing a Java EE implementation.

This gave me a foundation to base my Project decisions on, and a guideline to recognize and cut tasks into comprehensive chunks, either for my own planning or for my trainee developers. I don’t have to visualize all the risks and dependencies in a big monolith anymore, which is a huge advantage.

Although it targets a Java EE implementation, it’s also too abstract to be considered “strongly typed”. As you said, it’s easy enough to upgrade from Java EE to any framework. It’s that thought in particular I implemented into my architecture: Keep things simple and “basic”, as to allow for future sophistication.

So… who’s won?

I feel I should be more clear about how this connects to the topic.

In the beginning, there was a choice to be made. Java EE vs Spring vs Struts vs You-Name-It. Which way to go?

Because I’m in an abstract situation, with future projects generally ahead of me, I need a more abstract, general approach to the question of tech.

My above mentioned guidelines provide this:
Whenever I face a new project, I begin plain and simple, and with Java EE. My customers, the stakeholders and I become more familiar with the project, and as we do, we better understand what tech we need. Since most frameworks build on Java EE, the extra effort to implement a framework later in the development process is acceptable, while the decision can be backed with real experience.