Gradescope Submission Notes

• General Notes
• Common Issues

We will be collecting submissions through Gradescope and have an autograder that will compile and run your code as soon as you submit it. So, you will get immediate feedback as to whether or not your code compiled.

General Notes

• If you’re submitting as a zip, make sure there is no extra top-level directory that your files are inside of. All files (source code files especially) cannot be nested inside any folder.
• When you submit, please wait for confirmation that your submission went through and compiled. If it doesn’t compile, we won’t be able to give you extra late days or go back to fix your submission just because you didn’t check that it compiled. If you see the “Autograder failed to execute” message, it does not mean the autograder broke, it means that your submission did not compile!
• There are a bunch of tests for each assignment, of which many are hidden from you.
  • You get feedback as to whether or not you failed the visible tests.
  • When grades are released, your total score might not add up as you expect. This is because you failed some hidden test cases. We can’t tell you exactly what they are (as it wouldn’t be fair if we reuse them in future semesters), but we will give you a general idea of what they were for you to pay attention to for the next assignments.
  • You also get checkstyle feedback. However, this should not be your primary mode for validating you are checkstyle compliant - that would simply take forever to debug your issues and it would be worth the time to be able to run checkstyle locally.
• Previously, a submission that went in an infinite loop got stuck. However, now we’ve updated the autograder to stop any unit tests that take longer than 10 seconds. So you shouldn’t get the “Autograder Timed Out” message, but if you do please let us know as it is likely an issue on our end.
• Your (non-unit-test) files need to be checkstyle compliant, even if the skeleton file we provide is not necessarily checkstyle compliant. We will do our best to make sure the skeleton code is itself checkstyle compliant, but it’s on you to make sure the final deliverable is.
• Your Java version should be Java 8. If you’re compiling with Java 10, you should be ok as long as you don’t use things like var.
• Don’t forget to include a README!

Common Issues

Inevitably, some of you will get the “Autograder Failed to Execute…” message. This essentially means that your submission did not compile as expected. However, we don’t show you the actual compiler output (as it could tell you what the hidden test cases are).

• If submitting a zip, make sure you’ve zipped correctly at the correct level and there are no extra folders.
• Make sure you haven’t changed any file names.
• Make sure you haven’t modified any of the provided files, we will be using the interface files we provide. So if you modify them, ours will overwrite any changes you make.
• Make sure you haven’t changed any public method names, class names, or method signatures or scopes.
  • You can’t change the return type of any public method.
  • You shouldn’t change the scope of any method/class - don’t make something private that was originally public or package private (meaning no scope modifier).
  • You can’t add exceptions to public method headers. If you add throws IOException (which is not a `RunTimeException) to any method, then our code won’t compile when we call that method because our code won’t be expecting any exception.
• Make sure you don’t call System.exit(). We are grading your code from our own java code. So if you exit(), you’re actually exiting our program that is grading yours and the autograder won’t finish executing. Instead, you’ll have to find a way to just return from main.