Using NetBeans 4.0 RC2 (junit: ide4/modules/ext/junit-3.8.1.jar) on
j2sdk1.4.2_06, I get this error:
C:\Projects\FWS\src\fi.java.net\fi\FastInfoset\test\algorithm\AlgorithmTest.java:104:
cannot resolve symbol
symbol : method assertEquals (float,float)
location: class algorithm.AlgorithmTest
assertEquals(_floatArray[is], f[is]);
On the platform I mentioned above, only |*assertEquals
<../../junit/framework/Assert.html#assertEquals%28float,%20float,%20float%29>*(float expected,
float actual, float delta) is supported. Adding a 0 to each of these
calls, i.e. |assertEquals(_floatArray[is], f[is],0), the unit test runs
fine.
|
--Joe
|
Paul Sandoz wrote:
> Hi,
>
> Alan, the encoding algorithm support is complete enough for you to now
> use.
>
> Feel free to modify the interfaces and implementation to improve in
> general and have better integration with X3D.
>
> I have tried to update the JavaDoc of the interfaces to reflect the
> current behaviour, but it is very time consuming to write such stuff.
>
> It is probably more instructive to look at code to see how the SAX
> interface may be used for serializing and parsing in conjuction with
> encoding.
>
> See the algorithm unit tests:
>
> FastInfoset/test/algorithm/AlgorithmTest.java
>
> with tests for:
>
> - the implemented built-in encoding algorithms (base64 (partial no
> character support), int and float).
>
> - application defined algorithm with no registered encoding algorithm
>
> - application defined algorithm with a registered encoding algorithm
>
> We can go over it on the phone if you want.
>
> Currently there is a mixture of sun specific implementation and
> org.jvnet stuff.
>
> The vocabulary stuff needs to be transitioned over to use the API
> (still not sure if the proposed API is good, likely to change when
> implementation starts).
>
>
> If you make changes i recommend that before you commit you run the
> unit tests and the UNIX script:
>
> FastInfoset/bin/saxroundtripdir
>
> on the XBC test corpus.
>
> I will keep away from this area for now and concentrate on writing a
> DOM specific parser so we should avoid any conflicts.
>
> Paul.
>