CS11 – Advanced Java Winter 2011-2012 Lecture 2Today’s Topics n Assertions n Java 1.5 Annotations n Classpaths n Unit Testing! n Lab 2 hints JAssertions! n Assertions are a very useful language feature n Provide two major benefits n Can test the assumptions that your code makes q Add statements to your code that test your assumptions q These assertions are tested at runtime q If assertion is violated then program is halted with an error n Assertions also document your assumptions q Like javadoc, the code specifies its own assumptions q Other developers can read your code and see exactly what you think should be trueAssertions in Java n Java 1.4 added an assert keyword assert result >= 0; q Condition must evaluate to a boolean value q No parentheses required around the condition n If the condition is false at runtime, a java.lang.AssertionError is thrown q AssertionError is in the Error subtree of the Java exception hierarchy n Since it’s an exception, it includes a stack-trace for where the assertion-failure occurred q From Java API for java.lang.Error: n An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.Assertions in Java (2) n Simple assert syntax: assert cond; q cond must evaluate to a boolean value n Can also specify details for when failure occurs: n assert cond : expr; q expr must evaluate to something n e.g. it cannot be a call to a void function n expr is only evaluated if cond is false n Error details should indicate what went wrong q Make it easy to debug your software! q Example: assert result >= 0 : "Bad result " + result;Disabling Assertions n Assertions are sometimes expensive to test q Example: a class that can sort its contents public class Sorter { public boolean inOrder() { ... // Iterate through contents to test order } public void sort() { ... // Do the sorting magic here assert inOrder() : "My sort is broken!"; } } n Java can enable/disable assertions at runtime q A class’ assertion behavior is enforced when it is loaded q Can’t turn on/off a class’ assertions after the class is loadedDisabling Assertions (2) n Java VM uses these arguments for assertions: q -enableassertions (or -ea) n Enables assertions in all classes except system classes q -disableassertions (or -da) n Disables assertions in all classes except system classes n Example options: q -ea package.ClassName or -da package.ClassName n Enables/disables assertions in a specific class q -ea package... or -da package... n Enables/disables assertions in all classes in a package n To enable/disable assertions in system classes: q -enablesystemassertions or -esa q -disablesystemassertions or -dsaJava Assertion Guidelines n Do not use Java assertions for verifying the arguments of public APIs! n Standard Java approach is to use exceptions to flag invalid arguments n A small set of examples from the Java API: q NullPointerException n null was specified for a required reference-argument q IndexOutOfBoundsException n an index argument was out of the required range q NumberFormatException n a string representation of a number is not the correct format q IllegalArgumentException n a general catch-all for bad argumentsJava Assertion Guidelines (2) n Don’t put required code into assertion tests! assert set.remove(obj) : "obj not found: " + obj; q Problem? n When this assertion is disabled, the remove operation won’t occur at all! n Many more guidelines for assertions in Java q For more info, see “Programming with Assertions” http://java.sun.com/javase/6/docs/technotes/guides/language/assert.htmlJava Naming Conventions n A common usage pattern for classes in Java: q Create a class for use in a 3rd-party framework q Frequently, the class needs to adhere to certain naming conventions n Framework can look up methods and fields on the class n External dev tools can parse the code and find methods/fields n Example: J2EE web-application frameworks q Enterprise JavaBeans (EJBs) encapsulate web-app logic q EJBs must implement certain interfaces, and EJB methods must follow certain naming conventions q When these rules are violated, J2EE application server gets very unhappy.Java Annotations n Java 1.5 introduces a simpler solution: q Attach annotations (i.e. metadata) to classes, and their fields and methods n Annotations can be extracted by external tools q Instead of looking for methods with a particular name or signature, retrieve all methods with a specific annotation n Annotations are also used by the Java compiler, VM q Examples: n “this method is deprecated” n “this method implements an interface method” n “this method overrides a parent-class method”Java Annotations (2) n Annotations are like classes q They have a specific type q They can contain fields to store annotation details n Annotation specifications include: q What they can appear on (e.g. only classes, or only methods) q A retention policy: when and where they are made available n “Source” – only available at compile-time n “Class” – annotations included in compiled class file, but JVM may discard them at load-time n “Runtime” – annotations must be kept by the JVM at runtime, so that they can be extracted and read by other codeA Simple Example n You need to write a 2D point class public class Point2d { private double xCoord, yCoord; public boolean equals(Point2d obj) { ... // Implementation of equals } } n Problems? q This is not a correct declaration of equals()! q Must take an argument of type Object n The compiler doesn’t tell us there is a problem! q Code just acts bizarrely when used with collections, etc.Now with Annotations n Java provides some annotations for you to use q @Override – A method overrides a parent-class method n Update our code: public
View Full Document