4 ms·

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

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.

Nanzikambe 13y ago
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.
matt_heimer 13y ago
> 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.
- Nanzikambe 13y ago
  > 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
  - twic 13y ago
    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/0c5b383026ba097f86e29866b6ccd90e9663f2fd/build.gradle?at=default https://bitbucket.org/twic/jpaquickstart/src/0c5b383026ba097...

Nanzikambe 13y ago

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.

matt_heimer 13y ago

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

Nanzikambe 13y ago
> 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
- twic 13y ago
  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/0c5b383026ba097f86e29866b6ccd90e9663f2fd/build.gradle?at=default https://bitbucket.org/twic/jpaquickstart/src/0c5b383026ba097...