This is to announce the availability of an alpha release of ILU 2.0, ILU 2.0alpha14. See ftp://ftp.parc.xerox.com/pub/ilu/ilu.html to download the sources for UNIX or Windows. The Inter-Language Unification system (ILU) is a multi-language object interface system. The object interfaces provided by ILU hide implementation distinctions between different languages, between different address spaces, and between operating system types. ILU can be used to build multi-lingual object-oriented libraries ("class libraries") with well-specified language-independent interfaces. It can also be used to implement distributed systems. It can also be used to define and document interfaces between the modules of non-distributed programs. ILU interfaces can be specified in either the OMG's IDL language, or in ILU's Interface Specification Language, which allows extensions to the CORBA spec. Programming languages supported in 2.0alpha14 are ANSI C, Common Lisp, Java (1.1.x and 1.2), and Python (through 1.5.x); rough Guile Scheme and C++ support is also present. Additional ILU support for Perl is freely available from outside sources. Operating systems supported in 2.0alpha14 are all Windows platforms with Win32 and WinSock, and all UNIX platforms with BSD sockets and minimal POSIX compliance, including Linux, Solaris, AIX, IRIX, and OSF/1. 2.0alpha14 supports interoperability with ONC RPC services, OMG CORBA services, World Wide Web HTTP services, and W3C HTTP-NG services. ``Plug-in'' extensibility is provided for RPC message formats, message transport schemes, URL schemes, accounting and authorization identity types, threading and event loop processing, and various other things. An implementation of the IETF's Common Authentication Technology working group's Generic Security Service (GSS) is provided, and can be used to wrap client-server connections in a security context. An XML parser is provided. ILU is provided free for unrestricted use. Known bugs are listed in the README file. Despite being an alpha release, 2.0alpha14 is very stable along a number of dimensions. Principal areas still under development, and hence unstable, are: the C++ mapping, the HTTP-NG protocols, and the specific contents of the ILU profile in the OMG CORBA IOR. Patches will be appearing in the file ftp://ftp.parc.xerox.com/pub/ilu/2.0a14/patches.html. Please fetch this file and apply the patches before attempting to build ILU. See the beginning of the patch file for information on how to apply patches. Changes from 2.0alpha13 to 2.0alpha14 ------------------------------------- * New Type UID Hash Algorithm. This release introduces a documented algorithm for producing the ILU `type hash' for an ISL type. It's documented in the ILU manual, in the section entitled "Algorithm for Generation of Structural-Hash Type IDs". This algorithm will become the default algorithm for the next release, but the old algorithm is still the default for this release. You can enable the new algorithm with the configuration switch -enable-version-2-type-uids. We recommend that you do this, if possible. ILU configured with the version 2 type uids will *not* be on-the-wire compatible with ILU configured with the old type uids. * Directives in ISL. The ISL syntax has an experimental directives concept. Expect changes before this is made final. * Java support. Supports running ILU and a standard CORBA ORB in the same address space. Optional support for JNI based native methods. Support for jdk1.2. Support for Microsoft sdk3.1. Switchable usage of org.omg.CORBA classes (Java core for jdk1.2 or provided by ILU for jdk1.1). No more problems with the boot class path. Configuration process slightly improved. * Java API changes. Default use of org.omg.CORBA.Object interface as base type for all ILU stubbed objects. Corba system exceptions are no longer subclassed; other minor API changes required for sharing address space with standard ORBs. Most users shouldn't notice these changes. * Java serialization support. Most Java classes and interfaces corresponding to ISL types are now serializable. Among other things, this allows ILU objects to be passed via `Java RMI'. Also, a new ILU interface exists which allows transport of arbitrary Java serializable objects with ILU. Third, a very experimental `DIRECTIVE-EXPERIMENTAL' mechanism which optionally allows classes implementing ILU object types to avoid extending org.omg.CORBA.Object (and optionally, extend java.rmi.Remote). Also, custom mapping may now be specified in the ISL file using the `DIRECTIVE-EXPERIMENTAL' keyword. * Support for Python CORBA mapping. This release includes a preliminary version of the CORBA mapping for Python. You should configure ILU with --enable-corba-python-mapping to get this form of Python support, instead of the "classic" version documented in the ILU reference manual. See `http://www.informatik.hu-berlin.de/~loewis/python/pymap.htm' for more information on this mapping. * Python has experimental support for passing dictionaries. If --enable-python-dictionaries is specified during configuration, the mapping of ISL to Python generated by the stubber will be modified as follows: If a sequence type has a base type which is a record type with two fields, `name' and `value', and the type of the `name' field is an integer or string type, and the name of the sequence type ends with `"dict"' or `"Dict"', the sequence type will be mapped to a Python dictionary instead of to a list. The key value of each item in the dictionary will be the value of the `name' field of a record value, and the value value of the item will be the value of the corresponding `value' field of the same record value. This mapping may change in the future. * Python `auto-import' of ILU interfaces now enabled by default. In this release, loading of the Python `ilu' module will cause a call to `ilu.AutoImport()', with no parameters. This can be defeated by setting the environment variable `ILU_PYTHON_DISABLE_AUTOIMPORT' before loading the `ilu' module, and `ilu.AutoImport' can still be called manually at a later time. * Lisp "old-style" method names not produced by default. The default for lisp is to not produce the old-style method names. Users who need them should specify the --enable-old-lisp-method-names configuration switch to get them.