Java unchecked operations warnings

Java unchecked operations warnings

by Anton Dil -
Number of replies: 2

Another user posted a question here about this

I'm raising the same question here because I think it is a more general issue.

What happens is that when students use raw types the Java compiler generates a message like this:

"Note: <filename> uses unchecked or unsafe operations.
Note: recompile with -xlint:unchecked for details"

It used to be possible to suppress warnings like this at the compiler level by passing a flag like -Xlint:none or -nowarn, but as far as I can see this no longer works.

It is possible to suppress these messages programmatically, and sometimes this could be hidden in a template so that students don't have to know about this feature: @SuppressWarnings("unchecked").

However, if you want a student to submit more than one class in the same answer box, altering the template no longer works. It also doesn't work for a single class if the student must add an import (as the annotation isn't legal before an import).  It could be given in the preloaded code, but that would require some more teaching.

Currently CodeRunner reports this as a syntax error

but actually this does not prevent the student's code from compiling and it's not really a syntax error, just an unsafe practice.

I wonder whether warnings like this (another example is the use of deprecated code) could be captured another way, as the current approach prevents tests from running that could actually be run?

In reply to Anton Dil

Re: Java unchecked operations warnings

by Richard Lobb -
I'm personally happy with the current way that warnings are handled. I haven't taught Java for many years, but in my C course I always required students to submit code that compiled without warnings. Any warnings meant zero marks. I even added the -Wall option for even more warnings! But penalties for resubmission were fairly low so students could resubmit warning-free code without paying a high price. 

However, your situation may be different, so ...

As a starting point, to get a feel for what's possible, create a new write-a-program question of type 'multilanguage'. Customise it, and pull out all the non-Java-relevant code. Under Advanced Customisation, set the Ace language to Java rather than a comma-separated list of options. That will lock the question into Java only and the language-select dropdown will disappear.

Now it's over to you to decide exactly how you want the compile-and-run process to work in the presence of compiler warnings. One option might be to check for the presence of a .class file after the compile phase and proceed to run the code if it's present, rather than abort if the compiler gives a non-zero return code. But you'd still have the compiler warnings present in your got column, so the student would still fail the tests. To prevent that you'd have to change the script to capture the actual compiler output. The relevant line here is "return_code =['javac', "-J-Xss64m", "-J-Xmx4g", filename])": change that to a more-generic (see documentation here) in which you capture the stdout and stderr output. You could filter the stderr output to remove lines beginning with 'Note:' and print the rest to stdout. That should, if I understand the Java compiler properly (which I don't) give you only genuine syntax errors rather than warnings. 

Once you've got it working the way you want, you could make it into a new question type (or several types, adding appropriate extra Java code for 'write-a-function', 'write-a-class', 'write-a-program' questions as appropriate). They could be question types like Java_program_allow_warnings, Java_class_allow_warnings etc. 

If you want to get real fancy, you could make it into a combinator template grader, and give fewer marks if students submit code that generates warnings :-) But that's much harder.

And after writing all that, I do still wonder why you'd want students to submit code that uses unsafe or unchecked operations! :-)

In reply to Richard Lobb

Re: Java unchecked operations warnings

by Anton Dil -
Thank you for the suggestion Richard - this will take some time to explore.
To answer your question, it's because we will use this in a context where students will get one submission and won't see the test results. In this context, it's brittleness I'm trying to avoid. It is, as I say, not a syntax error and does not prevent code from compiling.