2. String List v2026.sp¶

Notice

This document contains the description for the String List project assigned to the students in the Spring 2026 CSCI 1302 classes at the University of Georgia.

2.1. Project Deadlines¶

This String List project is broken up into three parts, and each part has its own deadline. The deadlines for each part are summarized in Table 2.1, and instructions are provided in the Project Checklist section later in this document.

Table 2.1 String List Deadlines¶
Part	Due Date
1	Friday, March 6^th @ 11:55PM
2	Friday, March 20^th @ 11:55PM
3	Wednesday, March 25^th @ 11:55PM

To earn full points, you are required to submit all three parts. If you want extra credit, then complete and submit the first and / or second parts before their deadlines, as explained in the drop-down below.

2.2. Project Preface¶

This second CSCI 1302 project for Spring 2026 is designed to help you apply and extend your prerequisite Java programming knowledge with new concepts from CSCI 1302 in a Unix development environment (i.e., Odin).

Course-Specific Learning Outcomes

If you work on and complete this project, then you will gain exposure and practice with the following learning outcomes:

#	Exposure	Description
LO1.c	⭐⭐	Create and modify text files and source code using a powerful terminal-based text editor such as Emacs or Vi.
LO1.d	⭐⭐	Use shell commands to compile new and existing software solutions that are organized into multi-level packages and have external dependencies.
LO2.a	⭐	Identify redundancy in a set of classes and interfaces, then refactor using inheritance and polymorphism to emphasize code reuse.
LO2.b	⭐⭐	Define, throw, and propagate exceptions appropriately in a software solution.
LO3.a	⭐⭐	Create and update source code that adheres to established style guidelines.
LO3.b	⭐	Create class, interface, method, and inline documentation that satisfies a set of requirements.
LO4.c	⭐	Design, create and use inheritance relationships in a software solution.
LO7.c	⭐	Use common abstract data types and structures, including lists, queues, arrays, and stacks in solving typical problems.

2.3. Project Description¶

In this project, you are tasked with writing and testing the code for two classes that each implement, in their own unique way, the Abstract Data Type (ADT) defined by the StringList interface.

Introduction to String List Objects

Note: Packages included in cs1302-str-list.jar

Several of the UML diagrams in this project description include packages with a <<jar>> stereotype. For example, when a package includes the <<jar>> stereotype (like the one shown in Fig. 2.1), you should assume that package, including its classes and interfaces, are provided for you in the cs1302-str-list.jar file that is included in the project’s starter code.

You do not and must not recreate the classes and interfaces in these packages since they are already provided for you.

!includesub cs1302-str-list.puml!STYLE

package cs1302.adt <<jar>> {

} — Fig. 2.1 A UML diagram depicting a Java package that is included in the `cs1302-str-list.jar` file, as denoted by the inclusion of the `<<jar>>` stereotype displayed near the top of the package.¶

The Implementing Classes

In this project, you will implement the StringList interface two different ways. While both implementations will behave the same way from an outside perspective, each one will manage the storage data structure for its list items in a completely different way, as summarized in Table 2.2.

Table 2.2 Implementing classes and their storage data structures.¶
Implementing Class	Storage Data Structure
`ArrayStringList`	A simple, one-dimensional array object.
`LinkedStringList`	A linked list of `Node` objects.

Instead of writing every method two times (i.e., once for each class), you will create an abstract parent class named BaseStringList that will include some instance variables and methods that are common to both implementations.

A small UML diagram depicting how these classes are related is provided below in Fig. 2.3, and a more detailed UML diagram that includes the methods you are expected to include in each class is provided later in the project’s functional requirements section.

!includesub cs1302-str-list.puml!STYLE

package cs1302.adt <<jar>> {
interface StringList <<interface>>
class Node
}

package cs1302.p2 {
abstract class BaseStringList <<abstract>>
class ArrayStringList
class LinkedStringList
}

BaseStringList .up.|> StringList : implements
ArrayStringList -up-|> BaseStringList : extends
LinkedStringList -up-|> BaseStringList : extends
LinkedStringList -up-> Node : dependsOn — Fig. 2.3 UML diagram depicting the relationships between the classes and interfaces in the `cs1302.p2` and `cs1302.adt` packages. A more detailed version of this diagram that includes the instance variables and methods for each class and interface is provided in the project’s functional requirements section.¶

Tip

This project involves an interface, inheritance, and several classes, all of which can look daunting at first. Please take your time and read this entire project description before starting the project and be sure to follow the instructions for completing each part as they are described in the Project Checklist. You got this!

Using and Testing String List Objects

Tip

When you refer to the interface’s API documentation, you may be tempted to skip down the page to where the interface’s methods are documented since those are the methods that you will write for your implementing classes. Be sure to also read the interface-level documentation provided near the top of the page. It includes important definitions, examples, and even sample code that you are expected to understand before attempting to implement the interface’s individual methods.

Getting Started

You will not be starting from scratch. Instead, starter code is provided that you will need to download to get started, then modify and test to meet the project’s requirements. To download the starter code, follow these instructions:

Login to Odin.
If you have not done so, we recommend creating a separate directory inside of your home directory to store all of your CSCI 1302 projects instead of having them all directly inside your home directory.
Change to your CSCI 1302 projects directory.
Execute the following command to download the starter code into a sub-directory called cs1302-str-list:
Listing 2.13 The git command to download a clone of the project’s starter code.¶
git clone --depth 1 https://github.com/cs1302uga/cs1302-str-list.git

Change to the cs1302-str-list directory that was just created, then use the tree command to verify that you now have a copy of the starter code:

Listing 2.14 Output of running the tree command directly inside the cs1302-str-list directory.¶

tree --filesfirst

.
├── compile.sh
├── jdeps.sh
├── LICENSE.rst
├── README.rst
├── SUBMISSION.md
├── test.sh
├── lib
│   └── cs1302-str-list.jar
└── src
    └── cs1302
        ├── p2
        │   ├── ArrayStringList.java
        │   ├── BaseStringList.java
        │   └── LinkedStringList.java
        └── test
            └── StringListTester.java

Descriptions of the files included in the starter code

A short description for each file contained in the starter code can be found below in Table 2.3.

Table 2.3 Descriptions of files included in the starter code for `cs1302-str-list`.¶
File	Description
`compile.sh`	A script that compiles the starter code.
`jdeps.sh`	A script that shows the dependencies between types in your compiled code.
`LICENSE.rst`	A copy of the license for starter code.
`README.rst`	A small README file that points students to the project description.
`SUBMISSION.md`	A file that you will update to include your name API documentation link.
`test.sh`	A script that runs the tester included in the starter code.
`cs1302-str-list.jar`	A JAR file containing some already-compiled files included in the starter code.
`BaseStringList.java`	The starter code for an abstract parent class for `StringList` implementations.
`ArrayStringList.java`	The starter code for an array-based `StringList` implementation.
`LinkedStringList.java`	The starter code for a linked-list-based `StringList` implementations.
`StringListTester.java`	The starter code for a reusable tester class for `StringList` implementations.

Modify the SUBMISSION.md file to meet the project requirement related to that file (stated here).
Listing 2.15 The emacs command to open SUBMISSION.md.¶
emacs SUBMISSION.md
Make sure that you save the file before continuing to the next step.
Your cs1302-str-list directory is managed by a local Git repository (hidden under a .git directory), which means you should be able to stage the change that you just made to SUBMISSION.md, then commit that change to add it to the repository’s history.
Instructions: Stage and commit your SUBMISSION.md changes
1. Check the current status of the local Git repository (refer to Listing 2.16 to see the exact command to use):
  Listing 2.16 The git command to see the current status of the local Git repository. You should see output similar to what is shown below if you the only thing you have done so far is clone the starter the code and modified your SUBMISSION.md file.¶
  
  git status
  
  On branch main Your branch is up to date with 'origin/main'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: SUBMISSION.md no changes added to commit (use "git add" and/or "git commit -a")
2. Add SUBMISSION.md to the list of files that are “staged” for the next commit (refer to Listing 2.17 to see the exact command to use):
  Listing 2.17 The git command to add SUBMISSION.md to the list of files that are “staged” for the next commit. This “add” command will not produce any output unless Git encounters an error while performing it.¶
  
  git add SUBMISSION.md
3. Check the current status of the local Git repository again to confirm that SUBMISSION.md is now included in the list of files that are “staged” for the next commit (refer to Listing 2.18 to see the exact command to use):
  Listing 2.18 The git command to see the current status of the local Git repository. You should see output similar to what is shown below if you are following along and the last thing you did was “add” your modified your SUBMISSION.md to the list of files that are “staged” for the next commit.¶
  
  git status
  
  On branch main Your branch is up to date with 'origin/main'. Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: SUBMISSION.md
4. Commit the staged changes to repository’s history (refer to Listing 2.19 to see the exact command to use):
  Listing 2.19 The git command to commit the list of staged files to repository’s history with the log message specified using the -m option. When you run this command, the output will show a different value for the commit hash (i.e., not ???????).¶
  
  git commit -m "added my info to SUBMISSION.md"
  
  [main ???????] added my info to SUBMISSION.md 1 file changed, 1 insertion(+), 1 deletion(-)
5. Confirm that the “commit” is now included in the repository’s history with the message that was specified when it was committed (refer to Listing 2.20 to see the exact command to use):
  Listing 2.20 The git command to view the log for the local Git repository (i.e., its history of commits). When you run this command, the output will show a different value for the top-most commit hash (i.e., not ???????).¶
  
  git log --decorate --oneline --graph
  
  * ??????? (HEAD -> main) added my info to SUBMISSION.md * 141e8b4 (origin/main) starter code commit
Proceed to the Project Checklist to see the instructions for each part of the project.

2.4. Project Checklist¶

The steps in the following checklist assume you have already read the other parts of the project description. The first time that you read this section, simply take notes, then reread it again later to begin working on the project.

Part 1. Prepare and Plan (due Friday, March 6^th @ 11:55PM)

Preparing for Part 1

Follow the steps provided below to prepare the BaseStringList, ArrayStringList, and LinkedStringList classes so that everything compiles and so that you can test ArrayStringList and LinkedStringList with the same test code provided in cs1302.test.StringListTester.

Due Before:: Friday, March 6^th @ 11:55PM.

If you have not yet done so, download the starter code on Odin by following the instructions in the Getting Started dropdown provided earlier in this document.
Based on the API documentation for StringList and the UML diagrams provided in the Overview: UML Diagrams dropdown and elsewhere under the project’s Functional Requirements, add “stub” methods (or placeholders that let us compile the code without fully implementing a method) for the specific method overrides that expected to be declared in BaseStringList, ArrayStringList, and LinkedStringList, in that order.

How to identify the methods to declare

Refer to the UML diagrams shown in the Overview: UML Diagrams dropdown under the project’s Functional Requirements. The “Default UML” diagram in the first tab shows exact overrides that must be declared inside BaseStringList.java, ArrayStringList.java, LinkedStringList.java.

You should notice that BaseStringList does NOT declare an override for every abstract method listed in the StringList interface. That is okay since BaseStringList is abstract. Any method overrides that are missing can still be called, assuming they are eventually “filled in” by an override declared in a concrete child class.
How to write a “stub” method for an override
Refer to Listing 2.21 below for an example of what a “stub” for the size() method override that is expected to be declared in BaseStringList.java. Not only are you permitted to copy this example directly into your BaseStringList class, you can base your other “stub” methods on it as well.
Listing 2.21 Example “stub” method for the size() method.¶
/** * Returns the number of items in this string list. * {@inheritDoc}. */ @Override public int size() { // TODO: describe the plan for this method throw new UnsupportedOperationException("not yet implemented"); } // size

As soon as you have valid “stub” methods added for the appropriate overrides in BaseStringList, ArrayStringList, and LinkedStringList, you should be able to compile your project code using the compile.sh interpreter script that is included in the project’s starter code (see Listing 2.22).

Listing 2.22 The command to execute the compile.sh interpreter script.¶

./compile.sh

The actions performed by compile.sh

You are encouraged to inspect the compile.sh script to see what commands it executes. At a high-level, it attempts to execute commands for the actions listed below in Table 2.4 until an action fails or or all the actions complete successfully:

Table 2.4 A list of the high-level actions performed by `compile.sh`.¶
#	Action	Description
1	clean	Delete all files under `bin` and `doc` so that you do not risk accidentally using an old version of a compiled class or interface.
2	compile	Compile the `BaseStringList`, `ArrayStringList`, `LinkedStringList`, and `cs1302.test.StringListTester` classes to the `bin` directory using the javac command
3	document	Generate the files for API documentation website and place them in the `doc` directory using the javadoc command.
4	lint	Check all the `.java` files under `src` for code style violations using the check1302 command.

Important

If you encounter any errors or warnings when running the compile.sh script, then you should always fix them before proceeding. This includes any errors or warning emitted by the javadoc and check1302 commands in addition to those emitted by the javac command.

Now that you have everything setup so that it compiles without any errors or warnings, you should stage and commit the changes that you have made to BaseStringList.java, ArrayStringList.java, and LinkedStringList.java using Git.

Hint

You can follow the same process described earlier in Getting Started to accomplish this, but take care to specify a different commit message that more accurately describes the work that has been done since your last commit.
Now it is time to come up with a plan for each method override. Assuming each of your “stub” methods looks like the example shown in Listing 2.21, simply replace the “// TODO” comment with one or more comments that list out the high-level steps that you think need the method needs to perform.
Tips for planning
Tip

The BaseStringList does not set anything up to store list items; however, the method overrides declared in this class can call any of the methods available from the interface, even those that are not overridden in BaseStringList itself under the assumption that such a call will get “filled in” with by an override in a child class.

Tip

Be sure to read everything up to the “Method Details” section. That section is important but will make more sense later – you will want to reference it when you are ready to start writing code. Also be sure to carefully trace through any code examples that are given. These will help you understand how your class(es) will be used.

Tip

You need to make sure that you understand what a potential call to each method might look like and what a user would expect to happen when making that call on an object of an implementing class. Use the method documentation and code examples in the interface’s API documentation to get started.
Tip

For each method in the interface, try to write down what you think the basic steps need to be in order to produce the desired outcome.
- Try to keep it high level. If the steps that you write down sound like they can be accomplished with another method, then replace those steps with a note to refer to that method. If that other method does not yet exist, then you might introduce that as a private or protected helper method. Using existing methods can greatly cut down the amount of code you need to write and will minimize the number of bugs in your code.
- Here is an example: If there are multiple methods that have a step that gets an element from a specific index in the list, then you might have that method call the get(int) method instead of directly accessing the underlying data structure (array or linked list) which might require writing the same loop multiple times.
- Consider drawing out memory map diagrams similar to the ones shown in the List ADT - Examples with Both Implementations section of the textbook.
Based on the previous suggestion, draw out what the method dependencies are for each method (i.e., what method depends on what). If you notice any circular dependencies, then those should be eliminated.
- The methods that do not depend on other methods are good candidates to start with when you begin the next phase of your development. We will call these the independent methods.
Specific planning steps for each file
Here are the specific steps that you should follow to add your planning comments to each file:
1. Add your planning comments to the stub methods in BaseStringList.java, save it, and make sure it still compiles without any errors or warnings using the compile.sh script. After that, stage and commit your changes to that file using Git.
2. Add your planning comments to the stub methods in ArrayStringList.java, save it, and make sure it still compiles without any errors or warnings using the compile.sh script. After that, stage and commit your changes to that file using Git.
3. Add your planning comments to the stub methods in LinkedStringList.java, save it, and make sure it still compiles without any errors or warnings using the compile.sh script. After that, stage and commit your changes to that file using Git.

Modify the newStringList() method in cs1302.test.StringListTester to return a reference to a new OracleStringList object, then run the test.sh interpreter script that is included in the project’s starter code (see Listing 2.23).

Listing 2.23 The command to execute the test.sh interpreter script.¶

./test.sh

The actions performed by test.sh

You are encouraged to inspect the test.sh script to see what commands it executes. At a high-level, it attempts to execute commands for the actions listed below in Table 2.5 until an action fails or or all the actions complete successfully:

Table 2.5 A list of the high-level actions performed by `test.sh`.¶
#	Action	Description
1	compile	Run the `compile.sh` script.
2	test	Run the `cs1302.test.StringListTester` class using the java command.

Important

If you encounter any errors when cs1302.test.StringListTester tests a specific scenario, then that is great! If you encounter an AssertionError, then that means the implementation you are testing does not meet some behavior expectation.

Use the output provided in the stack trace to determine which test scenario failed and what expectation was not met so that you more quickly locate where to start addressing the issue in your code.

At this point, you should have a complete project environment set up with “stub” methods, planning comments, and one or more tester programs that you can adjust and run to check the functional correctness of your code as you begin to implement it during the next part of the project.
Before Friday, March 6^th @ 11:55PM, follow the submission instructions to prepare Part 1 of your project for submission and actually submit it.

Part 2. Implement ArrayStringList (due Friday, March 20^th @ 11:55PM)

Preparing for Part 2

To prepare for this part of the project, you must first complete and submit Part 1. Also, even though you are not finalizing the code for the overall project during this part, your submission for this part is still expected to meet all the non-functional requirements stated later in the project description.

Due After:: Submitting Part 1.
Due Before:: Friday, March 20^th @ 11:55PM.

Modify the newStringList() method in cs1302.test.StringListTester to return a reference to a new ArrayStringList object, then run the test.sh script (see Listing 2.24).
Listing 2.24 The command to execute the test.sh interpreter script.¶
./test.sh
StringListTester is Expected to Fail!

Since you have not fully implemented any of the methods that you added as “stub” methods yet, you should see the tester program crash when test.sh runs cs1302.test.StringListTester using the java command.

Once you confirm that your tester is testing the ArrayStringList class but failing (as expected), stage and commit your changes using the appropriate Git commands.

Implement and test the methods below in the order presented by following the specific steps stated in the next dropdown for each method:

Table 2.6 The methods to implement and test for Part 2.¶
#	Class	Method
1	`BaseStringList`	`int size()`
2	`BaseStringList`	`boolean isEmpty()`
3	`ArrayStringList`	`boolean add(int, String)`
4	`ArrayStringList`	`String get(int)`
5	`BaseStringList`	`String makeString(String, String, String)`
6	`BaseStringList`	`String toString()`
7	`BaseStringList`	`boolean contains(int, String)`
8	`ArrayStringList`	`void clear()`
9	`ArrayStringList`	`String remove(int)`
10	`ArrayStringList`	`StringList reverse()`
11	`ArrayStringList`	`StringList slice(int, int)`
12	`BaseStringList`	`boolean add(int, StringList)`

Before Friday, March 20^th @ 11:55PM, follow the submission instructions to prepare Part 2 of your project for submission and actually submit it.

Part 3. Implement LinkedStringList (due Wednesday, March 25^th @ 11:55PM)

Preparing for Part 3

To prepare for this part of the project, you must first complete and submit Part 2. Also, please remember that your submission for this part is expected to meet all the functional requirements and non-functional requirements stated in the project description.

Due After:: Submitting Part 2.
Due Before:: Wednesday, March 25^th @ 11:55PM.

Modify the newStringList() method in cs1302.test.StringListTester to return a reference to a new LinkedStringList object, then run the test.sh script (see Listing 2.25).
Listing 2.25 The command to execute the test.sh interpreter script.¶
./test.sh
StringListTester is Expected to Fail!

Since you have not fully implemented any of the methods that you added as “stub” methods to LinkedStringList, you should see the tester program crash when test.sh runs cs1302.test.StringListTester using the java command.

Once you confirm that your tester is testing the LinkedStringList class but failing (as expected), stage and commit your changes using the appropriate Git commands.

Implement and test the methods below in the order presented by following the specific steps stated in the next dropdown for each method:

Table 2.7 The methods to implement and test for Part 3.¶
#	Class	Method
1	`LinkedStringList`	`boolean add(int, String)`
2	`LinkedStringList`	`String get(int)`
3	`LinkedStringList`	`void clear()`
4	`LinkedStringList`	`String remove(int)`
5	`LinkedStringList`	`StringList reverse()`
6	`LinkedStringList`	`StringList slice(int, int)`

Final Run-through.
- Thoroughly test all of your methods on objects of both ArrayStringList and LinkedStringList using one or more tester programs.
- Remember to fix errors and warning as you go, including code style violations, and to fully stage and commit your changes every time you confirm that something works.
Before Wednesday, March 25^th @ 11:55PM, follow the submission instructions to prepare Part 3 of your project for submission and actually submit it.

2.5. Functional Requirements¶

A functional requirement defines a specific behavior between program inputs and outputs, and a collection of functional requirements describes how a program should function. If your submission satisfies a functional requirement listed in this section, then the requirement’s point total is added to your submission grade.

Overview

For this project, you are required to create two different classes that implement the same interface via a common abstract parent. While the specific details are listed later in this document, the following diagram illustrates the general relationship between your classes and the interface. The package cs1302.adt is provided for you in the cs1302-str-list.jar file that is included in the starter code.

cs1302.p2.BaseStringList

Starter Code

The cs1302.p2.BaseStringList class is one of the classes that you are responsible for implementing and testing. A partially implemented version of this file is included in the starter code. It is your responsibility to ensure that it is placed under src and named correctly based on the information provided below.

Table 2.8 Starter Code for `cs1302.p2.BaseStringList`¶
Item	Description
Source	`src/cs1302/p2/BaseStringList.java`
FQN	`cs1302.p2.BaseStringList`
Package Name	`cs1302.p2`
Simple Name	`BaseStringList`

Dependencies

It should also be noted that the BaseStringList class depends on some classes that we have included in cs1302-str-list.jar.

Class / Interface	Description
`StringList`	An ADT / interface for a sequence of references to non-empty `String` objects.

You do not have access to the source code for the classes and interfaces in that Java ARchive (JAR) file; however, API documentation for those classes is provided api|_.

The compilation instructions that we provide below will ensure that these dependencies are available on the classpath so that the compiler can find them.

cs1302.p2.ArrayStringList

Starter Code

The cs1302.p2.ArrayStringList class is one of the classes that you are responsible for implementing and testing. A partially implemented version of this file is included in the starter code. It is your responsibility to ensure that it is placed under src and named correctly based on the information provided below.

Table 2.9 Starter Code for `cs1302.p2.ArrayStringList`¶
Item	Description
Source	`src/cs1302/p2/ArrayStringList.java`
FQN	`cs1302.p2.ArrayStringList`
Package Name	`cs1302.p2`
Simple Name	`ArrayStringList`

Dependencies

The ArrayStringList class depends on your BaseStringList class as well as some classes that we have included in cs1302-str-list.jar.

Class / Interface	Description
`StringList`	An ADT / interface for a sequence of references to non-empty `String` objects.

You do not have access to the source code for the classes and interfaces in that Java ARchive (JAR) file; however, API documentation for those classes is provided here.

The compilation instructions that we provide below will ensure that these dependencies are available on the classpath so that the compiler can find them.

cs1302.p2.LinkedStringList

Starter Code

The cs1302.p2.LinkedStringList class is one of the classes that you are responsible for implementing and testing. A partially implemented version of this file is included in the starter code. It is your responsibility to ensure that it is placed under src and named correctly based on the information provided below.

Table 2.10 Starter Code for `cs1302.p2.LinkedStringList`¶
Item	Description
Source	`src/cs1302/p2/LinkedStringList.java`
FQN	`cs1302.p2.LinkedStringList`
Package Name	`cs1302.p2`
Simple Name	`LinkedStringList`

Dependencies

The LinkedStringList class depends on your BaseStringList class as well as some classes that we have included in cs1302-str-list.jar.

Class / Interface	Description
`StringList`	An ADT / interface for a sequence of references to non-empty `String` objects.
`Node`	A node for an item in a linked list data structure.

You do not have access to the source code for the classes and interfaces in that Java ARchive (JAR) file; however, API documentation for those classes is provided here.

The compilation instructions that we provide below will ensure that these dependencies are available on the classpath so that the compiler can find them.

cs1302.p2.StringListTester

Starter Code

The cs1302.test.StringListTester class is one of the classes that you are responsible for updating while working on this project.

Table 2.11 Starter Code for `cs1302.test.StringListTester`¶
Item	Description
Source	`src/cs1302/test/StringListTester.java`
FQN	`cs1302.test.StringListTester`
Package Name	`cs1302.test`
Simple Name	`StringListTester`

Dependencies

The LinkedStringList class depends on your BaseStringList class as well as some classes that we have included in cs1302-str-list.jar.

Class / Interface	Description
`StringList`	An ADT / interface for a sequence of references to non-empty `String` objects.
`OracleStringList`	An oracle implementation of the `StringList` interface.

You do not have access to the source code for the classes and interfaces in that Java ARchive (JAR) file; however, API documentation for those classes is provided here.

The compilation instructions that we provide below will ensure that these dependencies are available on the classpath so that the compiler can find them.

2.6. Non-Functional Requirements¶

A non-functional requirement specifies criteria that can be used to judge your submission independently from its function or behavior. If functional requirements describe what your submission should do, then the non-functional requirements describe how your submission is supposed to be. If your submission does not satisfy a non-functional requirement listed in this section, then the requirement’s point total is deducted from your submission grade.

2.7. Submission Instructions¶

You will submit each part of your project on Odin. Before you submit each part, make sure that your project files are located in a directory called cs1302-str-list. If you followed the instructions provided earlier in the Getting Started dropdown to download the project’s starter code, then cs1302-str-list is already your directory name.

How to Submit

To submit a specific part of the project, first change into the parent of your project directory (i.e., one directory above it), then complete the steps below.

Ensure that all of the .java files in your project compile without any errors or warnings on Odin using the compile commands included in the compile.sh script that is included in the project’s starter code. This script also checks your .java files for code style violations using the check1302 command, although you can still run check1302 src manually.

Warning

If there are style violations, then fix them, recompile, and retest your code! Retesting is important to ensure that you do not accidentally break your code when fixing a style issue.
Ensure that you have generated and hosted the API documentation website for your code, as described in the related non-functional requirement.

Warning

You only need to create the symbolic link to your project’s doc directory at ~/public_html/cs1302-p2-doc once using the ln command to host the website. Assuming that the symbolic link was created correctly, you do not need to create it again; however, you must regenerate the website files under doc using the appropriate javadoc command to update the contents of that website.
Ensure that your SUBMISSION.md file is up to date, as described in the related non-functional requirement.
Ensure that your project’s code is fully committed using Git. You can use the git status command to determine if the local copy of your repository has any changes that need to be committed (or confirm that everything is good), then use the git add and git commit commands to stage and commit changes, as needed.
What to look for when using git status
If your copy of the project is fully committed, then git status should inform your that there is nothing commit:
git status
On branch main ... nothing to commit, working tree clean
You do not have permission to publish your local commits to the book author’s copy of the repository at origin/main, so please disregard any suggestion from Git to use git push when working on this project.
git status
On branch main Your branch is ahead of 'origin/master' by ?? commits. (use "git push" to publish your local commits) ...
If you add any new .java files (e.g., if you setup separate tester classes as described in the comments inside StringListTester.java, then they will not be tracked by Git at first. The git status command will let you know this and give you the command to use in order to start tracking them and add include them on the stage for your next commit.
git status
On branch main ... Untracked files: (use "git add <file>..." to include in what will be committed) source/cs1302/test/ArrayStringListTester.java source/cs1302/test/OracleStringListTester.java source/cs1302/test/LinkedStringListTester.java
Once you are certain that the code included in your project compiles, has no code style violations, includes both an up-to-date doc directory and SUBMISSION.md file, and is fully committed using Git, then you can submit your work using the following command, replacing N with the specific part of the project you are submitting:
```
submit1302 cs1302-str-list partN
```
Warning

Do NOT literally type partN; instead, be sure to replace N with the specific part of the project you are submitting! For example, use part1 when submitting Part 1.
Inspect the output of the last command to verify that your project was submitted. Your cs1302-str-list directory should now contain a receipt file that starts with rec. The exact name of the receipt file may vary, depending on the part of the project that you are submitting.

If you have any problems submitting your project then please contact your instructor as soon as possible; however, doing this the day or night the project is due is probably not the best idea.

2.8. Frequently Asked Questions¶

How can I test that exception was thrown?

In this project, you are tasked with making sure that exceptions are thrown from your method overrides in certain situations based on each method’s API documentation. When testing your methods, you will want to make sure that one of the things you check is that your methods actually do, in fact, throw those exceptions when they are expected to per the API documentation.

An example of a test method you might write to test whether your add(int, String) method throws an IndexOutOfBoundsException when a negative value is supplied for the index parameter is provided below in Listing 2.27.

Listing 2.27 A test method to check that add(int, String)
throws an IndexOutOfBoundsException when a
negative value is supplied for the index
parameter.¶

public void testScenario4() {
    try {
        StringList list = this.newStringList();
        list.add(-1, "a");
        throw new AssertionError(
            "add(int, String): no exception thrown, but IOOBE expected"
        );
    } catch (IndexOutOfBoundsException ioobe) {
        System.out.println("add(int, String): IOOBE thrown as expected");
    } catch (Throwable cause) {
        throw new AssertionError(
            String.format(
                "add(int, String): %s thrown, but IOOBE expected",
                cause.getClass().getName()
            ),
            cause
        );
    } // cause
} // testScenario4

We recommend that you further break up your test code into methods in order to reduce the redundancy you see in the example above. Your test code does not need to look exactly like the test code what we provide, but an illustrative example is provided below in Listing 2.28 to help you get started with this idea.

Listing 2.28 A test method to check that add(int, String)
throws an IndexOutOfBoundsException when a
negative value is supplied for the index
parameter. In this example, the parts related to
passing or failing the test are factored out into
reusable static methods that to help make the test
code more readable. You will need to include proper
Javadoc comments if you add these static methods to
your tester class.¶

private static void pass(String message, Object... args) {
    System.out.printf(message, args);
} // pass

private static void fail(String message, Object... args) {
    String formatted = String.format(message, args);
    throw new AssertionError(formatted);
} // fail

private static void failFromException(Throwable cause, String message, Object... args) {
    String formatted = String.format(message, args);
    throw new AssertionError(formatted, cause);
} // failFromException

public void testScenario4() {
    try {
        StringList list = this.newStringList();
        list.add(-1, "a");
        StringListTester.fail("add(int, String): no exception thrown, but IOOBE expected");
    } catch (IndexOutOfBoundsException ioobe) {
        StringListTester.pass("add(int, String): IOOBE thrown as expected");
    } catch (Throwable cause) {
        StringListTester.failFromException(
             cause,
             "add(int, String): %s thrown, but IOOBE expected",
             cause.getClass().getName()
        );
    } // catch
} // testScenario4