Banking System (Console)
Never store money in a double — and the program proves it while you watch.
- Java
- BigDecimal
About this project
A console banking system: open accounts, deposit, withdraw, transfer, print a statement, credit interest and audit the books. Plain Java — `javac *.java` and `java Bank`, with no build tool, no library and no database.
The idea it is built around is that money is never a double. 0.1 + 0.2 is not 0.3 in Java any more than anywhere else, and menu option 9 computes the whole argument live: ten deposits of ten paise leaving 0.9999999999999999, a customer refused their last ten paise because the balance is really 0.09999999999999998, and four standard-library ways of rounding one charge of Rs 1.005 that do not agree with each other. Every figure on that screen is computed as the program runs, so none of it can quietly go stale.
The second theme is encapsulation as a safety property. The balance is private and changes only through methods that enforce the rules, so no code path can set an account negative. A transfer either completes on both sides or happens on neither, and the audit checks every balance against its own ledger — the property a bank would actually care about.
What you will learn
- Use BigDecimal with an explicit scale and rounding mode for money, and know why double fails
- Treat encapsulation as a safety property rather than ceremony
- Keep a transfer atomic, so it can never debit one account without crediting the other
- Reconcile a balance against its own ledger, which is what an audit actually is
- Model refusals as exceptions carrying enough detail to explain themselves
Before you start
- Java basics — classes, methods and exceptions
- JDK 17 or newer. No build tool, no library, no database.
New to Java? The free Java course covers everything this project assumes.
Academic integrity notice
These projects are provided for learning, experimentation and reference. Understand the code, modify it for your own requirements, and acknowledge external work according to your institution’s academic policies. Priodemy does not supply work to be submitted as your own.
Features
- BigDecimal money with a fixed scale and rounding policy in one place
- A live demonstration of double precision loss, computed at runtime
- Atomic transfers, with the bank total printed before and after
- An audit that reconciles every balance against its own transaction ledger
- Refusals that explain themselves — overdrawing tells you how short you are
- Indian digit grouping and ASCII-only output, so a Windows console renders it correctly
Technology stack
Track: Java · Level: Starter
What is included
- Money.java, Transaction.java, Account.java and Bank.java — commented throughout
- A README on BigDecimal, encapsulation and transfer atomicity
- Suggested extensions, including replaying the ledger from a file and a test class
Delivered as a 31 KB ZIP. SHA-256 published under Changelog so you can verify it.
System requirements
- Operating system
- Any
- Runtime
- JDK 17 or newer. javac and java only — no Maven, no Gradle, no library.
Licence
Learn from it, change it, and use it in your own coursework and personal projects. Do not resell it or pass it off as your own original work.
- Personal and educational use
- Modifying the code however you like
- Using it as the basis of your own coursework, with honest acknowledgement
- Putting your modified version in a portfolio or on your own GitHub
- Reselling or redistributing the project, modified or not
- Presenting it as your own original work
- Commercial deployment — see the Commercial licence
Support window: 6 months from download.
Frequently asked
Why BigDecimal instead of double?
Because a double is a binary fraction and a rupee is not. Run menu option 9 and the program shows you: ten deposits of ten paise leave 0.9999999999999999, which prints as 1.00 and is not 1.00. Every number on that screen is calculated as it runs, so you can change the code and watch it change.
Does it use a database?
No, deliberately. Everything is in memory and the program says so when it closes. Adding persistence is the second suggested extension, and the README explains why you should save the ledger and rebuild the balances rather than saving the balances.
Will this pass as a college submission?
It is the right scope for a first Java project, and BigDecimal, encapsulation and atomicity are all examinable. Understand the transfer logic well enough to explain what happens if the credit fails, extend it, and write your own report.
Changelog
- First release
SHA-256336a1370c998a951bc5f20f7e47a6fe3934bd3d385e4b9bf01002ea0161a3ea2