I read an interesting question about Monitor structure in Swift Forums. The question was how the way it is implemented in Java using synchronized methods compares to Swift concurrency and actors.
Well since this was interesting and I wanted to learn more, there was simply no other option than to pick up the code editors and start coding…
I’ve been busy with preparing the Data structures and algorithms (DSA) course. As mentioned earlier, I decided to remake all the programming tasks, which I did.
Partly they were edited from earlier year tasks. Like the Graphs task is the old 2021 Mazes task with a Pac-Man kind of a game. Each task has the actual algorithm and/or data structure to implement, and additionally a task to apply that in some specific problem solving situation. Another programming task applying a data structure is the implementation of linked list and then using it as a snake in a Snakeses game.
I also decided to remake all the recorded lecture videos. There was a couple of errors in the slides and some content needed revisions and better treatment. So I did that too.
All in all my attempt was to make the course easier to pass without cutting or compromising the learning goals. It has become kind of a bottleneck course in the curriculum when the compulsory prerequisite to a later course was cut away. Now students tend to take it later than before, so the number of students passing has been slightly lower than before. Hopefully this helps, well see.
Courses started two weeks ago and the first deadline of DSA is tomorrow at noon. Students are supposed to deliver the URL to the remote repository where their code will be.
I also remade the tool teachers and students can use to check the code does use the building blocks they should use. Like when implementing a recursive binary search, the tool checks that the function actually calls itself. Another example is a data structure’s toString() -method. There, it must use StringBuilder, not String — since it is thousands of times slower with large number of elements in the collection.
Some checks are made to make sure students do not use loops in various cases where they should cope without. So the tool has a rules file listing all these different kinds of rules to follow:
The implementation then uses the com.github.javaparser library to parse the student code and check if the rules are followed. To avoid false warnings (and to some extent trying to fool the tool), the tool first clears comments and literal string values out of the code, and then analyses if the rules are fulfilled.
—
Otherwise, I’ve been in the usual Fall flu for the past ~25 days. I had to stop running due to that. A week a go I had to visit a doctor due to feeling really odd, like fainting. Nothing was found, except that the white cell levels in blood were a bit elevated. Strange times, strange illnesses.
First run after the break was the on Tuesday this week. I did 5+ km run, and yesterday 4+ km run, totaling a bit over ten km. Hopefully no more sickness this year.
—
Now I’ll have to rush to a teachers’ meeting. Returning back to this blog later, hopefully sooner.
In the post last week I mentioned that I’ve added new features to the tool I use in Data Structures and Algorithms course to supervise, support, test and grade the student programming course work. I’ll describe here the new features and provide some (hopefully) interesting implementation details about those.
Background about the course that helps in understand the role of this tool:
students each have their own github or gitlab repository to where they fork the initial status of their course work from the teacher repository,
repository contains the task instructions, skeleton code to implement, unit tests code and other supporting code given ready for students,
repository tests enable testing the student’s implementation of the data structures and algorithms that are required to implement in the course,
teachers have access to the student repositories to assist students with any issues, and finally to grade the work.
Before going into details, a comment about the motivation for this tool to exist in the first place: The course the tool is used in, has 300+ enrolled students and only two full time teachers (sometimes we do have 1-2 assistants with small number of hours, like 50 hrs in total for the whole Autumn), simultaneously teaching 2-3 other 200-300 student courses. That totals around 900+ active students taught simultaneously, so providing individual support and attention to all is practically impossible, at least if no automation (and other support tools) is taken into use.
So the critical thing in managing all this work is, that we do need automated tools to:
keep track of how the students are progressing in the course and help those who desperately need it, and after the last deadline,
to evaluate and grade the students’ programming submissions as fast as possible.
The grading should be done in three weeks after the last deadline, so it cannot be done in time manually. The aim is to use this tool during the course, trying to catch those students that are not doing OK, and then try to contact and help them in getting their coursework going and spotting any possible mistakes in their work so that they can correct their mistakes before the final deadline.
Students next Fall will receive the same unit tests and the same code analysis tools (in Java unit tests) they can also themselves use. However, this is not enough, especially if the students do not contact the teachers about their issues soon enough or at all. A problem that is too common, unfortunately.
The new features added to the teachers’ tool during this Winter and Spring are:
Automatic source code analysis:
results of the source code analysis are stored in a database table; repository table has a column where problems found in code are flagged,
tool checks for java imports that are not allowed, notifies about this and sets error flag in the database table,
tool also uses the Antrl parser generator to check if method implementations in the source code violate any rules and if the code does not do the things it should do.
Remote repo checks for both github and gitlab:
checks that remote is not public, the rule of the course,
checks that remote has only allowed contributors.
Testing and grading enhancements
tests are now grouped to grade level tests,
when all tests in a grade group passes, grade is stored to repository table,
grade tests can be executed in whichever order, since grade value is bit flag,
test for a certain student repository can be disabled if they cause issues like tests never ending or taking way too much time,
if git pull updates code, grade is set to zero and test results are cleared.
Status reporting
the tool now generates a textual status report that can be sent to student by email, listing how test pass, if any forbidden things are used / things to use are not used, git statistics etc.
Let’s take a closer look at the code analysis done by the tool in this post. The other features are left for future possible posts to discuss.
Analyzing if the source code uses “forbidden” imports was implemented with simple text parsing techniques. The tool goes through the Java source files in a certain directory where student code is located, reads the .java files and checks if the source uses imports that are not allowed.
For example, when implementing a Stack data structure, student must not import the java.util.Stack and just use it instead of implementing their own stack from scratch, using an array as internal data structure. Or when sorting an array, java.util.Arrays is not imported and Arrays.sort is not used, because student should have used their own implementation of the sorting algorithms.
These kinds of mistakes can be found by analyzing the imports in the student’s .java files. You cannot call Arrays.sort without having import java.util.Arrays in the .java file.
The tool first reads a rules file that contains the import rules for the course:
For example, the java.util.Comparator may be used by the students in all of their .java files (*). The same goes with java.util.function.Predicate and all the files in package oy.interact.tira (the course source packages). The class SetImplementation may also import java.util.Iterator.
Et cetera. As you can see, this is an allow list, not a deny list. The imports that are allowed and can be used in the course are small in number, so it is easier to have an allow list than deny list.
Reading the allow list and analyzing the source files was straightforward to implement by simple file handling and text parsing. First read in the rules file and parse the import rules from there, into this structure:
fileprivate
struct SourceRequirementsSpecification {
var allowedImports: [String: [String]] = [:]
The Swift dictionary object allowedImports has the class as the key (either * or the name of the class rule is about), and then the array of allowed imports the class may contain.
Then the tool starts reading the student .java files and handles all lines beginning with import to check if that class may import that specific thing or not. If the .java file imports something that was not allowed, the tool database table (for the student’s repository) having a column with integer value, a specific bit in that number (a “flag”) is set to 1 (true). This indicates that the student’s code imported something it was supposed to not do.
This is the data structure keeping track of these repository flags, if they are set or not set:
struct Flags: OptionSet {
typealias RawValue = Int16
var rawValue: Int16
static let remoteFails = Flags(rawValue: 1 << 0)
static let buildFails = Flags(rawValue: 1 << 1)
static let usesForbiddenFeatures = Flags(rawValue: 1 << 2)
static let repositoryIsPublic = Flags(rawValue: 1 << 3)
static let repositoryHasOutsideCollaborators = Flags(rawValue: 1 << 4)
static let repositoryTestingIsOnHold = Flags(rawValue: 1 << 5)
}
The Swift OptionSet is a type that presents a mathematical set interface to a bit set. So each flag is a single bit in the 16 bit integer, being either off (0) or on (1). So instead of having six boolean columns in the database table, I can have one 16 bit integer column to store 16 different flags. Most of those still available for future needs.
The flag usesForbiddenFeatures is set in this case of student code using forbidden imports (or other features, discussed below). Other flags are used to:
track if the remote repository cannot be accessed at all (remoteFails) or is empty,
compiling the code fails (buildFails),
repository is public even though it must be private (repositoryIsPublic) and finally
if the repository has other collaborators than the student owning the repo and the course teachers (repositoryHasOutsideCollaborators).
These are all issues that have been met in the course during the previous years.
Final flag repositoryTestingIsOnHold can be set manually from the tool user interface for those repositories that mess up the testing, either because the tests are stuck or take too much time and therefore should not be executed before fixed.
That flag struct is a 16 bit integer, the datatype of the database column storing the flags in each student repository database table. If the code has issues related to these rules, the flag is set. When the git repository is updated from the remote, the user needs to run the code analysis again. If a violation of a rule was fixed, the flag is then reset to zero (false), if no other violations are found.
The imports checking from source code is not enough, though.
Sometimes students do mistakes in method implementations they are not supposed to do. Like when implementing a recursive binary search, they implement an iterative binary search. Or when sorting a table in descending order, they first sort in ascending order and then reverse the table order. Since time efficiency is the major topic of the course, this is not what they are supposed to do. Instead, they should use a comparator to sort the table to descending order in the first place, and then no reverse operation is needed at all, making the operation faster.
For checking these kinds of issues the import rules are not enough since these kind of mistakes can be made without importing something. Therefore, the same rules file contains also rules like this:
[codeRules]
# Algorithms.binarySearchRecursive must contain word binarySearchRecursive
Algorithms.binarySearchRecursive,must,binarySearchRecursive
# Algorithms.binarySearchRecursive must not contain word while
Algorithms.binarySearchRecursive,mustnot,while
Algorithms.binarySearchIterative,must,while
CodeWordsCounter.topCodeWords,must,Algorithms.fastSort
CodeWordsCounter.topCodeWords,mustnot,Algorithms.reverse
Here lines beginning with # are comments and ignored by the tool. Illustrating the examples of mistakes above, the rule:
Algorithms.binarySearchRecursive,mustnot,while
specifies that the algorithm binarySearchRecursive in class Algorithmsmust not contain the keyword while. Since breaking this rule implies that the student has implemented the recursive algorithm using iterative approach. Therefore, the learning goal of implementing a recursive binary search has not been met, and code needs to be fixed.
These rules are also parsed from the rules file into the above mentioned rules structure, which now looks like this:
enum Rule {
case must
case mustNot
}
struct CodeRule {
let methodName: String
let rule: Rule
let stringToMatch: String
}
fileprivate
struct SourceRequirementsSpecification {
var allowedImports: [String: [String]] = [:]
var rules: [String: [CodeRule]] = [:] // ClassName : CodeRules
}
In addition to the allowedImports rules, the structure now contains also rules for a class (the Swift dictionary key String has the class name), where the CodeRule structure has the name of the method the rule is about, then if the method must or must not (Rule) contain the string to match.
This is a very simple current implementation, and as I develop this further, it may change to something different later. For example, it should be possible to say that the recursive binary search algorithm must not contain “while” but also not the “for” keyword.
The second example about being able to realize that descending order can be implemented by a specific comparator (instead of ascending sort and then doing reverse, which is more time-consuming operation) is checked by the rule that the class CodeWordsCounter in the algorithm topCodeWords (where the work in the coding task is done) must not call Algorithms.reverse.
If a student uses the Java Collections.reverse or Apache Commons ArrayUtils.reverse for this, that mistake is already caught using the import rules.
For this feature implementation, I used the Antrl parser generator. Antlr has existing grammars for many languages, including Java, and it supports generating parsers also for Swift. So all I needed to do was to get the Antlr tool and the Java grammar files (Java20Lexer.g4 and Java20Parser.g4) and then generate the Java parser and lexer for Swift:
$ antlr -Dlanguage=Swift -message-format gnu -o Autogen Java20Lexer.g4
$ antlr -Dlanguage=Swift -message-format gnu -o Autogen Java20Parser.g4
Those commands place the generated Swift source code files in a subdirectory named Autogen.
Using the generated Swift code from Autogen, the tool can then parse Java code. All I needed was to implement a class that extends the Antlr generated Java20ParserBaseListener, give the rules to this class and start parsing the source string read from the student’s java file, containing the Java source code:
import Antlr4
class Java20MethodBodyChecker: Java20ParserBaseListener {
private let file: String
private let rules: [CodeRule]
private var currentMethod: String = ""
private var stream: ANTLRInputStream? = nil
var violations: [String] = []
func start(source: String) throws {
stream = ANTLRInputStream(source)
if let stream {
let lexer = Java20Lexer(stream)
let parser = try Java20Parser(CommonTokenStream(lexer))
let parserTree = try parser.compilationUnit()
let walker = ParseTreeWalker()
try walker.walk(self, parserTree)
}
}
// ...
Analysing the code happens in the overridden handler for parsing Java methods, enterMethodDeclaration. There, the implementation checks, using the rules, if the Java code contains any keywords that should not be there or does not contain keywords that should be here:
override func enterMethodDeclaration(_ ctx: Java20Parser.MethodDeclarationContext) {
if let identifier = ctx.methodHeader()?.methodDeclarator()?.identifier() {
currentMethod = identifier.getText()
let ruleSet = rules.filter( { $0.methodName == currentMethod } )
if !ruleSet.isEmpty {
if let body = ctx.methodBody() {
let bodyText = body.getText()
for rule in ruleSet {
switch rule.rule {
case .must:
if !bodyText.contains(rule.stringToMatch) {
violations.append("\(file).\(rule.methodName) ei käytä \(rule.stringToMatch), vaikka pitäisi")
}
case .mustNot:
if bodyText.contains(rule.stringToMatch) {
violations.append("\(file).\(rule.methodName) käyttää \(rule.stringToMatch), vaikka ei pitäisi")
}
}
}
}
}
}
}
The violations then contains all the things found to be against the rules.
This worked, except for one thing: if the code has comments that do/do not have the specified keywords of the rules, the code analysis did check those comments also. Even though the comments do not influence the implementation and are therefore totally irrelevant.
So if the comments of recursive binary search algorithm contains the keyword while, the tool would report that as a violation of the rule! Or if the code contains a required keyword, but not in the actual code implementation but only in the comments, the analysis would be satisfied. End result: not satisfactory at all.
First I started to fix this by implementing code myself to remove the comments from the code in a String variable before the analysis, but soon I realized that the Antlr parsing tool should somehow already handle this.
What I did instead, was (after some searching on the internet) to modify the Antrl lexer file for Java so that it does not parse the comments at all, but skips them:
Then I regenerated the Swift parser and lexer source files and added them to the tool project.
Using the new lexer/parsers, the parsed Java code does not anymore include comments and I do not have to consider them at all! This works perfectly.
Without asking anything about any “AI” tools out there. As usual, I do not touch them even with a long stick. I prefer to discover and learn myself, as long as the internet is not polluted with “AI” generated crap which makes everything impossible.
Below you can see the tool reporting about imports in a student repository, imports that should not be in the code, and that the code in CodeWordsCounter.topCodeWords does not call Algorithms.fastSort, even though it should, based on the rules in the rules file.
As you can see, the first violation is because the student has misnamed the class as setImplementation. In Java, classes (and therefore also class files) should always begin with capital letters and the name should be SetImplementation instead. So this is a mistake, but actually does not violate the import rule; the Set data structure implementation may use the Iterator. Therefore, when the rules are found to be violated, it often requires human rechecking to make sure no unfair judgments are made by the automation.
Considering the 300 something students in the course, perhaps each of them making at least 3-5 mistakes the code analysis could find, this results in 900-1500 mistakes in total. For the teacher to comb through all the hundreds of lines of code in each of the student projects, repeatedly during the course, working on this “code quality control” task manually is very time consuming and therefore not a realistic task. Especially considering the available teaching resources mentioned in the beginning.
Hopefully the new features of this tool and the similar tests given to students in Java test code, improve the support the teachers can provide during the course to lead the students to the correct path of implementing the required data structures and algorithms.
The post is getting quite long, so the rest of the new features will perhaps be discussed in future posts. Unless I decide to focus on other more interesting topics. Have a nice day!
Many (most?) apps need some kind of settings the user can modify, that influence on the behavior of the app across app launches. In this post, I’ll show how to implement this with java.util.Properties class in a Java / Swing game.
As an example, I will use the Snakeses game from the previous post. In this game, user can change the difficulty, game mode and light/dark mode of the UI:
The selections will be saved to and read from a file named snakeses.ini:
#Snakeses Settings
#Tue May 06 19:28:32 EEST 2025
difficulty=hard
mode=dark
playername=Antti
style=classic
The settings file contains key-value pairs (e.g. on line difficulty=hard the difficulty is a key, and hard is the value). Managing the settings is then just handling these key-value pairs, providing a user a way to change these in a controlled manner, and then handling the saving and restoring the values with the settings file. The file can also contain commented lines (beginning with #) that are just for humans to read, and are not actual settings.
As you can see, also the latest player’s name, who entered the Hall of Fame, is also stored in the settings. Assuming the game is mostly played by the same player, she does not need to write her name again and again, but can just accept the notification as you can see in the previous post video.
The settings are managed in a single class, unsurprisingly named Settings:
public class Settings {
public Settings() {
difficulty = "easy";
style = "modern";
mode = "dark";
playerName = "Anonymous";
}
public String difficulty;
public String style;
public String mode;
public String playerName;
public boolean isDirty = false;
private static final String SETTINGS_FILE_NAME = "snakeses.ini";
As you can see, the constructor gives the default values to the various settings. You can also see that I’ve taken the easy road of letting the members be public instead of the default and recommended private. Lazy me, but I am myself making sure that as the only programmer in this project I will treat these public members responsibly and not mess the values with anything that is invalid. In a larger project I would let them be private and make sure that setter methods would check that the parameters to change the setting values would always be valid.
How to read the settings from the snakeses.ini file, is shown here:
Opening and reading the settings file is handled using java.io.File, java.io.FileInputStream and java.util.Properties classes. The Properties object will then contain the settings read from the ini file, after calling config.load(istream).
After that, it is simple to read the setting values from the properties object by calling config.getProperty, giving the name of the property. Just to be sure, the code checks if the properties contain that key (using config.containsKey, and if it does not, a default value is used. This is necessary, since the file could be changed outside of the app, by the user, for example, so as a programmer you cannot trust that the file (after saving it) will surely contain those key-value pairs.
Also, when the app launches for the first time, the settings file is not there. It could be delivered with the app with default values, but again, nothing stops the user accidentally or deliberately deleting that file. So the code must prepare for the situation that the settings file does not exist — that’s why the catch (FileNotFoundException e). If the file is not there, again, resort to the default setting values. And then save the settings immediately, calling save(). That makes sure that at least now we have the settings file there.
The member variable isDirty is also set to false. isDirty is convenient to have. When the user opens up the settings panel and closes it, there is no sense in saving the settings if they were not changed. As you can see below, the isDirty is set to true if the settings change, and only then the settings are actually saved. No need to do any disk access if there is no need for it.
Do note that the app in this demo does not check if the settings are actually different from the original when user leaves the settings panel. If there are lots of settings and changing them leads to lots of code to be executed, you might want to keep the old settings somewhere, let the user to manipulate the settings, and then when the user is done, actually compare the old setting values to new ones. For those values that are actually different, then handle the changes to those settings only.
Saving settings to a file is handled using java.io.File, java.io.FileOutputStream and java.util.Properties classes. In this case we just set the various properties of the Properties object, using config.setProperty, giving the key and value pairs to the configuration, and finally call config.store. As you can see, the string “Snakeses Settings” and the date of the update is saved as comments to the snakeses.ini file.
Also, the isDirty is set to false at this time; settings are now saved and not changed.
How the Settings panel then uses the settings when user is shown the current settings? As an example, let’s see how the game difficulty radio buttons are created and how the radio button corresponding to the current setting is selected, in SettingsPanel constructor, other details omitted:
public class SettingsPanel extends JPanel implements ActionListener {
private Settings settings;
public SettingsPanel(Settings settings) {
this.settings = settings;
ButtonGroup levelGroup = new ButtonGroup();
JRadioButton easy = new JRadioButton("Easy");
easy.setActionCommand("easy");
easy.addActionListener(this);
JRadioButton hard = new JRadioButton("Hard");
hard.setActionCommand("hard");
hard.addActionListener(this);
levelGroup.add(easy);
levelGroup.add(hard);
if (settings.difficulty.equals("easy")) {
easy.setSelected(true);
} else {
hard.setSelected(true);
}
The “Easy” and “Hard” radio buttons are created to a ButtonGroup. That takes care of managing the principle of the related radiobuttos that only one of them can be selected at one time. The last if-else block shows how the current value of the Settings is used to select one or the other from these game difficulty radio buttons.
Did you know that the name “radio button” for this control comes from the actual radios to listen to radio stations? Radios used to have several buttons for selecting preselected radio station frequencies to listen to. Obviously, you can only listen to one station at a time. So pressing down one station button would then deselect (pop up) the previously selected station button.
That’s why these buttons are called “radio buttons”. Radio buttons in GUI frameworks are round to distinguish them from check boxes, which are rectangular and function differently (many of them can be selected simultaneously).
Row of seven white rectangular radio buttons in a vintage radio divide. Image from https://www.collectorsweekly.com/stories/273171-1950s-grundig-fleetwood-tube-radio-mode
Obviously, the controls to use in managing the settings depends on the setting and the possible values of that setting. For example, if we would have a setting with multiple values, like e.g. 42 distinct values, using radio buttons would not be a good choice. Then one could use a dropdown / combobox list instead, populating the available options to the list and selecting the one found in the settings.
What happens then when user changes the setting? In the code above, you can see that the SettingsPanel is set as the action listener to the radiobuttons, e.g. in easy.addActionListener(this). Also, each radio button were given a name for the command they represent, e.g. like this: easy.setActionCommand("easy").
The panel implements the ActionListener interface, and therefore must have the method actionPerformed overridden. Again, let’s look at the relevant parts of this method:
public void actionPerformed(ActionEvent e) {
final String action = e.getActionCommand();
if (action.equals("easy") || action.equals("hard")) {
if (!settings.difficulty.equals(action)) {
settings.difficulty = action;
settings.isDirty = true;
}
} else if (action.equals("classic") || action.equals("modern")) {
// and the same for the other radio buttons...
Here, we check which was the action command related to the action event. So if the command was “easy” or “hard”, we check if the related setting value is different, we then change it and also set the isDirty of the setting to true indicating a need to actually save the settings to the snakeses.ini file as seen above.
So far we have seen how the Settings class manages the settings file, and how the SettingsPanel displays the current settings, and then changes the settings based on user actions.
How the app then actually initializes the settings and saves them if they have been changed? This is done, in this app, in the SnakesesApp class that contains the main method of the app.
When the app is launched, the settings object is the first one to be created:
public static void main( String[] args )
{
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
new SnakesesApp().run();
}
});
}
private static SnakesesGame game;
private static Settings settings;
private static HallOfFame hallOfFame;
// Later...
private void run() {
try {
settings = new Settings();
settings.read();
hallOfFame = new HallOfFame();
hallOfFame.read();
game = new SnakesesGame(GameViewConstants.GAME_WIDTH, GameViewConstants.GAME_HEIGHT, settings);
// GUI
JFrame mainFrame = new JFrame("Snakeses");
// And the rest of the GUI is then created...
Things to note here: The app object contains the relevant application objects as member variables (game, settings, hall of fame). Also the GUI objects (frame, panels) are member variables, but left out from code snippet above since they are not relevant in this post.
As you can see, the settings are read from the settings file as the very first step of the application launch. Therefore, they are read from the file and available to the rest of the application immediately.
How about saving the settings? This could have been done in the SettingsPanel, but in this implementation it is done also in the SnakesesApp. The reason is, that changing some of the settings needs to be reflected in other components of the app. The method SnakesesApp.switchTo is called by the SettingsPanel when the close button is pressed. The app then switches back to the game view.
But before that, the app first checks if the settings were changed (isDirty is true), and saves the settings. App also instructs the hall of fame object to switch the hall of fame visible to the user, to the corresponding game difficulty level hall of fame data. This is because the game always shows the hall of fame for the current difficulty level only. This is shown in the code snippet below:
Other game objects and panels read the settings continuously as they do their things, so they need not to be updated the same way as the hall of fame needs to be. For example, the game panel that draws the snake and the food, uses the light/dark mode setting in painting the graphics each time the game screen is drawn:
public void paintComponent(Graphics g) {
super.paintComponent(g);
if (settings.mode.equals("dark") && getBackground().equals(Color.WHITE)) {
setBackground(Color.BLACK);
} else if (settings.mode.equals("light") && getBackground().equals(Color.BLACK)) {
setBackground(Color.WHITE);
}
// ....
Summarizing, we have now seen:
how the game settings and the settings file can be managed using the Java Property class,
how game settings panel can display and enable changing the settings,
how the app initializes the settings at lauch and how it saves the settings if they are changed in the settings panel,
how settings are used in the app when drawing the game screen, and
how changed settings can be propagated, if necessary, to other game elements like the hall of fame.
I implemented the classic Snake game (a.k.a “matopeli” in Finnish) using Java and Swing in retro style:
Why Java and Swing?
Originally, the idea was to implement something to demonstrate to students in our GUI design & implementation course. Namely, how to have one frame (window; JFrame) and be able to easily switch between different content views (JPanels) within that window, by using Swing CardLayout. And since Java and Swing are the default tools to use in this course (they can pick almost anything else they like, though), that’s why.
The game settings panel, hall of fame panel and the actual game view panel are all included in the same frame using the CardLayout. The demo also shows how to use keyboard shortcuts and buttons to switch between the three cards.
As usual for me, things got out of hand and I ended up implementing the whole game with all the features (I came up with). Unnecessary for the original purpose of the demo, but more fun than other more boring responsibilities, like various macrodata refinement types of tasks.
Since this app is “too complete” and could be used to copy-paste solutions in the course, the plan is not to publish this in source code. But parts of this can be included in (future) tutorials on how to:
use the CardLayout,
play the game using keyboard,
control the game using a Timer and TimerTask,
draw graphics on the screen,
store and restore settings using Properties, and
store and restore the hall of fame stats so that users cannot (at least easily) cheat by editing the hall of fame file manually.
The Hall of Fame file is scrambled using Base64 encoding and the Cesar cipher, so not actually rocket science. The scrambled Hall of Fame contents you can see in the video looks something like this, when scrambled:
Anyone could try out implement the same scrambling algorithms (since I have now revealed all the important secrets about it!) and attempt to “decrypt” the file and then manually put themselves at the top, then “encrypt” it back into the file. They can then be proud no one ever reaches the same level of gameplay again… Damn those clever cheaters! Luckily one can always delete the file and start from scratch.
Thanks for reading and have a nice rest of your day!
So, another long break in blogging. This, of course, is due to having too much work and spending the remaining energy somewhere else (like running).
So I thought I’d write a couple of posts on what I have been doing in between the previous post in January:
Evaluating the Data Structures and Algorithms course programming assignments. This has been faster this year, since my automated tool that both unit tests all the submissions and now also checks the source code that it doesn’t use things students are not supposed to use, and does use things they are supposed to use. Later I’ll make a post about the latest and future improvements to this tool. I still use too much time on this, due to lacking teaching resources, so the only ways to improve the situation are to add more automation and forget about giving detailed feedback to students.
Launching and supervising six BSc student projects. This started in January and will continue to end of April or May, depending on individual project schedules. Groups of 4-6 students show the skills and knowledge they (hopefully) acquired during their BSc studies and design and/or implement a software for an external (or “external”) customer. Sometimes they continue development of already existing software. I have weekly status meetings with them and guide them through the project, and participate in official steering group meetings.
Preparing and conducting our MSc program applicant interviews. This took most of the February, almost full day.
In March, the Programming 4 course started. The course focuses on GUI design, usability and user experience. I am assisting my colleague in this course. Students design and implement a GUI app, often the first time in their lives. Up to this point, they have usually implemented only small command line apps with relatively small number of functions or classes. This week is the last week of the course.
Supervising some BSc and MSc thesis students and
Preparing courses for teaching in Fall.
So, lots of work and thus no time for blogging, considering my priorities.
Anyways, I thought that in addition to listing the jobs above, I could also show some demonstrations I prepared for the Programming 4 course. The one described below in this post is a very simple and small demonstration showing how to use a Publish/Subscribe pattern to update GUI views when a data object (a model) in software changes state.
The old school way to do this is the Observer design pattern, which has it’s pros and cons — easy to use but has its negative consequences too. Classes related to that in Java have been deprecated though still usable.
Instead of Observer, Java recommends using other techniques, like the Publish/Subscribe pattern, using Java Flow Publisher and Subscriber interfaces and classes.
So, I implemented a simple demo app in Java and Swing, WallClockApp (GitHub link to source). The app uses the Publish/Subsctibe pattern and looks like this:
You can add several timezones using the plus button, and see the time in these different timezones. The red circle and cross button in each timezone can be used to remove a timezone. Obviously, the times advance with each clock, as seconds tick forward.
The app follows the also common Model-View-Controller architecture in GUI apps. In the app the Model (class ClockTickSource) is an object that provides the time signal, once a second. The View objects (class WallClock) are the different time zone views (three visible in the screenshot above). The app object (class WallClockApp) acts as the Controller, creating the model, and adding clock Views for user selected timezones. The Views basically just show the time in their corresponding time zones.
Where does the Publish/Subscribe then fits into this? Well, the Model needs a way to tell the views when a second has passed. So it has to know about the views that need the time tick signal. When the Model’s timer ticks, once a second, it then needs to notify the views so that they can update the time visible in their timezones.
This has been implemented here using the Java Publish/Subscribe pattern. The model is the publisher, that publishes the current time in one second intervals. The current time is published as the Unix time, milliseconds since Jan 1st, 1970, in UTC time.
Views, the Subscribers, subscribe to the Publisher as they are created:
public WallClock(final ClockTickSource clock, final TimeZone timeZone) {
super();
setLayout( new BorderLayout());
this.clock = clock;
this.timeZone = timeZone;
this.clock.subscribe(this);
On the last line above, you can see the View object subscribing to the clock ticks, calling the clock.subscribe. The Publisher (clock, the Model) then will notify the Subscriber about successful subscription and the View can then request for the clock ticks (Long values; the milliseconds from Jan 1st, 1970 UTC):
The Publisher then (code below) starts the clock ticking using a Timer, but only once, for the first subscriber (since only one timer is needed to run the show; see the start() method on details on how to launch the timer):
public void subscribe(final Subscriber<Long> subscriber) {
if (publisher == null) {
publisher = new SubmissionPublisher<Long>(ForkJoinPool.commonPool(), 10);
}
publisher.subscribe(subscriber);
if (publisher.getNumberOfSubscribers() == 1) {
start();
}
}
A concrete Java class SubmissionPublisher does the actual work here in the Publisher side.
Then the subscribers (views) handle the published data (Unix timestamps) as they get the notification from the Publisher when onNext is called by the Java Flow framework. The views will then convert the UTC time in milliseconds in the parameter item to their respective timezones and show that to the user:
public void onNext(final Long item) {
final long currentTime = item;
Date time = new Date(currentTime);
ZonedDateTime zonedTime = time.toInstant().atZone(timeZone.toZoneId());
timeLabel.setText(DateTimeFormatter.ofPattern("HH:mm:ss", Locale.getDefault()).format(zonedTime));
}
When the view closes (from the red circle/cross button), it needs to unsubscribe from the publisher, using the subscription.cancel():
You can get the rest of the details from the linked GitHub repository. This was a very small demo, just to show how the pub-sub works with the Java interfaces and classes. If you are interested in the details, head to the GitHub demo, clone it and check it out in action!
In the following posts I’ll show some other demonstrations and also write about the updates to the automatic DSA course testing/checking tool. Have a nice day!
So, you can use a Binary Search Tree (BST) to store and quickly access key-value pairs. Usually the key gives the position of the value element in the tree. You place smaller values in the left side, and larger values in the right side of the tree.
A sample BST unbalanced, having 13 nodes in the tree. Key in the BST is the person’s name in ascending order.
Finding by key value is O(log n) operation. Starting from the root node of the tree, comparing the key, you can choose which subtree to continue searching for the key. If the BST is balanced, you need to only do O(log n) comparisons at most to get to the key-value pair you wish to find. Like searching for Jouni Kappalainen takes four comparisons from the root and it is found.
The tree contents in key order shown in a Java Swing table view. Order is by BST key order.
Note that the numbers in each tree node picture above is the number of children of that specific node. For example, Kevin Bacon has zero children, as Samir Numminen has five, and the root node has 12 children.
How about if you want to treat the BST as an ordered collection, each item in the tree accessible by index, as you would do with an array? Like, “give me the 6th element in the tree (element at index 5), when navigating in-order, from smallest to largest key in the tree”. In the sample tree above, Kappalainen would be in the index 5 (zero based indexing). Kevin Bacon’s index would be zero since it is the first element in-order. Root node would be at index 1 in this sample tree.
The obvious thing to do would be to traverse the tree in-order, counting indices from the lowest left side node (Bacon) with index 0 (zero) and then continue counting from there until you are at the index 5 (Kappalainen).
Sample tree with in-order indices added in blue. Compare this to the GUI table order and you see the indices are correct.
This works, but the time complexity of this operation is O(n). If you have, let’s say a million or more elements in the three, that is a lot of steps. Especially if you need to do this repeatedly. Is there a faster way to do this?
The faster way is to use the child counts of the tree nodes to count the index of the current node (starting from the root), and then use that information to decide if you should proceed to left or right subtree to continue finding the desired index. This makes finding the element with an index O(log n) operation, which is considerably faster than linear in-order traversal with O(n).
For example, consider you wish to find element at the index 5. Since the root node’s left child has zero children, we can then deduce that the root node’s index is zero plus one, equals one. Therefore at the root you already know that the element at index 5 must be at the right subtree of the root. No use navigating the left subtree.
Also, when going to the right child from the root, you can calculate the index of that node, Töllikkö. Since Töllikkö is after the root node, add one to the index of root node, therefore the current index being two (2). Then, since all Töllikkö’s left children are in earlier indices, add the child count of Töllikkö’s left subtree, which is 8, to the current index, having current index of ten (10). And since the left child node must be counted too, not just its children, we add another one (1) to current index, it now being 11. So the index of Töllikkö is 11.
Now we know that since we are finding the index 5, it must be in the left subtree of Töllikkö, so we continue there and ignore Töllikkö’s right subtree.
Moving then to Kantonen, we need to deduct one (1) from the current index, since we moved to earlier indices from Töllikkä, current Index being now 10. This is not yet Kantonen’s index. We need to deduct the number of children in Kantonen’s right child + 1 from the current index, and will get 10 – 6, having 4. That is Kantonen’s index.
Since 4 is smaller than 5, we know we need to proceed to the right subtree of Kantonen to find the index 5. Advancing there, in Numminen, we need to add 1 to the current index since we are going “forward” in the index order to bigger indices, as well as the count of children + 1 (the subtree itself) in Numminen’s left subtree, in so current index (Numminen’s) is now 6.
Since 6 < 5 we know to continue searching the index from Numminen’s left subtree there we go (to Kappalainen), deducing one (1) from current index, it now being 5. Now, earlier, when moving to left (to Kantonen), we also deducted the number of children in Kantonen’s right subtree. But since Kappalainen has no right subtree, we deduct nothing.
Now we see that current index is 5, the same we are searching for. So, we can stop the search and return Kappalainen as the element in the index 5 in the tree.
Using this principle of knowing the count of children in each tree node, we can directly proceed to the correct subtree, either left or right, and therefore replacing the linear in-order search with faster logarithmic search. With large data sets, this is considerably faster.
While demonstrating this to students using the course project app TIRA Coders, we saw that loading 1 000 000 coders to the course TIRA Coders app, the O(n) index finding operation (required by the Java Swing table view) made the app quite slow and sluggy. When scrolling, the app kept scrolling long time after I lifted my hand off the mouse wheel. Swing Table view was getting the objects in the visible indices constantly while scrolling and as this is O(n) operation, everything was really, really slow.
When replaced by the O(log n) operation described above, using the app was a breeze even with the same number of one million data elements in the BST; there was no lags in scrolling the table view nor in selecting rows in the table.
So, if you need to access BST elements by the index, consider using the algorithm described above. Obviously, for this to work, you need to update the child counts in parent nodes while adding nodes to the BST. If your BST supports removing nodes and balancing the BST, you need to update the child counts also in those situations.
(I won’t share any code yet, since the students are currently implementing this (optional) feature with the given pseudocode in their BST programming task.)
Just checked out for my Computers and computer networks course that there is no more sadness since the Willab weather service works again!
The API has changed from HTTP to HTTPS, and the JSON data structure returned has also changed a little. So I needed to change the demoapps that get the current weather from the service.
This week I’ve again taught how to use curl from the command line, how to see the HTTP traffic using Wireshark and how the two demo apps do HTTP GET to access the weather data from the service.
When going through some course projects, there were some deliverables using a SQL database.
If you are just hacking something to quickly test or demonstrate a thing, you do not necessarily have to do things as they should be done. Course projects are usually not quick hacks, but should demonstrate the things you have been taught and things you have actually learned.
So, for course projects using SQL databases, this means that you should do things so that the database is not exposed to simple SQL injections. Or that you should actually encrypt confidential data, such as passwords saved in database tables.
Why I am being such an asshole, expecting these to be done properly in student course projects?
Because the way you implement things, demonstrates what you have learned. Demonstrating that in course projects is kind of expected.
The things you learn going through the study program courses, should be carried on from course to course, accumulating skills and knowledge.
Because the things you consistently design and implement, is embedded into your deeper knowledge and skills and is then easier to take into use when needed in real life settings.
Because when knowing at least the basics of these things, you perhaps do not expose real apps and systems to these vulnerabilities when you go to work in the industry. Something that happens way too often…
So, if you do use a SQL database in your course work, do the basic things the way they should be done. Use prepared queries instead of exposing the app to SQL injections. Encrypt the confidential data, at least the user passwords.
I made a demo app to show how this is done, and a (Finnish) YouTube video to demonstrate the things in action to anyone learning database programming basics.
Yes, I know this demo app is not perfect either. But the idea is to demonstrate (simply) how to consider these very basic, small things in database programming. Small things that still have a considerable impact on app security.
Next Fall is the fifth time when I teach the course Data Structures and Algorithms. I received the course on 2019 and after a year of familiarising with the course, started developing it.
First I switched from C to Java and implemented automated unit tests to verify the correctness of student implementations. Some unit tests also measured time performance with varying numbers of n. The measurements were then used to support the time complexity analysis of the implementations, in addition to analysing the pseudocode and implemented algorithms. Comparing the implemented fast algorithms and data structures to slower ones was also one of the things students did.
All this to support the students to learn to see the difference between algorithms and helping them to decide which algorithm or data structure to use in whatever situation. Many times a simple algorithm suffices and simple array and plain loops are enough. But sometimes, something more is needed.
In the last two years, one or two exercise tasks had a graphical user interface (GUI) instead of a console UI, most of the tasks have. The feedback from the students was that seeing the actual effect on using faster and better data structures and algorithms in a GUI was a very nice thing to have. It really gave them a tangible view on the benefits of using these algorithms (like partitioning a large array) and data structures (finding a path using Dijkstra’s algorithm in a maze game).
Based on this student feedback, I decided to implement a GUI to all exercise tasks for the Fall 2023 course. The experiment I want to make is to see if having a GUI helps in motivating the students to work on and learn from the course exercises, compared to the more common console UIs and seeing the results of unit tests passing (or not).
Yesterday the first version of the GUI was finished, including all the exercise tasks to teach concepts like:
sorting an array with simple (and slow, with large n) insertion sort algorithm,
sorting to both ascending and descending order using the Java Comparator interface,
searching using linear search algorithm,
after sorting, implementing faster search using binary search,
implementing a Stack to verify a JSON file has no issues with parentheses nor quotation characters,
implementing a Queue to implement a “call list” (either using an array or a linked list as the internal data structure of the Queue),
when dealing with larger data sets, using faster sorting algorithms like quick sort, heap sort or merge sort,
to make handling large data sets faster in adding data elements and searching for them, using a binary search tree as the data structure,
using a hash table to count the number of unique words used in a text file and list the top 100 words with counts (a classical problem in data structures and algorithms), and finally,
using a graph data structure and associated algorithms (like Dijkstra’s) to find a shortest path between two data items.
So in addition to the already existing unit tests and time efficiency measurements, to verify the correctness and time performance of their data structure and algorithm implementations, next Fall they will also see these working in a “real life” application, the TIRA Coders Phonebook app:
TIRA Coders Phonebook app screenshot
Each of the smaller windows and dialogs appear when the feature is used from the menu of the application.
On the lower right corner, there is a log window displaying time performance data when executing the different algorithms; filling the data structures, sorting the data, searching for data, etc.
Students are able to load phonebooks of different sizes, from 100 coders up to 1 000 000 coders, and see how their implementations of different data structures and algorithms cope with various numbers of n.
I still need to work on this app more, making sure that when I remove all the solutions for the data structures and algorithms I’ve implemented, the app is still functional enough to be a starting point for the students to start working on the course exercise tasks.
I also need to carefully point to the students the parts of the code they need to work upon, and parts of the code they do not need to care about, not to get confused by the things not relevant in learning the course topics.
It will be exiting to see, in a couple of months, how this works out and if having the GUI helps in learning or motivates students to work on the tasks.
