Re: [Gen-art] Gen-ART review of draft-carpenter-renum-needs-work-04

[Ran Atkinson <[e-mail]>]

On 30  Nov 2009, at 12:51 , Vijay K. Gurbani wrote:
> ...it is not the
> case that Java is exposing some additional functionality that
> C/C++ do not. 

Indeed.  That is precisely our point, although phrased in an
inverse manner.

The more abstracted Java Networking APIs *HIDE* some low-level/
more-specific networking information from application programmers.  

As with the standard situation in Computer Science, such use of
information hiding encourages application programmers to use 
properly high-level and abstract designs both for their applications 
and their application protocols.  

In turn, this tends to make the resulting applications more 
tolerant of changes to low-level networking details (e.g. changes 
to an IP address).  As our draft is entirely about the issues and
limitations of IP renumbering, this is precisely on point and
within scope for our draft.

As an aside, I'm told that Apple's COCOA APIs (and possibly also 
some proprietary Microsoft Windows APIs) also engage in significant 
information hiding, for the same reasons as the more abstract Java
networking APIs, and likely with the same benefits.  However, 
those are not open-standard C/C++ networking APIs, but rather 
platform-specific networking APIs.  So they don't make very good
examples.  The abstracted Java networking APIs are, however, both
platform-independent and open-standard, which is why those are 
particularly good examples for our document.

[And yes, I know that some Java instances might contain ugly
low-level networking APIs.   THese are not commonly used,
however, and programmers don't have the equivalent choice of
API abstraction in open-standard C/C++ today (at least for 
platform-independent software) that they do today in open-standard
Java.  The point is not that one could write bad software.  The 
point is that Java encourages one to write good software by having 
suitably abstracted APIs as the "normal" and most commonly used/taught 
networking APIs.  It is a pity that such abstracted APIs were not
openly specified by the IETF during the protracted IPv6 process.]

Cheers,

Ran