141–150 of 213 posts
I don't see how this question is answerable in any meaningful way in its current form. You're going to get a list of basically every JVM framework there is, and you speak nothing of your front-end requirements.
Probably playframework [1] or maybe Spark [2] if it's a really simple app, along with jOOQ for persistence [3]. If I was just writing a REST API, then Dropwizard [4]. The reason I would not choose Spring despite the fact that it is better now than it was 10 years ago is because it still approaches things with the wrong mindset, IMO. The reason JVM technologies are so loathed is because of the stupid, pointless comple…
I really like annotations. And I really enjoy working on JavaEE. For anyone who still thinks it means loads and loads of boilerplate code but wants to check, read Adam Bien, check out the TomEE examples, the Wildfly examples etc.
To reduce even more boiler-plate, I've recently started using project Lombok [1]. Code generation provides all the standard methods and allows JPA @Entity objects or JAX-B objects to be completely declarative. Start with @Data and @Value.
First of all, I have to agree with dommer. You pick the stack depending on the use case. That being said, in most use cases I've encountered I would've gone with a REST API on the server for CRUD operations and an SPA framework on the UI side. I've found that the use of a classical UI Framework like Play, Grails or JSF make seperation of UI and business logic harder, rather than easier. Especially Grails is a huge ve…
Often, choosing a JVM language does not lock you into that language, as there's good interoperability. Be prepared that the first choice of language for a project might not be the best choice.
In response to the question, Java, Spring, Hibernate, and Postgres have served me well on a variety of projects. However, you need to take it with a grain of salt -- my needs will likely be different to your needs, and my skill set is almost certainly different.
Probably playframework [1] or maybe Spark [2] if it's a really simple app, along with jOOQ for persistence [3]. If I was just writing a REST API, then Dropwizard [4]. The reason I would not choose Spring despite the fact that it is better now than it was 10 years ago is because it still approaches things with the wrong mindset, IMO. The reason JVM technologies are so loathed is because of the stupid, pointless comple…
+1 for Dropwizard. Setting up Dropwizard was a breathe of fresh air in the Java world. If you can swing it for your project, I would suggest trying to sidestep ORM altogether by using a NoSQL database like MongoDB.
Probably playframework [1] or maybe Spark [2] if it's a really simple app, along with jOOQ for persistence [3]. If I was just writing a REST API, then Dropwizard [4]. The reason I would not choose Spring despite the fact that it is better now than it was 10 years ago is because it still approaches things with the wrong mindset, IMO. The reason JVM technologies are so loathed is because of the stupid, pointless comple…
I really like annotations. And I really enjoy working on JavaEE. For anyone who still thinks it means loads and loads of boilerplate code but wants to check, read Adam Bien, check out the TomEE examples, the Wildfly examples etc.