4 ms·
You're right but wrong. That's all OK in theory but not in reality having migrated various Java EE gubbins on a project. It's a rat's nest of supposed standards
by cssmoo 12y ago
You're right but wrong. That's all OK in theory but not in reality having migrated various Java EE gubbins on a project. It's a rat's nest of supposed standards and interop that doesn't amount to much at the end of the day because there's still coupling to infrastructure and configuration at every level. On top of that there's edge cases that the APIs and standards don't consider as they're all pretty leaky.
Dropfish is a cohesive "opinion in a box" that just works without having to do a Java EE iteration zero which is hours of eye-stabbing pain. Someone did all the hard work of swapping components out until they found something that wasn't horrible and stuck them all together.
The Java EE ecosystem is mature, you're right but it's not pleasant, is inflexible despite its modularity and doesn't live up to it's promoted abilities.
Saying that I've used both in production, but would rather can both of them and use something like flask and python with SQLAlchemy just for the fact I don't have to deal with massive heavyweight environments and it's possible for a human to understand it all in a lifetime.
Also, 500 level deeps stacks in Java+OSGI projects make me cry. Trac has a better composition and component model!
- dawidloubser 12y agoI've had some terrible experiences with migrating, and maintaining, Java EE apps before. But every single one of those were caused by how the teams built the system, and not by Java EE itself. The added complexity, and choices, imposed by Java EE require a degree of understanding, maturity, and ability to abstractly design that is beyond the average programmer that just quickly wants to hack together a couple of REST services. I'm not trying to paint successful Java EE developers as some sort of elite here, but there is no doubt that people with a solid understanding can, and have, built long-lasting systems of beauty with it, whereas the average un-informed team, having managed to soundly lock themselves into awful pre-2005 app servers, have created conterted messes of Java code beyond belief. Both Java EE, and OSGi, are soundly beautiful in their own ways, but both have suffered from some awful implementations and libraries that have caused a lot of pain. For the past 5 years, my experiences with Java EE has been everything but "heavyweight". I consider it a rapid application development environment. Especially now that nobody does any server-side view frameworks anymore (it's all ECMAScript in the browser). In this world, I challenge any environment to put more horsepower behind your REST services, for less effort.
- tokenizerrr 12y ago> For the past 5 years, my experiences with Java EE has been everything but "heavyweight". I consider it a rapid application development environment. Especially now that nobody does any server-side view frameworks anymore (it's all ECMAScript in the browser). Do you have any recommended reading for that? Every time I try to get started with Java EE I am plagued with outdated material and pages upon pages of boilerplate XML configuration.
- nbw-hn 12y agoCheck out the JavaEE tutorial from Oracle http://docs.oracle.com/javaee/7/tutorial/ http://docs.oracle.com/javaee/7/tutorial/ and the 1st Cup https://docs.oracle.com/javaee/7/firstcup/index.html https://docs.oracle.com/javaee/7/firstcup/index.html There's also an excellent GIT repo of JavaEE7 samples that is maintained by RedHat here: https://github.com/javaee-samples/javaee7-samples https://github.com/javaee-samples/javaee7-samples