Abandon fish! Leaving GlassFish for TomEE or JBoss | Hacker News Reader

Abandon fish! Leaving GlassFish for TomEE or JBoss

zeroturnaround.com

37 pointstheotown25 comments

I am a little surprised to see an article like this on HN. I wouldn't have thought the kind of person who reads HN uses anything as fusty as a Java EE application server.

Am i mistaken? How many of us are using Java EE? Is it just those of us who are toiling away in the code mines of megacorps? Or are some of us using Java EE in cool and exciting startups?

I'll bet a lot of startups are using parts of it.

Servlets and JPA are both part of Java EE, and I've worked at a startup that used at least those parts of the EE stack. Any startup that uses Grails is using Java EE, albeit indirectly.

>Is it just those of us who are toiling away in the code mines of megacorps?

Code miner here, can confirm we operate Java EE servers but I have never known anyone to use Glassfish, its always that bundled server I download yet never use. We use mostly weblogic and tomcat, there may be a few JBoss app servers somewhere too.

Clojure's Immutant is built on top of JBoss so you are indirectly using Java EE there too.

And there's TorqueBox for Ruby on or off Rails:

http://torquebox.org/

speaking of ruby-off-rails, you may be interested in crudzilla.com, a web app platform for the jvm.

Articles about Java don't usually do well on HN, and something about Glassfish (which never had any significant adoption whatsoever) getting any votes surprises me. I've run a JUG fir 14 years, and most of my membership these days is from larger companies. The startup crowd is a small minority now, but years ago was at least 50% of my membership.

Some of us toil away in the mines using Java EE (and even Glassfish in production, in my case) but read HN because we dream of a better life.

I'm startups, and dream of the opposite.

The grass is always greener, etc.

This was one of the advantages of the old IBM mainframe ecosystem: there was only one shade of green, and that was blue.

My small experience from working with startups was that a LOT of java EE was used. This most likely came from them needing cheap labor, and many programmers fresh from school only knew java. I don't know if those startups qualified as 'cool and exciting' though.

I would guess that your startup experience wasn't all that recent? I'd say Java has been somewhat out of favor with most startups, at least in my area, for at least the past 5-7 years.

It was about 2-4 years ago. However, I was only in touch with a handful of companies. Still, my experience is that the continuous strength of java is that "everybody" knows it. Especially if the founder is not from a technical background, I think it is easy for a company to get stuck with programmers that only knows java.

I'm still toiling away in the mines, but when my current contract runs out next month Java EE I expect will still be invaluable. (Wildfly, not Glassfish though).

I used it extensively, I wrote a suite of web based tools for an MMO with GF 3.12, at the time I started writing I had good familiarity with Java, but none-with J2EE technologies, REST, JSON etc. Whilst I implemented what I set out to do, when the time came to implement a significant ammount of new features, one thing that amazed me was the labyrinth of code that I'd had to create (beans, resources, factories, abstract base classes) - and how quickly it was becoming a major chore to change the trivialest of things. Also I made the unfortunate mistake of using JavaDB/Derby as the datastore, thinking I had no need for a full RDBMS, I'll never make that mistake again, it's the most pathetic excuse for a db ever (I've used Oracle, MSSQL, Sybase, MySQL and Sqlite in the past, so I have some perspective on the matter)

So I began looking for alternatives, as a result v2 is written in Python (Flask/REST producing JSON, a simple wrapper around TornDB querying a MySQL db) which is consumed and presented by the Javascript/HTML front end using AngularJS. I re-implemented everything V1 had from scratch in under three days and was ready to begin adding the new features. By comparison the initial implementation in Java had taken me several weeks. Obviously some of that is to be expected, its easier to re-write than write. But I come away now feeling that Java & Glassfish made me jump through hoops to accomplish something that should have been simple, and I was certainly guilty of chosing the wrong tool for the job, but Java was what I knew best at the time.

To add to that, my background before the scenario I describe was as a developer in the banking industry, where Java/J2EE is used very widely and potentially justified for the complexity of the projects.

> how quickly it was becoming a major chore to change the trivialest of things

This was more than likely just bad design on your part. GlassFish 3.12 support Java EE 6 which supports a lot of POJO based development - between your mention of abstract base classes, factories, and J2EE (which became Java EE over 8 years ago) I have to wonder if you used a lot of legacy APIs and design patterns.

> Also I made the unfortunate mistake of using JavaDB/Derby as the datastore

Derby is neat for an portable in-process relation db but no one in their right mind uses it for a large or high-performance db. But most db changes should be isolated to your persistence layer using Hibernate/JPA so changing database vendors shouldn't have caused a big change in your code unless you had to redesign your tables for some other reason.

> This was more than likely just bad design on your part.

Oh I won't deny that, as I mentioned, I approached the problem from a background with limited exposure to modern web technologies. Still though, lets take just one aspect, db interaction for which I used hibernate:

First I create my DB structure, then create an XML mapping, then create the POJO model (replete with getters/setters) sure, most IDEs do this automagically, but experience with switching IDEs and changing versions makes me abhore IDE generated code, then hibernate's own XML config, then the utility class (I called these factories, my bad). Not to mention the prerequisites that made all this possible, glassfish, maven etc require their own configuration etc. By now I have several thousand lines of code and I've not even implemented any functionality. Time taken, no clue, but hours, lots of hours.

The equivalent with Python + TornDb?

Create schema, extend torndb to pull credentials from environment variables & connect to db (3 lines of code, wow), create flaskapp.py, bind path to a method, begin writing the "real" code. Lines of source, under 100. Time taken, less than an hour.

> J2EE (which became Java EE over 8 years ago) I have to wonder if you used a lot of legacy APIs and design patterns.

When you spend a considerable amount of time calling something by one name, despite a rename you tend to continue. Apologies for using the incorrect name, but the rest of your assumption are unfounded unless you're calling Glassfish, Hibernate, Jersey, JSF and JavaDb legacy ..

> Derby is neat for an portable in-process relation db but no one in their right mind uses it for a large or high-performance db

Those were precisely the reasons I chose it, the example I gave isn't large or high performance, and its pathetic at that role, I stand by my assertion. You'd be better off using serialised objects, CSV files, heck even notes scribbed on postit notes tacked to the wall than JavaDB.

I say this after countless hours spent taking the platform offline to rebuild the database which grew uncontrollably despite careful use of transactions within hibernate and daily cron jobs to run SYSCS_UTIL.SYSCS_COMPRESS_TABLE

For the schema stuff, these days what i would do is write the objects, add the minimal set of JPA annotations (which can be as little as @Entity at the top and @Id on the ID column), then generate the DDL from that. You don't need any XML for the mapping.

Sadly, you do still need a persistence.xml with the database connection details, and for some providers a list of all your entity classes (WTF). I have a build script which generates all that (amongst other things), though:

https://bitbucket.org/twic/jpaquickstart/src/0c5b383026ba097...

Interesting!

I did end up using annotations as you mention. However I chose to manage the db structure myself because early on I encountered problems when I changed data types and indexes, hibernate incombination with JavaDB dropped then recreated the structure, which is fine, but then if you want to push your changes to the live version, I had to write the SQL to port the live data into the newly created table which was a PITA given javadb can't insert into "GENERATED ALWAYS AS IDENTITY" columns, so that in turn meant more SQL to preserve referential relationship between data. I was always left feeling I did something totally wrong in that respect, so I blame myself.

A part of this also stems from the way I approach building an application, I'll always spec & then create out the DB as a way of helping me visualise the model before I start doing any "real" coding.

I still respect Java enormously, but I'm not at all sold on JEE application servers for anything below enterprise scale applications. And for any case where you need a quick prototype, Java definitely will not be my choice in the future.

Why a XML mapping file? If you don't like getters/setters no one is forcing you. A fully function JPA entity class is:

    @Entity
    public class TableName {
        @Id public int primaryKeyColumnName;
        public String someOtherColumnName;
        @Column(name="DESC") public String fieldThatDidNotMatchColumnName;
    }

How the heck did you get to thousands of lines of code without even having an functionality? You can create a RESTful webservice that does basic CRUD ops to a database in just a handful of lines....

And unfortunately there are tons of legacy APIs (backwards compatibility...) available in any Java EE app server like GlassFish. Hopefully they really will start pruning things from the spec.

Do you want to create a basic CRUD web service with your hip-Startupy method of choice and I'll create a Java equivalent so we can compare? I'm curious about how it would play out.

Even yesteryear's Java EE does not require the configuration you mention. See e.g. this example: http://jdevelopment.nl/minimal-3tier-java-ee-app-xml-config or this one: http://henk53.wordpress.com/2012/04

Specifically you don't need to create a schema, xml mapping and POJO model. In most cases you ONLY need the POJO model. The XML mapping is almost never needed and the schema (DB structure) is generated automatically from this POJO model. Hibernate specific config is certainly not the norm to have, especially not in its own file. At most you may want to set one or two attributes in the Java EE/JPA standard persistence.xml file.

You also rarely need any GlassFish specific config. It exists, but needing it is the exception rather than the rule.

I wonder how you can talk about both hibernate and GlassFish configs btw. GlassFish ships with EclipseLink, so you don't need hibernate as well (they both implement JPA and will even conflict when used together).

I think you're indeed mistaken ;) Java EE had a bad reputation in 2004, being mainly represented by mega corps with their hidden corporate agendas (IBM, BEA, Oracle). Developers weren't being asked what the wanted or needed managers were influenced by sales teams to go with either IBM or BEA. Application servers were at least a 2GB download and easily required a GB of memory to run (this is still a lot in 2014, go figure what this was in 2004). Of course everything was closed source, super expensive (so your company never updated) and servers took a minimum of 5 minutes to boot up. A hello world in the then dominant EJB 2 technology required implementing 3 interfaces, inheriting from a base class, using a special compiler tool to enhance the class another compiler tool to create stubs and needed some 20 lines of XML in an incredibly verbose format to be registered.

You didn't need to be a technology export to predict developers didn't really like this tech (understatement of the year).

In 2005 Sun made a dramatic turn, and Java EE 5 started focussing on developer demands instead. Meanwhile many open source initiatives started or were getting mature (Sun's GlassFish, JBoss, Apache's Geronimo and recently TomEE).

Java EE 6 (2009) and EE 7 (2013) continued this trend.

Long story short, completely free and open source servers that start in a second or less and are between 30 and 120MB to download now dominate the market. The APIs have been dramatically simplified and the process of contributing to the platform has been largely opened, making it possible for anyone to create issues, submit patches or discuss the future direction. There's one thorny exception and that's the so-called TCK: a test suite that checks spec compliance is still mostly closed.

And yes, there are now hip startups using Java EE, for example http://zeef.com

All in all Java EE has become somewhat of a secret weapon. It's powerful, yet lightweight and quite a lot of people have not (re-)discovered it yet. Especially when combined with Java 8 (due for release next week) it's a very good stack.

see also Resin, which has a GPL version http://www.caucho.com/

Reply on news.ycombinator.com