We Keep Coding

Saving Data from a JavaFX-Application without Database

Unfortunately I couldn't find anything specific to this topic / to my problem. Here we go:
I'm building a JavaFX Business Application for a friend of mine. Unfortunately I do not have any possibility to connect to a Database. I want the Application to load a savestate from a file. The application contains a list with clients and the clients got some specific properties. I do not want to hardcode this to a .prop or .txt file, because I'm sure that there's a different way of doing this, isn't there?
Thanks in advance, appreciate it!

Lots of choices for persisting data to local storage. The exact choice depends on your needs. You do not describe enough details to make a specific recommendation.
Here is a list of possibilities, roughly in increasing order of complexity of your data.
Text file
If you have small amounts of simple data, save to a text file. You can store each piece in a separate file, or combine into a single file. Recent versions of Java have new classes to make this easier than ever. See Oracle Tutorial.
Comma-separate & Tab-delimited
For sets of structured data, write to text files in comma-separated values (CSV) or tab-delimited values. For example a list of people with rows for each person, and columns for name, phone number, and email address.
While reading/writing such files is easy enough to program yourself, I suggest using an established library to eliminate the drudgery, avoid bugs, and save yourself some time. There are a few such libraries written in Java.
My favorite is the Apache Commons CSV project. This library makes easy work of the chore of reading/writing such files. Despite the name, this library supports tab-delimited as well as comma-separated formats. I've written a few Answers here on Stack Overflow showing how to use this library, as you can see here, here, and here.
By the way, plain old ASCII defines a few character positions explicitly for delimiting in data files, with four levels of grouping (document, group, record/row, and field). Unicode, of course, inherits these from ASCII as code points. I am puzzled why these have remained so obscure and so infrequently used. Seems much more logical to me than using commas and tabs which may well exist inside the data payload.
Serialization
You can write out the data values stored within an object. This is called serialization. Java has a serialization facility built-in, but be sure to study up on the details.
To more simply write out an object’s values and later read them back in to reconstitute an object, I have enjoyed using the Simple XML Serialization project. This works well for relatively simple needs, and is aimed at the situation where you want the structure of a class to drive the process of determining what to write.
Java has other XML binding facilities both built-in and third-party. These are much more powerful in their flexibility. They are especially good for when you want to define and verify the XML structure in a rigid fashion such as defining a XML DTD or XML Schema against which to validate the data and perhaps even generate the Java class in which to represent the data.
Embedded database
For more complicated data, use an embedded relational database.
The SQLite database is bundled with many platforms. This is a C-based library, not pure Java. As the name indicates, SQLite is indeed quite “lite“, lacking rigid data types and many other common database features. SQLite is meant to be an alternative to writing text files than as a competitor to more serious databases. It is a great product if your needs fit the sweet-spot of its capabilities.
My first choice for an embedded database would be H2 Database Engine. Built in pure Java. Can be run inside your app, or separately as a server (you choice). Has sophisticated relational database features. Has been around for years, often updated, and is well-worn. The principal author has much experience in the field.

Hibernate Domain Object Generation

I'm trying to understand how to best generate and synchronize domain model POJO's from my database using Hibernate. Right now the process I managed to build is the following:
Build the ER schema on the database
Have an hibernate.reveng.xml file containing the elements (one for each table)
Use JBoss tools on eclipse to run a code generation configuration where I set the target package and location, the aforementioned reveng.xml file and get generated POJO's, mapping files and hibernate.cfg.xml files
But this has a lot of problems:
I cannot map common fields (ID, created by, modified by, etc..) to a
particular base entity.
I have to manage a lot of mapping files (doesn't seem to generate a
single one)
I cannot generate a basePojo and have my extended one so that my
modifications on the POJO's aren't overriden by the next code
generation.
I cannot fine tune the output location of the generated artifacts (mappings, .cfg and Pojos) they all go into the same base folder (POJO's are placed according to the package name I set)
Is it possible to "tell" the generator to map the common table fields to the same classe (createdBy, ModifiedBy, ID, etc...) ?
I'm questioning if this approach makes sense at all? Should I be managing my POJO's by hand ? I don't mind that but some help managing the mapping files (.hbm.xml) would help a lot.
Or should I find some way to go "code first", ie. write the POJO's and then generate the schema ? I'm a bit used to the .NET's entity framework and I feel quite lost on what's the "proper" way to build the persistence layer in Java/Hibernate
Thank you

The Telosys Tools code generator is probably the solution for you.
It uses an existing database to generate any kind of source file for
each entity (database table), typically POJO, DTO, DAO, web pages, etc...
When the database schema change you just have to regenerate.
For more information see the web site : https://sites.google.com/site/telosystools/
and the tutorials : https://sites.google.com/site/telosystutorial/
All the templates are free and customizable,
for Hibernate POJO you can use the JPA templates (https://github.com/telosys-tools/persistence-jpa-TT210-R2) and adapt them if necessary

Import and export data as files using Spring/Hibernate

I need to be able to export and import data from one instance of my application (spring / hibernate) to another.
My data are stored in multiple tables (with foreign key contraints), and can contain LOBs. I am also required to export the data in files (no specific format).
The Data pump API looks promising but I need to do something "easy to use" (basically a "export those data" button and nothing else), so I can't use external tools such as the one integrated in sql developer
Does spring provide a way to to use this API (or a similar one), or is there another framework that I could use?

Have a look at the Spring Data and Batch projects. They might help.
I don't know what "from one instance to another" means. Are these separate versions?

if export/import is between database then writing procedures sounds good to me.If it can be for any format(file/webservice) to any then go for mule(http://www.mulesoft.org/what-mule-esb) ,Spring batch.

How to generate orm mapping classes from sql schema in Java

I have an existing sql schema file for db. Is it possible to generate and re-generate when needed DAO's entities and all other required helper/client classes to access it? I don't mind what will it be -- hibernate, other jpa or something else.

Asuming you/others are still looking for a solution:
I just got the same problem and got it working in Eclipse (slightly different) as follows:
created JPA Project and downloaded & added user library in the wizard
Also wanted to give a schema-sql-file as input but instead found a way to take an actual db as input. (That was surely much easier for the developers of the tool to process than parsing proprietary sql-script-files)
To do that "rightclick" you jpa project an there "new/other/jpa/entities from tables"
In the following Wizard you have to create a db-connection to the db whose schema you want to get as jpa-annotated POJOs (IMHO It's very intuitive..but you may ask if there is a problem)
After finishing all jpa-classes are generated from the db...saved me from a lot of dummy work :)

For a simple application, should I be using XML files or a real database or something else?

I'm currently working on a simple Java application that calculates and graphs the different types of profit for a company. A company can have many branches, and each branch can have many years, and each year can have up to 12 months.
The hierarchy looks as follows:
-company
+branch
-branch
+year
-year
+month
-month
My intention was to have the data storage as simple as possible for the user. The structure I had in mind was an XML file that stored everything to do with a single company. Either as a single XML file or have multiple XML files that are linked together with unique IDs.
Both of these options would also allow the user to easily transport the data, as apposed to using a database.
The problem with a database that is stopping me right now, is that the user would have to setup a database by him/herself which would be very difficult for them if they aren't the technical type.
What do you think I should go for XML file, database, or something else?

It will be more complicated to use XML, XML is more of an interchange format, not a substitute for a DB.
You can use an embeddedable database such as H2 or Apache Derby / JavaDB, in this case the user won't have to set up a database. The data will be stored only locally though, so if this is ok for your application, you can consider it.

I would defintely go for the DB:
you have relational data, a thing DBs are very good at
you can query your data in that relational much easier than in XML
the CRUD operations (create, read, update, delete) are much more easier in DB than in XML
You can avoid the need for the user to install a DB engine by embedding SQLite with your app for example.

If it's a single-user application and the amount of data is unlikely to exceed a couple of megabytes, then using an XML file for the persistent storage might well make sense in that it reduces the complexity of the package and its installation process. But you're limiting the scalability: is that wise?