Preview

The next release shall contain support for device class PointCardRW to complete support for all device classes specified in UPOS 1.15.

In addition, all device classes supported by jpos 1.15 will be prepared to work with jpos 1.16 as well. Therefore, a specific jar file - Jpos116Dummy.jar - will be provided: It will contain a JavaPOS 1.16 implementation for device classes Lights and POSPower as well as the corresponding interfaces LightsConst and POSPowerConst. Until an official implementation for jpos 1.16 becomes available, this should be enough because Lights and POSPower are the only device classes that have been changed since jpos 1.15.

To ensure that these implementations override the corresponding implementations of jpos1.15, this jar file must be within the class path before the jpos 1.15 jar file. When an official jpos 1.16 jar file will be available, Jpos116Dummy.jar should be removed from the class path.

Validation concept for POSPrinter, LineDisplay and PointCardRW has been changes slightly.

Due to a conversation with several members of OMG (Object Management Group, the UPOS standardization organization), it remains vendor specific how string representations of currency values must be made. For OPOS and POS for .NET, the situation seems to be clear: The string representation of 123.45 is "123.45" (perhaps with additional trailing zeroes). For JavaPOS, the situation is a little bit different: A Currency value of 123.45, stored within a variable of type long, is represented by a long value of 1234500. Therefore, some vendors provide a string representation of "1234500" for the currency value 123.45, while other vendors use the same string representation as OPOS and POS for .NET - "123.45" (perhaps with additional trailing zeroes).

This seems to be only a problem within FiscalPrinter class devices (for CAT and ElectronicValueRW, string representations always represent the currency value, not the internal integer representation), therefore only a few new methods will be added to FiscalPrinterInterface that allow easier data exchange between the corresponding service and the device implementation: getData with data parameter of type long[] to store currency values and of type int[] to store numbers or counters, getTotalizer with data parameter of type long[] to store currency values and printRecPackageAdjustment and printRecPackageAdjustVoid with additional parameter parsedAdjustments of type Map<Integer,Number> which holds the adjustment amounts with the corresponding vat ids as key. Even if default implementations exist for backward compatibility, it is strictly recommended for implementations based on JavaPOS-SPF to use the new methods to avoid problems due to miss-interpretation of currency values passed in strings.

In addition, event handling does not follow the FIFO (first in - first out) principle strictly: Currently, JavaPOS-SPF uses separate queues for status update events, data and input error events, output complete and output error events and transition events. Direct IO events could be handled by any of the other events queues. Since the corresponding event handles work in separate thread independent from each other, it can happen that an event fired after another event will be delivered before, for example, if FreezeEvents was true while both events have been fired and after FreezeEvents has been set to false, the event handler handling the queue of the first event continued delivery after the event handler handling the queue of the second event. Therefore, the event handler will be changed to be able to follow the FIFO principle strictly (if StrictFIFOEventHandling will be set to true in jpos.xml) or with an exception for data and input error events (which can be bypassed by other events only while DataEventEnabled is false).

Furthermore, the UniqueIOProcessor class and the **SerialIOAdapter **class will implement the AutoCloseable interface to support try-with-resources as specified for Java 7.

Even if all these changes require only little changes in existing driver implementations, this is reason enough to increment the minor number in next release.