Option 1: free project

Option 1: free project #

The first possible type of group projects is for students to develop a Java application of their choice.

This application is only a prototype, so it does not need a comprehensive list of features or functionalities.

The evaluation of the project will be mostly based on its backend (rather than the frontend). This means that the application:

  • does not need a graphical user interface (but may have one),
  • should perform non-trivial backend task(s) (e.g. writing and/or reading to/from files is not sufficient).

Guidelines #

Motivation #

A good projects is driven by an idea.

Feel free to design your application so that it matches your own interests. For instance:

  • relate it to a hobby (music, cinema, fashion, sport, games, social media, astronomy, etc.),
  • use the project as an opportunity to explore a topic that you are curious about (natural language processing, computer vision, recommender systems, robotics, etc.),
  • develop a functionality that one of your favorite applications is missing.

Do not hesitate to be ambitious at first. You can restrict the scope of your project (to certain features or components) later on.

Specification #

A frequent source of failure for this course is students focusing on tools (e.g. following tutorials) without having a precise objective. The short deadline (June 2025) does not give you this flexibility. Besides, without a precise objective, the amount of libraries that are available to you (especially in Java) can be overwhelming.

So we recommend you to clarify what your application should do, before thinking about how you could implement it. In other words, specify which problem(s) (i.e. input and expected output) your program and/or components should solve. Then only think about algorithms, libraries, tools and/or tutorials that can help you solve these problems.

In order to determine whether your specification is precise enough, you may check whether it leaves some doubt as to whether an output is correct or not.

User interface #

Developing a Graphical User Interface (GUI) requires familiarity with a graphical framework. Learning the details of such a framework (terminology, syntax, setup, etc.) can be an important time investment, and this knowledge may not transfer to other graphical frameworks. In other words, developing a GUI may not require lot of thinking, but a lot of reading (and web browsing).

Beware also that GUIs technologies are still rapidly evolving, and that recent innovation has largely been driven by web development. So learning a graphical framework for Java may not be a strategic investment of your time (compared to learning a Javascript framework like React or Angular). Note that even desktop and mobile applications are increasingly relying on web technologies for their GUIs (thanks to frameworks like Electron or React Native).

This is why we recommend you to think carefully before committing to a Java GUI, and to keep it minimal if you do. Note also that we will not evaluate your project based on aesthetic criteria.

So in order to design your interface, you may follow the following guidelines:

  1. Ask yourself whether your application really needs a GUI. A command-line interface (CLI) may be sufficient, because:
  • your program takes files as input and produces files as output, or
  • your program is (primarily) meant to be used by other programs (rather than human beings), or
  • your program is meant to be used by other developers, or
  • external programs with GUIs (such as IDEs) can easily call your application, or
  • you leave the GUI for future work (again, your application is just a prototype),
  • etc.
  1. If you really need a GUI, then:
  • decouple frontend and backend (whenever possible), so that the backend could be used with another frontend, and conversely. Many applications accessible via GUI have a natural decoupling of frontend and backend.

Example. Consider an application that allows booking hotel rooms. The backend takes as input some data (e.g. number or guests, arrival date, departure date, etc.), and outputs data as well (available rooms, prices, etc.). These input and outputs are objects, integers, strings, etc. They do not depend on a specific GUI (windows, menus, buttons, colors, etc.).

Example. Even for some games, frontend and backend can easily be decoupled. Consider for instance a program that plays chess against a human opponent. The backend:

  • keeps track of the current state of the board,
  • takes as input either a move from the white player, or a request to play as the (bot) black player,
  • outputs the next state of the board.

These input and output do not depend on a specific GUI (they can for instance be encoded using algebraic notation). So the backend can be implemented without any reference to graphical elements or controller inputs (mouse clicks, etc.).

  • develop the backend first (and write unit tests for it),

  • develop the frontend afterwards (if you have time for it).

  1. If you really need a GUI, then try to keep it minimal. In particular, restrict the input to what is essential for your application (the more freedom the user is given, the more likely he/she is to input a sequence of actions that your program cannot handle).

Illustrations #

Here are some examples of (past and imaginary) possible projects:

  • a program that detects texts generated by a large language model,
  • a program that takes as input a dataset of Tweets and identifies communities and/or influencers based on the network formed by re-tweets,
  • a program that retrieves news articles about an input topic (using web APIs), and analyses their polarity (via sentiment analysis) together with their provenance (news outlet, country, etc.),
  • a (toy) recommender system,
  • a program that generates (solvable) sudoku grids with different sizes and/or level of difficulty,
  • a game to help people improve their typing speed,
  • a web crawler that retrieves sport-related statistics from various websites and exposes them via a web API,
  • a classroom reservation system for the Unibz that can computes a default schedule for a whole semester, satisfying a set of constraints (room capacity, etc.) and/or preferences (minimize days of presence per week of a same group, etc.),
  • a flashcard app that incorporates answers produced by a chatbot,
  • an (Obsidian-like) note management application,
  • a program to organize and manage coding contests (similar to this one),
  • a password manager (with encryption), for instance similar to pass, where password update and synchronization are performed via git,
  • a program that analyzes the commit and/or branching history of a git repository (e.g. contributions of the different users, frequency of commits, percentage of preserved code, etc.).