We Keep Coding

How can I convert the ISO codes to country names in my MySQL table?

I found on GitHub a project that JSON which contains a list of 28K+ airport(ISO code, name, status...) which is great and I'm gonna use it in my Java project later on. I converted to a .sql file and imported it in my MySQL database as a new table.
My only problem is the ISO codes, I was looking for one with the country names not the codes themselves. So I added a new column to my MySQL table called country that would eventually contains the country name. So how could i do that? Is there a project or some code I could use to automatically convert the ISO codes to the country name without having to manually do that for the whole 6822 rows in the table?

Here is the JSON data for countries and their codes. (They have some more APIs)
You can use Jackson to create a HashMap from the JSON data and use it to get the country name by it's code.

This is likely just ISO 3166 Country Code data which is readily available in a variety of formats.

How to get list of nationalities in Java

Does someone know a way to retrieve a list of nationalities in Java ? Few precisions : I do not need a list of countries but a list of nationalities. I do not need a list of languages, but a list of nationalities. I've tried to twist Locale API, without result.
And icing on the cake, I need to display nationalities in a specific languages.For example, with Brazil, I need to display a 'brazilian' in english, a 'brésilien' in french and a 'brasilero' in spanish.
Does someone have an idea ?

Java doesn't contain a list of nationalities as far as I'm aware. The Locale class just gives a list of regions as stated in the javadoc. It would be helpful in your situation, but not for a lot.
From what i gather, you're going to have to create your own list of nationalities, and the name of the nationality in each language - not too hard.
To do the language part, internationalization will be helpful. It allows you to get the users region and set a language depending on where the user is from. It also allows formatting of numbers, text and dates.
Look at this stack overflow answer specifically for how to get the names of the nationalities in different languages. Basically, you create a different file for each language and inside the file are key-value pares. So the English file will look a bit like this:
nationality.english = English
nationality.german = German
nationality.russian = Russian
and the German file will be similar to:
nationality.english = Englisch
nationality.german = Deutsche
nationality.russian = Russisch
then depending on what language you want the nationalities displayed in, you just get the text from the language file using the key (e.g. nationality.russian).
To do the nationality part, you can create an enum that contains all the nationalities. For example:
public enum Nationalities{
ENGLISH,
GERMAN;
//And so on
}
See here if you are new to java enums.
You will probably want to add a bit more information in the enum class, such as the county and what the key for the nationality name is.
To pull it all together, you get the region of the user and set the language file for the region. Then for each listed nationality, you get the name of it from the language file.

Why do we need converters for TextFormatters

My professor said that it is 'ideal' to use a filter and a converter for a TextFormatter. I looked at his examples and tried them, but couldn't understand why we need a converter at all.
From the docs:
A Formatter describes a format of a TextInputControl text by using two distinct mechanisms:
A filter (getFilter()) that can intercept and modify user input. This helps to keep the text in the desired format. A default text
supplier can be used to provide the intial text.
A value converter (getValueConverter()) and value (valueProperty()) can be used to provide special format that
represents a value of type V. If the control is editable and the text
is changed by the user, the value is then updated to correspond to the
text.
I am cleary something missing here. I get why you want to convert a string to an integer (for calculations etc.). But why do you have to have it as a part of TextFormatter? Can't we just use getText() and then just cast the text as we want to have the value?
One more thing: If we have a filter that doesn't allow non-numeric characters, then why do we need to take care of the conversion of the text to integer/double etc. with a converter?
Maybe I am just missing something very obvious.

You can't cast a String to an Integer (or any other type, except an Object): you have to convert it. Even if the text formatter has a filter that only allows numeric entry, the text field's getText() method still returns a string, which is usually not very convenient (as the entry in the text field likely represents a numeric value in some object).
You might need to get the integer (for example) value represented by the text field in many different places, so you centralize the conversion code in one place by including the converter as part of the formatter.
Additionally, the formatter's value is an observable property, so you can easily bind other properties to it, etc. This would be tricky if you needed to perform the conversion in a binding on the text field's text property.

Java data type for holding e164 phone number format

Is there any data type in java for holding E164 international phone number format?
I dont want to store the value in a string and then validate. I would like to simply define my variable in this particular data type.

You can make use of Google's libphonenumber api.

Java: Currency to Locale Mapping Possible?

I have a value stored in a DB correlating to a monetary amount, say 10.0. I also have access to the Currency/CurrencyCode. How can I use NumberFormat/DecimalFormat/(other?) to format when I don't know the Locale? According to the docs it will pick a default locale which won't work with a foreign Currency.

JasonTrue is correct, but you can override the currency of the NumberFormat's locale:
NumberFormat numberFormat = NumberFormat.getCurrencyInstance(locale);
//the user may have selected a different currency than the default for their locale
Currency currency = Currency.getInstance("GBP");
numberFormat.setCurrency(currency);
numberFormat.format(amount);

The correct behavior, generally speaking, is to format the amount in the User's preferred locale, not the currency's typical locale. On the client side, you'll have the user's preference (Locale.getDefault()); if you are doing something on the web server side, use the Accept-Language or, preferably, the page content's locale to obtain the proper a locale.
The reasoning is this:
An English-US user will understand € 10,000,000.15 but not the suitable-for-Germany equivalent, € 10.000.000,15
The currency itself doesn't contain enough information to infer a suitable locale, anyway.

What if the currency code is EUR? And, while it has taken a beating, USD is still used throughout the world. Inferring the locale from the currency code seems unreliable. Can you introduce an explicit user preference for the locale instead?
The information you are looking for is not part of the built-in Java currency database, so there is not an API for it. You could create your own table for the many cases that are unambiguous.

I would say that if your database is storing a currency value it should be hanging onto the units at the same time. It sounds like you're doing that now. Can you add the Locale to the database at the same time? Could be a decent solution.