Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developing and running a Java EE Hello World application

wiki.jetbrains.net

Post reply on HN
Print view View original

71–80 of 84 posts

Re: Developing and running a Java EE Hello World application

#73

Post by lmm »

lukaseder wrote: post #67
lmm wrote: post #30

Earlier quoted context omitted.

> I sincerely doubt that. I've seen E-Banking systems run on Jetty with JDBC directly. No fancy JSRs were needed. If you need distributed transactions (and sure, most people who think they do don't), you use the fancy JSRs or you will go out of business. That stuff is hard and it's the reason JEE is so horrible, but it solves problems you can't solve any other way.

Yep. I understand the use cases of JavaEE's JSRs. Yet, I personally don't see why I should install a complete 300MB application server (possibly with horrific licensing) just because I happen to need one of their JSRs in just one part of the application (that happens to need JMS because the customer's CIO was walked into buying expensive licenses from IBM), which is otherwise mostly just transforming data between the…

Making technical decisions for non-technical reasons is always bad, whether that's a decision to use a particular technology or a decision not to use a particular technology. I think many users do derive value from having an all-in-one platform that provides all the JSR implementations they need and they can then just forget about.

Re: Developing and running a Java EE Hello World application

#74

Post by assertnotnull »

Java main feature: fast on JVM, not on the dev. I've worked for 5 months to make a 4 pages - 3 grid & upload form using GWT, Spring, SOAP.. seriously?? It's a different stack but still it's overkill. You know what is the best part? our app is not even scaled. Why are we bothering then? Do we crunch tons of data to justify the need of a JVM? No. Is speed really a concern? It seems not.. I didn't even hear we are doing caching. It's only transform database beans to DTO and modify for display. Java is not a technical requirement here. It's just a lazy business standardisation solution.

To me It's like, the enterprise wants a flyswatter to kill a fly but you end up with a bazooka factory and the fly dies of age. But the bazooka factory is very efficient on the CPU. That's the important part you know..

Re: Developing and running a Java EE Hello World application

#75

Post by lmm »

realusername wrote: post #34

I've also done some JEE quite a long time ago and I hated every second of it. I'm not sure however if my experience is representative of the the Java community. There is no problem with the language itself nor the VM which is also working quite fine (while taking a lot of RAM). But I really have a problem with the community, everything seems over-engineered and super complicated in Java, even with simple things. Noth…

Maven is wonderful. It's the opposite of complicated. You declare the artifactId, "groupId" and version of your project. You declare those same values for your dependencies. And then it Just Works. When you want to release, you invoke the release plugin, and it will do all the right things. If you want a test coverage analysis, you invoke a suitable plugin (e.g. emma) and it'll do the right things. It is, hands down, the best build system I have ever used, in any language.

The problem comes because everyone thinks their build is a special snowflake that absolutely needs to replace every instance of the number 15 in their codebase with a heart symbol. No. You don't do that. If you're doing something standard there will be a plugin for it. If there isn't, it's probably because what you want to do is a very bad idea - do it in code instead. If you absolutely insist, you're going to have to write a plugin, which at least means you'll follow coding standards, have test coverage, and all the rest of it, rather than just sticking random unreviewed crap into your build like happens in every other build system.

Re: Developing and running a Java EE Hello World application

#77

Post by Delmania »

realusername wrote: post #34

I've also done some JEE quite a long time ago and I hated every second of it. I'm not sure however if my experience is representative of the the Java community. There is no problem with the language itself nor the VM which is also working quite fine (while taking a lot of RAM). But I really have a problem with the community, everything seems over-engineered and super complicated in Java, even with simple things. Noth…

Maven archetypes make Maven a lot easier to use, and the standardization of things such as JPA and CDI and the simplification of EJB has gone to lengths to reduce the complexity if JEE. That being said, this isn't a "Hello, World" app, but more of using "Hello World" to demonstrate how to set up the full JEE system.

Re: Developing and running a Java EE Hello World application

#78

Post by vorg »

konradb wrote: post #50
realusername wrote: post #34

I've also done some JEE quite a long time ago and I hated every second of it. I'm not sure however if my experience is representative of the the Java community. There is no problem with the language itself nor the VM which is also working quite fine (while taking a lot of RAM). But I really have a problem with the community, everything seems over-engineered and super complicated in Java, even with simple things. Noth…

> Maven is a nightmare to use, it's so complicated I would generally not use it. I would just like a package manager which is only doing packages like any other language. Before Maven, generally I remember there being Ant. And I remember that if an application needed dependencies, unless one explicitly used a dependency manager like ivy, one had to go find the jars and download them, and ensure they were on the class…

sbt, gradle, and leiningen each bring a better syntax to build scripts, viz their respective programming languages. They each pitch the ability to drop out of their declarative syntax when needed, but from the samples I've seen of gradle and leiningen use in open source projects this facility is rarely used. I guess it's because replacing procedural build code with declarative was the reason projects bought into Ant and Maven in the first place. In my opinion Gradle would do well to replace its Groovy DSL with its own lightweight one with a similar DSL and let developers use Java lambdas to do any procedural customization if it's ever required, just like they removed virtually every line of Groovy from their codebase for Gradle 2.0.

Re: Developing and running a Java EE Hello World application

#79

Post by vorg »

sesm wrote: post #40
thorin wrote: post #13

Earlier quoted context omitted.

Agreed. It's also possible to use frameworks such as Spring Data/Boot, Roo or Grails to get started really quickly - a bit like the django/rails crowd. Lots of interesting things happening in Java world at the moment. It seems like originally Java drew from the mega complex enterprise application world influenced by people building large scale C++ apps etc so were hardly aware of the complexity they were adding. Now…

The problem with Grails is, like you said, it focuses on getting started quickly, rather then producing a maintainable and performant codebase. I mean, Hibernate is very complex in itself, and adding another layer (GORM) on top of it won't make things better. If I were to start a new java project, I would probably choose Dropwizard ( http://dropwizard.io/ ), which is more a collection of libraries then a framework.

The business model of the Grails development has always been about integrating various existing software into one branded product for "full-stack" development, such as Groovy and Spring. The Spring and Grails crowds inside Vmware seem to do everything together now (e.g. SpringOne2GX conferences) so I suspect they're now already one group, and that it's the Grails project that's taken over Spring just like they previously took over Groovy.
Post reply on HN