Back to work

Java desktop exercise · public source

Currency Converter

An early single-window Java Swing exercise covering desktop layout, user input, event-driven execution, currency selection, static-rate arithmetic, and invalid-number handling.

Java developerPublic learning project
View source
architectureSwing form → ActionListener → conversion function → result state

3

selectable currencies

2

static base rates

1

desktop window

2

Harshitha-authored commits

The system

From operational problem to reliable workflow.

Problem

The project was a compact way to practice object-oriented structure, desktop widgets, event listeners, numeric parsing, branching conversion logic, and UI error feedback in Java.

Approach

A JFrame owns the amount field, source and target currency selectors, convert button, and result label. An ActionListener parses the amount and calls a dedicated conversion method using static USD-to-EUR and USD-to-GBP rates.

Outcome

The repository captures an early event-driven desktop application and a clear separation between UI setup, click handling, and arithmetic, with an intentionally limited three-currency scope.

Architecture

System architecture

This is a small learning project, not a live foreign-exchange product. Its value is the direct use of Java's desktop UI and event model in one inspectable source file. Rates are constants, there is no provider API, and the conversion matrix is intentionally incomplete.

Desktop shell

Owns the application lifecycle, window title and size, close behavior, and visibility on Swing's event-dispatch thread.

JFrame · SwingUtilities.invokeLater

Input form

Collects an amount and source/target denominations through one text field and two combo boxes arranged vertically.

JPanel · BoxLayout · JTextField · JComboBox

Event boundary

Runs conversion only after an explicit button click and catches malformed numeric input before arithmetic.

JButton · ActionListener · NumberFormatException

Conversion function

Chooses a static rate from nested source/target branches and multiplies the parsed amount by that rate.

Java switch statements · double arithmetic

Execution model

End-to-end execution

  1. 01

    Launch on the UI thread

    The main method schedules construction and visibility through `SwingUtilities.invokeLater`.

  2. 02

    Capture amount and denominations

    The user enters a numeric amount and selects USD, EUR, or GBP in the source and target combo boxes.

  3. 03

    Handle the click

    The ActionListener calls `convertCurrency`, which parses the text and reads the selected combo-box values.

  4. 04

    Select and apply a rate

    The conversion function selects a static branch and returns `amount × rate`; malformed amounts are caught and reported in the result label.

Implementation

What Harshitha implemented

  • Extended `JFrame` to keep window state and UI construction inside one application class.
  • Created a vertical form with labeled amount input, source currency, target currency, action button, and result label.
  • Used an anonymous `ActionListener` to connect the button event to application logic.
  • Separated input parsing in `convertCurrency` from rate selection and arithmetic in `convert`.
  • Defined USD-to-EUR and USD-to-GBP constants and same-currency fallback behavior.
  • Caught `NumberFormatException` and surfaced an actionable invalid-number message instead of allowing the event handler to fail.

Contribution summary

  • Built the JFrame application and BoxLayout-based form using Java Swing and AWT event APIs.
  • Connected the Convert button to numeric parsing and a dedicated conversion method through an ActionListener.
  • Implemented USD, EUR, and GBP selection with static conversion constants and a same-currency fallback rate.
  • Handled non-numeric input by replacing the result label with a direct validation message.

Failure design

Reliability engineering

R01

Risk

The amount field contains non-numeric text.

Control

Numeric parsing is wrapped in a `try/catch`, and the result label shows a validation message.

R02

Risk

UI construction runs off Swing's event-dispatch thread.

Control

The application launches through `SwingUtilities.invokeLater`.

R03

Risk

Static rates are mistaken for live market values.

Control

The portfolio labels the project as a learning exercise and states that no exchange-rate API is connected.

R04

Risk

Unsupported cross-rate branches produce misleading output.

Control

The case study discloses the incomplete conversion matrix rather than presenting the snapshot as production-ready finance software.

Tradeoffs

Technical decisions

Use Swing instead of a web UI

The learning goal was Java object-oriented and event-driven desktop programming without a server or browser runtime.

Keep rates as constants

Static values keep the exercise focused on UI events and arithmetic, at the cost of freshness and complete cross-currency behavior.

Separate conversion from click handling

A dedicated arithmetic method is easier to inspect and later replace with a complete rate table or provider adapter.

Credibility

Evidence and scope

Harshitha-authored public source

Both repository commits are attributed to Harshitha, and the complete implementation is visible in one Java file.

Explicit project limits

The snapshot has no live-rate API, persistence, tests, localization, or complete conversion matrix; it is presented as an early Java exercise.

Attribution boundary

This is an early educational desktop application with static rates and incomplete production behavior. The portfolio claims the Swing UI, event handling, parsing, branching arithmetic, and validation that are visible in source—nothing more.

Technology

JavaSwingAWT events