Release 1.1.4 of the Checker Framework and Type Annotations compiler

[Werner Dietl]

We have released a new version of the Type Annotations (JSR 308) compiler, and

the Checker Framework.

 * The Type Annotations compiler supports the type annotation syntax that is

   planned for a future version of the Java language.

 * The Checker Framework lets you create and/or run pluggable type-checkers,

   in order to detect and prevent bugs in your code.  

Changes for Checker Framework

Version 1.1.4, 8 Jul 2011

Units Checker (new):

  Ensures operations are performed on variables of correct units of

  measurement.

Changed -AskipClasses command-line option to -AskipUses

Implementation details:

- Improve support for type qualifiers with enum attributes

Changes for Type Annotations Compiler

Version 1.1.4, 8 Jul 2011

Bug fixes:

  javac: don't run type annotation processors if symbol resolution

    errors exist (improvement to fix in the last release)

Base build

  Updated to OpenJDK langtools build b147

[Werner Dietl]

 
Hi Werner,

thanks for your interest in the Units Checker and the Checker Framework!

>I looked at the recent Unit Checkers so far in the codebase.
>It seems, unlike the Lex Spooner approach (also working with double values, not precise enough for many operations which often require Number subclasses like BigDecimal) or Unit-API and related frameworks it aims directly at primitive types, but I could only see int data type so far.
>
>Can this be extended or made more flexible?

It seems you're looking at an old version of the Checker Framework. The current release is 1.2.2 and the Units Checker was changed considerably on July 19th, which was included in release 1.1.5.
As an example for using other primitive types, see

http://code.google.com/p/checker-framework/source/browse/checkers/tests/units/Units.java

The same works with boxed types and BigInteger.

Is this flexible enough or did you mean something else? Could you send an example of something that you would like to do?

> Also the TimeChecker should take the new JSR-310 into consideration, allowing
> e.g. the Hz demo case or any other time/date related code to 

What are the TimeChecker and Hz demo case you are referring to here?

Best regards,
cu, WMD.

>________________________________
>From: Werner Keil <werne...@gmail.com>
>To: jsr308-...@googlegroups.com
>Cc: "checker-fram...@googlegroups.com" <checker-fram...@googlegroups.com>; Werner Dietl <wdi...@yahoo.com>
>Sent: Monday, October 10, 2011 4:06 PM
>Subject: Re: Release 1.1.4 of the Checker Framework and Type Annotations compiler
>
>
>I looked at the recent Unit Checkers so far in the codebase.
>It seems, unlike the Lex Spooner approach (also working with double values, not precise enough for many operations which often require Number subclasses like BigDecimal) or Unit-API and related frameworks it aims directly at primitive types, but I could only see int data type so far.
>
>
>Can this be extended or made more flexible?
>
>
>Also the TimeChecker should take the new JSR-310 into consideration, allowing e.g. the Hz demo case or any other time/date related code to accept the Date/Time JSR. I know, Spec Lead Stephen has so far been sceptical if not to say hostile towards using too many annotations, but if both JSRs should end up in Java 8 together, they are supposed to interact, otherwise people would feel this is a redundancy. Unless of course checkers were never part of Java, but even in such case, the problem of calculating between various "built-in" types like primitives or Date/Time remained.
>
>
>Somewhat similar as for Unit-API, but unless that was considered an integral JSR (e.g. for the recent Sensor announcement for Java 8) one could always create a wrapper and people may have to accept it as a library served by a Date/Time class rather than expecting its direct support;-)
>
>
>Where it makes sense, especially for known multiply() or divide() operations such annotations would also benefit Unit-API. For all other operations like add() or conversion via to() it already is fully type-safe using generics as of now. 
>
>
>
>
>
>