Fx2C - small tweaks

Fx2C transpiler does get a bit smarter but also in a meaningful way. If you plan to use Kotlin mixed with Fxml (a feature which I think neither Oracle or JetBrains thought supporting) you will see that there is no (straight forward) way to support @Fxml fields.

Do not worry, if you have a Kotlin controller class, you can write something like inside fxml file:

<!--   Flags: IsKotlin-->

And the Kotlin code will work seamlessly:

package desktool.views.kotlinView

import javafx.event.ActionEvent
import javafx.fxml.FXMLimport javafx.scene.control.Button
import javafx.scene.control.Label

class LineToolControler {
    var thickness = 1   

@FXML    

var label: Label? = null    

@FXML    

var button: Button? = null    

@FXML    

fun handleButtonAction(event: ActionEvent) {
        println("You clicked me!")
        label?.setText("Hello World!")
    }
}

This is not to say that right now it is better to use Kotlin, but the idea is that maybe in future the code will be extended to support various other languages (Scala is another language which comes to mind) with JavaFx.

Another important part is that right now the compiler will generate a preloader class (Fx2CPreloader) which can load all classes in memory so for second time the JVM will start the dialogs in a fraction of the second. Under my unscientific testing, using a slow Atom CPU (Baytrail) machine, a medium sized dialog first time loading of classes into JVM could take something like 600 ms, but with preloading, the time can be reduced into 2-5 ms.

So, is it important to use this preloader? I think that yes, especially if you have many UI elements, using this preloader under a splash screen will warm up the JVM and will make the 2nd run to make your dialogs to be seen (close to) instantly.

This Fx2C tool is for me mature enough to be in maintenance mode for now, as it works really well enough for my taste/usages and I will likely use to make more JavaFx applications and just to feel responsive, a feature which I was feeling as missing going from a .Net WPF environment.

Vampire Logic - my team's entries

I was participating to create 3 apps using Microsoft Universal Apps APIs over a zombie competition (hackatlon). My ad-hoc team (Vampire Logic) did really well there.

Source code for these 3 (working) apps (in categories Productivity/Games/Educational) were created in 18 hours combined (around 6 hours per app, give or take).

Productivity: an image editor with camera support, Modern UI, live preview and infinite Undo levels:
https://github.com/ciplogic/zombie_productivity

Game: a zombie ship fights in a top-down shooter with animated background. It uses efficiently a Canvas control and fluent animations using only standard Universal Apps code
https://github.com/ciplogic/zombie_game

Educational: An interactive math game where the harder and harder math problems are given in limited time. How long will you survive?
https://github.com/ciplogic/zombiedu

The coding practices may be spotty at time, but excluding the fact that that the applications were written in only 6 hours (and was our first ever Universal App coding experience), all applications had no known bugs in the way coding was done (like no crashing, or solving errors just with big try-catches to hide them) or similar stuff.

Coding language: C#

Team members: Dāvis Sparinskis, myself, Linda Legzdiņa, Rudolf Petrov

Some photos with my team:

Finding non-duplicates in an array (using Java)

I had a job interview and I will do a lot more Java stuff in day-to-day coding (yay!) and one part of the job interview was about searching non-duplicated values from an array. There is a technical solution (which I would not divulge) which is with O(n) complexity (meaning that the maximum it should scale up linearly with the size of the array) but can it run faster?

Faster than O(n) complexity wise is kinda impossible, because you have to traverse the once the array of data. But as we've seen in an older post, if you can get the constant down, you can get a faster algorithm. So, what about searching it naively the chunk of the data and put it into an int array?

This is not my best benchmark (and I didn't try all combinations) but up-to 100, an native int[] (int array) structure would run faster than using the O(n) complexity.

The code that would search an index (and it will return Integer.MIN_VALUE if no value is not duplicated) is the following:


    public static int GetFirstNonRepeatingIntArray(int[] values) {
        if (values == null) {
            throw new NullPointerException("values");
        }
        int[] counters = new int[values.length * 2];
        int counterSize = 0;
        for (int index = 0; index < values.length; index++) {
            int toFind = values[index];
            int foundIndexValue = getIndexOf(counters, counterSize, toFind);
            if (foundIndexValue == -1) {
                counters[counterSize * 2] = toFind;
                counters[counterSize * 2 + 1] = 1;
                counterSize++;
            } else {
                counters[foundIndexValue * 2 + 1]++;
            }
        }

        for (int index = 0; index < counterSize; index++) {
            if (counters[index * 2 + 1] == 1) {
                return counters[index * 2];
            }
        }
        return Integer.MIN_VALUE;
    }

    public static int getIndexOf(int[] counters, int counterSize, int toFind) {
        for (int foundIndex = 0; foundIndex < counterSize; foundIndex++) {
            if (counters[foundIndex * 2] == toFind) {
                return foundIndex;
            }
        }
        return -1;
    }

For example for 10,000 repetitions of the algorithm if arrays are of 50 items (which are randomly generated in a range of 1 to 25) it would give the following output:
Total execution time: 100ms
Total IntArray execution time: 31ms

Does it have any implication in your day to day life this kind of coding? I would say yes: when you work typically with "Settings" kind of classes, you will better work using arrays/Lists than dictionaries, even it is counter-intuitive: there is very unlikely you will get hundreds of settings, but both as debugging experience and performance may be better. Memory usage (especially compared with Java's HashMap implementation) is also much better.