Project 13 — Java Migration

“For we walk by faith, not by sight.” — 2 Corinthians 5:7

“The languages change. The problem doesn’t.” — every programmer who has switched languages

Chapter: 13 — Shifting Gears: Hello, Java Due: End of Week 13 Submit: A link to your code — an OnlineGDB project URL or a public GitHub repo URL containing all .java files for your chosen tier’s port. See Appendix D for the full workflow. (Normal-tier students will ship StewardshipAccount.java + Demo.java; Medium-tier students ship the multi-file Library port; Hard-tier students ship the Chain port or, alternately, the Argument Case File port — see the rubric below.) Allowed tools: Everything from Chapters 1–13.

The Setup

You have shipped, by now, twelve C++ projects. You know how to build classes, manage memory, write linked lists by hand, and orchestrate polymorphic hierarchies.

This week, take one of those projects and rebuild it in Java.

The point isn’t to learn anything you don’t already know. The point is to feel, in your hands, the difference between a language that hands you responsibility (C++) and a language that holds responsibility for you (Java). At Normal tier, the migration is structural — same classes, same methods, slightly different syntax. At Medium tier, you also gain access to Java’s ArrayList and watch the fixed-size-array plumbing disappear. At Hard tier, you keep one piece of plumbing — a hand-built linked list — and notice that even with garbage collection, the design of references is still there.

You will also write a short comparative document called migration-notes.txt calling out what you noticed.

Learning Targets

By completing this project, you will demonstrate that you can:

• Translate a working C++ program into idiomatic Java.
• Identify which C++ responsibilities Java handles automatically.
• Identify which design responsibilities remain in any language.
• Use Java’s ArrayList<> appropriately.
• Use Java’s class file conventions (one public class per file).
• Articulate, in writing, the tradeoffs between the two languages.

Normal Tier

Goal: Port Project 9 (Stewardship Account) to Java. Same features. Same rules. Idiomatic Java syntax.

Required features

1. One .java file per public class. At minimum: StewardshipAccount.java (the class) and Demo.java (the main).

2. The class API:

   public class StewardshipAccount {
       private double balance;
       private String owner;
   
       public StewardshipAccount(String owner, double starting) { ... }
       public void deposit(double amount) { ... }
       public void give(double amount) { ... }
       public void spend(double amount) { ... }
       public void printStatement() { ... }
       public double getBalance() { ... }
   }

   Same behavior as your C++ Project 9. Same guard clauses. Same rejection messages.

3. A Demo class with a main that exercises at least 8 operations across at least 2 accounts, including at least one rejected operation.

4. Compile and run cleanly:

   javac StewardshipAccount.java Demo.java
   java Demo

   No warnings, no exceptions.

5. No direct field access from Demo. All interaction goes through public methods.

6. migration-notes.txt — at least 5 specific observations comparing this Java version to your C++ Project 9. Examples of what counts as a “specific observation”:

   • “In Java I didn’t have to write a destructor; the GC handles cleanup.”
   • “I had to put the class in its own file, which I didn’t have to in C++.”
   • “Java forced me to write new Account(...) explicitly; I couldn’t declare on the stack.”
   • “Comparing the owner string required .equals(), not ==.”

Generic “Java is automatic” doesn’t count. Specific moves and where they showed up does.

Normal-tier rubric (out of 100)

Medium Tier (+up to 25% extra credit)

Goal: Port Project 10 (Apologetics Library) to Java instead. Use Java’s ArrayList<> where you had fixed-size arrays in C++.

Required features

1. Three classes, each in its own file: Book.java, Member.java, Library.java. Plus Demo.java for the main.

2. Use ArrayList<Book> and ArrayList<Member> inside the Library class — not fixed-size arrays.

3. Use ArrayList<String> inside the Member class for borrowed titles.

4. Implement everything from your C++ Project 10 Normal-Medium tier:

   • Books with title, author, available flag.
   • Members with name and borrowed titles list.
   • Library that owns both, with addBook, addMember, findBook, findMember, printSummary.
   • Title uniqueness enforced on add.

5. Use .equals() for string comparisons throughout. Document one specific place where this caught a bug for you.

6. migration-notes.txt for the Medium tier should additionally note:

   • At least 2 places where ArrayList<> simplified what you had to do manually with fixed-size arrays in C++.
   • At least 1 place where Java’s stricter file/class conventions affected your design.

Medium-tier additional points (+25%)

• ArrayList used correctly: +10
• Three-class composition working: +10
• Updated migration-notes covering ArrayList wins: +5

Hard Tier (+up to 25% additional extra credit)

Goal: Port Project 11 (Chain of Witnesses) to Java. Build the linked list by hand — no LinkedList<> from java.util.

Required features

1. Two files: Chain.java (with nested Node class) and ChainDemo.java.

2. Nested Node class declared inside Chain as a private static class:

   private static class Node {
       String name;
       int century;
       String testimony;
       Node next;
   }

3. Chain class methods mirror your C++ Project 11 Normal tier: add, remove, print, size.

4. No LinkedList<> or any other collection-class shortcut. Build the chain with hand-managed Node references.

5. No destructor needed — the GC handles it. Note this in your migration-notes.

6. Seed data with at least 8 real witnesses (carry over from your C++ Project 11 — same attributions, same testimonies, same data).

7. migration-notes.txt for Hard tier additionally explains:

   • What GC freed you from — specifically what code you didn’t have to write that you did write in C++.
   • What GC did NOT remove — specifically, the design responsibility of pointer/reference handling is still there. You still set node.next = oldHead. You still walk the chain by following references. The garbage collector doesn’t excuse you from understanding the data structure.

This last paragraph is the apologetic point of the entire course: tools change; the skill of careful thinking does not.

Hard-tier additional points (+25%)

• Hand-built linked list working: +15
• Comparative analysis of GC vs. manual memory in migration-notes: +10

Alternate Hard tier (Polymorphism focus)

Goal: Port Project 12 (Argument Case File) to Java instead of Project 11. Same Hard-tier point ceiling (+25%); pick this path if you’d rather feel polymorphism switch languages than feel manual memory switch languages.

P12 is the most polymorphism-rich C++ project in the course — an Argument base with multiple derived subtypes and a polymorphic collection. The Java port lets you replace the C++ scaffolding (virtual, virtual destructors, slicing precautions, owning pointers) with Java’s defaults: every method virtual, @Override, polymorphic ArrayList<Argument>, reference semantics throughout.

Required features

1. All public classes in their own files, matching their public class names. At minimum: Argument.java (base), one file per derived Argument subtype, and Demo.java (with main).

2. extends for the inheritance hierarchy, @Override on every overridden method, and an ArrayList<Argument> that holds the polymorphic collection.

3. All features from your C++ Project 12 Normal–Medium tier, ported to Java. Same data, same behaviors, same output shape.

4. No instanceof/cast in the main dispatch loop. Polymorphism does the work; if you find yourself reaching for instanceof, that’s a sign the method should have been virtual on the base.

5. migration-notes.txt for this alternate Hard tier additionally explains:

   • What slicing-related concerns disappear in Java because of reference semantics. Be specific: name the C++ code in your P12 that existed to prevent slicing (passing by reference/pointer, virtual destructors, etc.) and what dropped out of the Java port.
   • What design responsibilities remain in either language — picking the right base methods, the right virtual surface, the right collection element type.

Alternate-Hard rubric (+25%)

• Inheritance hierarchy ported with @Override everywhere: +10
• Polymorphic ArrayList<Argument> in the main loop, no instanceof: +10
• Slicing-disappears analysis in migration-notes: +5

You may submit either the Project 11 Hard port or this Project 12 alternate-Hard port for full Hard credit. Not both — pick the one that better fits your remaining time and the lesson you want to internalize.

Submission

Submit one URL via the course portal:

• OnlineGDB project link (recommended for Coding 1 and Coding 2). Create your project at onlinegdb.com, choose Java as the project language, build your solution, and share the link. See Appendix D for the full workflow.
• GitHub repo link (optional). If you’ve set up local development on your own (see Appendix B), push the source to a public repo and submit that URL. You’re responsible for making sure the code compiles with javac *.java when the grader checks it out.

What the linked project must contain

1. Your Java source files — whatever the public class names of your solution require. For example, a port of Project 9 would have StewardshipAccount.java and a Demo.java (or whichever class holds main). Filenames must match public class names exactly.
2. A reflection comment block at the very top of the file containing main:

/*
 * Tier targeted:    Normal / Medium / Hard
 * Features done:    list each feature you completed
 * What I learned:   one short paragraph (no bullets)
 * What I'd change:  one sentence
 * AI usage:         where and how, if any. Be honest.
 */

3. The program left in a “demonstrable” state — when the grader presses Run, the features for your targeted tier should be exercised. Hard-code inputs at the top of main() (or pre-fill OnlineGDB’s Stdin panel) so the grader doesn’t have to guess what to type.

4. Your migration-notes — as a long /* ... */ comment block at the top of Demo.java (or whichever class holds main), or as a migration-notes.txt file in your GitHub repo if you went that route. Use the template below.

That’s it. No separate demo.txt. No screenshots. The instructor will open your link, read both comment blocks, run the program, and grade against the rubric.

Coach’s Note — Coding 1 and Coding 2 focus on writing code, not managing development environments. If something behaves oddly, you and the grader are looking at the exact same browser-hosted environment — there are no “works on my machine” defenses by design. Coding 3 will introduce a local toolchain properly.

migration-notes template

MIGRATION NOTES — Project 13

## Things Java does for me that I had to do in C++
- [observation 1]
- [observation 2]
- ...

## Things Java made me do that C++ did not require
- [observation 1]
- [observation 2]
- ...

## Things that did NOT change between the two
- [observation 1]
- [observation 2]
- ...

## What I learned about transferable programming skill
[One paragraph of your honest reflection. The course's claim is that the
skill of programming is language-independent. Did your experience support
that claim or undermine it? Be specific.]

The total length should be 400–800 words. Bullet lists are fine for the first three sections; the last must be a paragraph.

Hints

• “My filenames are wrong and javac is yelling.” Filename must match the public class name exactly. StewardshipAccount.java for public class StewardshipAccount. Case-sensitive.
• “My main is in the wrong place.” Java’s main lives inside a class, marked public static void main(String[] args). The class containing main is the one you pass to java: java Demo, not java Demo.java.
• “My string comparison is doing something weird.” .equals(). Always. Never == on strings.
• “My ArrayList<int> won’t compile.” Use ArrayList<Integer>. Generics need object types.
• “I’m tempted to use LinkedList<>.” Don’t. The whole point of Hard tier is to verify that you understand references without the library doing it for you.
• “How long should this take me?” Normal: 4–7 hours. Medium: 7–11 hours. Hard: 11–18 hours.

What Mastery Looks Like

A great Project 13 has idiomatic Java, not C++-pretending-to-be-Java. Capitalize Strings. Use ArrayList where appropriate. Use .equals(). Annotate @Override on overrides. Don’t write a destructor; don’t allocate-and-free manually.

A great Project 13 has migration-notes.txt that says something specific. “Java auto-boxes Integer” is not enough. “When I added ArrayList<Integer> to track per-member borrow counts in Project 10, I had to auto-unbox via .intValue() when doing arithmetic; that’s a place where the wrapper-class abstraction leaked” is the right kind of observation. Be a writer.

A great Project 13 carries the data. If you ported Project 11, the Chain of Witnesses still contains real witnesses with real testimony. The data is the data is the data. Languages change; the historical record doesn’t.

A great Project 13 is smaller than the original. Java versions of C++ programs are usually slightly smaller — less ceremony around memory, less plumbing. Your README should comment on this.

When You’re Done

1. Read every .java file aloud. Does it sound like Java, or like C++ in disguise?
2. Compile, run, exercise every feature. Anything break?
3. Read migration-notes.txt aloud. Is each observation specific?
4. Update README.
5. Submit.
6. Read Chapter 14. Polymorphism in Java.

Coach’s Note — This is the project where your hands prove the course’s thesis. You’ve now written the same essential program in two languages. The classes line up. The methods line up. The logic line up. The syntax differs in small specific ways. The skill of the program — articulating a careful idea clearly — is identical. If you can feel that, you’ve gotten what this course has been after.

See you on Monday.