COP 2800 (Java Programming) Project #4


Due: by the start of class on the date shown on the syllabus


For this project, you will create a class called TextKit containing several utility methods that can be used in different applications.  This class is not intended to be a complete application by itself!  (It has no main method.)  Your class will be put into a package called utils.  The package will then be documented using the javadoc tool to create HTML documentation for your package.  Finally, you will create a small stand-alone non-GUI Java program that tests the methods of your utils.TextKit class.

(Your next project will use this package, and you won't be allowed to make any changes to TextKit once submitted.)


Create a public Java class named “TextKit” in a package called “utils” that contains the following public static methods (at least):

To facilitate such reuse, these methods must be public static methods of a public class called TextKit, which must be in a package called utils.  (Someday you might add other text utility methods to this class or add other classes to this package.)

Be sure to add appropriate Java doc comments throughout your code!

For full credit, your methods must check for invalid arguments (for example, inappropriate negative numbers).  If you detect invalid arguments passed to a method, the method must throw an appropriate java.lang.IllegalArgumentException.

Next, create a testing application.  Your test program (containing just a main method) should not be in the utils package, but rather in the default, nameless package.  You can name the class anything you like; something like TextKitApp is fine.  This test program should invoke each method of the utils.TextKit class at least once, to verify those methods work.  You can test the resulting String object returned from each method, against the expected value.  Or you can simply print a message that says something like “You should see five stars here: ”, followed by the output of the method call with (in this example) the argument 5.  (Such a main method is sometimes referred to as a test driver.)  A good test driver will have many test cases, to more thoroughly check the methods.  Having failing cases (in a try...catch block of course) is also a good idea, but not required for this project.

Finally, you must use the javadoc tool to create HTML documentation for your package.  This documentation should be placed in a directory called “docs”.  (The docs directory should not be placed inside of the utils directory.)  Note, only the code in the package needs to be documented with Java doc comments; your test driver only needs regular style comments.

To be turned in:

For this project, no normal email submissions will be accepted.  Instead, you should submit a single zip attachment via the Canvas assignment dropbox only.  The zip should contain the correct files and directories:  Your testing application source, your docs directory, and your utils package source.  (You don't have to send any .class files.)

You must send this email using Canvas.  Email sent to regular email addresses that contains a zip file attachment will be discarded by the mail server, if they contain any executables or script files; that includes the JavaScript files generated by javadoc!

You can instead submit a flash disk or CD-ROM, with your name on it, containing your test program at the top (root) directory, a directory called utils containing the TextKit class and Java source code file, and another directory (not under utils!) called docs containing the HTML output of the javadoc command, which should be generated using all the appropriate options as shown in class.  (Please don't have other files on this; I don't wish to hunt around for the right ones.)

Send project questions to .  Please use a subject such as “Java TextKit Project Questions” so I can tell which emails are questions about the project.

Please review Submitting Assignments and Project Grading Criteria from your class syllabus for further details.


Class TextKit is not a complete application.  It is intended to be used in many different future applications.  This is an example of reusable (or library) code.  In this case, your methods do not read any input, nor produce any output.  Rather, they produce and return a result solely from the arguments passed in from some other class, in a similar way to methods such as Math.round().

Use PkgDemo as a model to create and use packages.  See JavaDoc Demo - Greeter demo as a model to use the javadoc tool.  (Remember that the Java SDK documentation contains information about all tools, including javadoc.)  In particular, when working from the command line you will make your life a bit easier if you create a package folder first, then create the .java files inside of that folder (that belong in the package).  (Your testing application is not in that folder, but the parent folder.)  Now when you run "javac", the source file(s) in the package will automatically get compiled!  And the .class files will get put in the correct location without any additional options needed!

You program should be easily read and well commented, including your name.  Be sure to have the “doc” comments for each class and each method in TextKit, in the correct locations, or they won't show up in the generated API web pages.  (So, check that to make sure all your doc comments did show up.)

What is an illegal argument?  If you try to pass something other than an int to a method expecting an int argument, you get a compiler error message.  That's not what is meant by an illegal argument.  That would just be a syntax error that the compiler catches for you.

What the compiler can't catch is when you pass an int value that makes no sense.  In the case of lineOfStars, what should that method do if you pass a negative integer?  Or a huge integer, say over one million?  The Java compiler can't detect such illegal argument values.  (In some languages you can more precisely define argument types, including legal ranges.  In such languages the compiler can detect the problem!)

So, you check arguments at the top of methods in reusable code modules such as TextKit, and if they are illegal then the method should throw exceptions.

A programmer is an expert problem solver.  To solve a task such as lineOfStars and pad you can make use of a design method that works in lots of cases.  The idea is to try to solve a simpler problem.  Then you can repeat that step in a loop to solve the original task.  This general idea of solving a problem by breaking a difficult task into very simple tasks (baby steps) and then repeating or combining those steps, is known as divide and conquer.

You can apply this idea to the task of lineOfStars.  To start with, create an empty String.  To add one star to this you can use a similar solution to adding a number to a variable (num = num + something).  You need to take the existing string of stars, append one "*" to the right end, and the new String object replaces the original.  Once you can add one star to a String, so you need to repeat that step the correct number of times to produce a String with the correct number of stars.  To make this idea efficient consider how you might use a StringBuilder instead of a String.

You can apply this idea to the design of pad as well.

Java 5 added many new features, including the ability to format numbers easily.  You don't have to use this feature, but if you find it and figure out how to use it (which isn't easy) you can pad a number in a single line of code!

Ask me for help if you get stuck!  (Try not to wait until the deadline!)