> 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:
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.
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).
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.
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