Issue 1730:  Changes to Java fixed type mapping (java-rtf)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: The current mapping for fixed type was written with the intention
 of supporting JDK 1.0.2 as well as JDK 1.1.  Recent changes in the
 Java RTF and other recently adopted submissions (Java to IDL) have
 introduced a JDK 1.1 requirement in the Java mapping which make
 it possible to implement certain operations on fixed types in a
 type safe manner instead of the current specification.
 
 

Resolution: closed issue
Revised Text: 
Actions taken:
July 24, 1998: received issue
July 30, 1998: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <gscott@inprise.com>
Date: Fri, 24 Jul 1998 00:07:10 -0700
From: George Scott <gscott@inprise.com>
To: java-rtf@omg.org
CC: issues@omg.org
Subject: Changes to Java fixed type mapping

The current mapping for fixed type was written with the intention
of supporting JDK 1.0.2 as well as JDK 1.1.  Recent changes in the
Java RTF and other recently adopted submissions (Java to IDL) have
introduced a JDK 1.1 requirement in the Java mapping which make
it possible to implement certain operations on fixed types in a
type safe manner instead of the current specification.

Therefore we propose the following changes be made to the Java
mapping:

Mapping of Any
--------------

Remove (do not deprecate) the following methods:

public java.lang.Number extract_fixednum();
public void insert_fixednum(java.lang.Number n);

In their place add the following:

public java.math.BigDecimal extract_fixed();
public void insert_fixed(java.math.BigDecimal value);
public void insert_fixed(java.math.BigDecimal value,
                         org.omg.CORBA.TypeCode type);

The new versions require JDK 1.1, but are type safe and do not
require a cast from java.lang.Number to java.math.BigDecimal.
The additional insert method which takes a TypeCode is a
convenience method.  Fixed types are template types in IDL, so
the TypeCode must be specified for correct type checking to 
occur.  The insert_fixed which does not take a TypeCode assumes
the typecode was previously set by calling the type() method.

InputStream
-----------

Remove (do not deprecate) the following methods:

public java.lang.Number read_fixednum();
public void read_fixednum_array(java.lang.Number[] value, int offset,
                                int length);

In their place add the following:

public java.math.BigDecimal read_fixed();

This is a typesafe version of the above method.  The array method
was removed, because it is not clear how useful it will be since
the Helper class must perform full type checking of all fixed types
in an array of fixed types, just as the Helper would perform bounds
checking on an array of bounded strings.  The current Java mapping
does not define read array operations for such template types (e.g.
there is no read_string_array()).

OutputStream
------------

Remove (do not deprecate) the following methods:

public void write_fixednum(java.lang.Number value);
public void write_fixednum_array(java.lang.Number[] value, int offset,
                                 int lenght);

Replace with the following:

public void write_fixed(java.math.BigDecimal);

The change here is symmetric to the InputStream change.

----------

In all cases the newly defined methods should be non-abstract and
should all throw org.omg.CORBA.NO_IMPLEMENT in their body.

Note, we have favored removal of methods over deprecation because
we do not believe any vendor has implemented the new APIs yet.
If there is strong opposition, the old methods could be deprecated 
instead of removed, but they would be largely useless and just 
clutter the API.

George