"Toy" human-language detection software

I've written a small program to detect the human language of a document or text fragment.

I tried to stick to good design principles and I tried to make it pretty robust. I would be generously described as an intermediate programmer so I'm sure there are things that are bad-smellish that didn't even register with me.

The program works, but I wonder if there is any way to make it better. I always hear that software is never actually done, you just stop working on it.

Also, I'd like to know if you are about the download it from my GitHub page and run it on your machine with no troubles, is it so?

The "load bearing" class which actually processes the input.

```
public class Processing
{
static double falsePositiveProbability = 0.1;
static int expectedSize = 500000;

//GERMAN
static BloomFilter de_bloomFilter = new BloomFilter(falsePositiveProbability, expectedSize);
//ENGLISH
static BloomFilter eng_bloomFilter = new BloomFilter(falsePositiveProbability, expectedSize);
//FRENCH
static BloomFilter fr_bloomFilter = new BloomFilter(falsePositiveProbability, expectedSize);
//SPANISH
static BloomFilter es_bloomFilter = new BloomFilter(falsePositiveProbability, expectedSize);
//ITALIAN
static BloomFilter it_bloomFilter = new BloomFilter(falsePositiveProbability, expectedSize);
//PORTUGESE
static BloomFilter pt_bloomFilter = new BloomFilter(falsePositiveProbability, expectedSize);
//DUTCH
static BloomFilter nl_bloomFilter = new BloomFilter(falsePositiveProbability, expectedSize);

public static void process_input( List input_text ) throws URISyntaxException, IOException
{

//THIS SEGMENT IS FOR DYNAMICALLY LOCATING THE DIRECTORY, SO THE PROGRAM WORKS "OUT OF THE BOX"
/*****/
//this holds all the dictionary files, i.e. word lists garners from languag

When things go wrong...

If initialization of MessageDigest digestFunction fails,
you just assign it to null.
But the class will be unusable that way,
as when createHashes is called, that will lead to a null pointer exception.

Instead of a static initializer like this that might fail,
it would be better to create MessageDigest in the program's top-level function, and if such fundamental problems are detected than stop execution.

Similarly:

try {
    UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
} catch (ClassNotFoundException | InstantiationException | IllegalAccessException | UnsupportedLookAndFeelException ex) {
    ex.printStackTrace();
}

UserInputPane userInputPane = new UserInputPane();
// ...

If UIManager.setLookAndFeel fails, you just print a stack trace and execution continues normally... It seems the program will be completely unusable like that.

As with the earlier problem,
it would be better to handle this at a higher level in the program and exit if an unusable state is detected.

Naming

private int k; // number of hash functions

Seriously? Even this would be better:

private int numberOfHashFunctions;

I would go with:

private int hashFunctionCount;

public class iDentificateur

It would be better to use English consistently throughout the code,
and class names should be PascalCase in Java.

Placement of braces

This way of placing braces is not common in Java:

public static int createHash(String val) 
{
    return createHash(val, charset);
}

The way is to put the opening brace on the same line as the closing:

public static int createHash(String val) {
    return createHash(val, charset);
}

Your IDE can easily fix this for your entire code.

Update: more on placing braces...

The placement of braces is a convention, not a hard rule. You can do as you like. Just keep in mind that all the major IDEs today encourage this convention by the default behavior of their auto-reformat feature.

Neither brace placement style is better than the other.
But if you get used to the most commonly used style,
then if you have to review the work of other programmers,
you will likely see a familiar style,
and it will be easier to read.
If you prefer a different style than the most common,
then you will likely see a different style,
it will be harder to read, and you will be dismayed.

Update: more on detecting fundamental problems early

I pointed out above that your program doesn't handle well fundamental problems:
you print a stack trace, log, or null a variable, and let execution continue,
even though the program cannot possibly function well.
When problems critical to the basic functioning of the program are detected,
it might be tempting to just stop execution with System.exit(1).

However, in your case,
the conditions are in fact pre-requisites,
not some random errors that can happen while the program is running.
As such, you could detect these problems in the main method that sets up your program elements and starts the execution of everything.
That would be the right place to check for preconditions (such as, can you can actually create a MessageDigest with "MD5"),
and exit otherwise.

Without catching missed pre-requisites early,
the problem crashes later, who knows when,
with a generic NullPointerException or something else that may not be very helpful for debugging the real cause of the malfunction.

StackExchange Code Review Q#91673, answer score: 3