Interlanguage Working Without Tears: Blending SML with Java
Contents
1. Also subpackages become visible as structures the sample pro gram opens java awt and then uses event ActionEvent to refer to the java awt event ActionEvent class class name field name 4 35 Fields exp field name Static fields are mapped to ML value bindings Fields quali fied by final really are treated as simple values an example of this is the BorderLayout WEST constant used in Figure 1 Non final fields are interpreted as ML value bindings with ref types The implementation permits these to be used in a first class way improving on Java To make this pos sible values of Java reference type are compiled as objects with reader and writer methods immediate assignment or dereferencing compiles to code as efficient as that produced by a Java compiler There is however a small performance hit for ordinary ML ref values that have Java types as if it wasn t for Java these could be implemented more efficiently by performing access and update inline As mentioned earlier we provide explicit provision for null values through the use of option types For example the colour constants provided in the java awt Color class have Java declarations such as public static final java awt Color pink and might be accessed in ML by val SOME pink java awt Color pink Non static fields instance variables are accessed by the new exp field name syntax It is not possible to use a simple dot notation because ther2. Bent Thomsen and Stephen Gilmore amongst others References 1 P N Benton A J Kennedy and G Russell Compil ing Standard ML to Java bytecodes In 3rd ACM SIG PLAN International Conference on Functional Pro gramming September 1998 G Bracha M Odersky D Stoutamire and P Wadler Making the future safe for the past Adding generic ity to the Java programming language In OOPSLA October 1998 3 L Cardelli J Donahue L Glassman M Jordan B Kalsow and G Nelson Modula 3 report revised Technical Report 52 DEC Systems Research Center November 1989 4 H Davis P Parquier and N S niak Sweet Harmony the Talk C Connection In Conference Record of the 1994 ACM Conference on Lisp and Functional 12 5 6 7 8 9 10 11 12 13 14 15 Programming pages 121 127 Orlando Florida USA 1994 S Drossopoulou S Eisenbach and S Khurshid Is the Java type system sound Theory and Practice of Object Systems 5 1 3 24 1999 S Finne D Leijen E Meijer and S Peyton Jones H Direct A binary foreign language interface for Haskell In 3rd ACM SIGPLAN International Con ference on Functional Programming September 1998 K Fisher and J Reppy The design of a class mech anism for MOBY In ACM SIGPLAN Conference on Programming Language Design and Implenentation May 1999 J Gosling B Joy and G Steele The Java Language Specification Addison We
3. all of Java How ever the two worlds were kept fairly separate For exam ple the type Java int represented Java language integers passed to or from external Java code and converting be tween this type and ML s int type required an explicit open javax swing java awt java awt event _classtype SampleApplet JApplet with local val prefix Counter val count ref 0 val label JLabel prefix 0 JLabel CENTER fun makeButton title increment let val button JButton title string val listener ActionListener with actionPerformed e ActionEvent option count count increment label setText prefix Int toString count end in button addActionListener listener button end in init let val SOME pane this getContentPane val button makeButton Add One 1 val button2 makeButton Add Two 2 in pane add button1 BorderLayout WEST pane add label BorderLayout CENTER pane add button2 BorderLayout EAST end end Figure 1 A sample applet in MLj Java fromInt or Java toInt coercion which would actu ally disappear during compilation because ML s int is rep resented as Java s int in the compiled code The extensions for creating classes from within ML included new keywords for all Java class and method attributes even where these overlapped conceptually with existing ML concepts For example the namespace management of Java s static final fields
4. but tedious so for conciseness we 7 c Sw super c T array Sw java lang Object T Xw T option F T XT TST y t T array Xw T array T option Sw T option lt w C JavaType x JavaType Figure 9 Reference widening for Java types T nT T 2nT ee aye super c gt n c java lang Object gt n T array Tont TnT 1 1 T array gt n T array T option gt n T option 2n C JavaType x JavaType Figure 10 Reference narrowing for Java types omit it e super c gives the superclass of c if it exists e staticfields c and fields c give the static fields and non static fields of c as a set of elements each of the form id T e staticmethods c and methods c give the static meth ods and non static methods of c as a set of elements each of the form id 7 for function type T Constructors are treated as static methods with the name lt init gt Note that for fields and methods but not for constructors all inherited members are included For external classes it is assumed that there is a pervasive environment from which the information can be gathered For internal classes the type c itself includes sufficient information though it should be noted that occurrences of the type name t TyName in types of methods and constructors must be expanded to the class definition c itself 6 4 Classes as structures To formalise the use of qualified identifiers for static fields and methods we extend
5. never use the foreign interface ex cept via functionally wrapped libraries written by compiler experts The importance of good foreign language interfaces for functional languages is now widely recognised particularly given the wider trend towards mixed language component based programming Recent years have seen a number of functional interfaces to language independent component architectures notably COM see for example 6 11 and CORBA 10 To quote 6 Programming languages that do not supply a foreign language interface die a slow lingering death good languages die more slowly than bad ones but they all die in the end To appear in the 4th ACM International Conference on Functional Programming September 1999 Paris France Copyright 1999 by ACM Inc Download the current version of the MLj compiler from http www dcs ed ac uk home mlj One of the main motivations for the design of MLj 1 a compiler for Standard ML that generates Java bytecodes was to provide a foreign language interface that would give ML programmers access to the extensive libraries available in Java We expected to be able to implement a much more useful and convenient foreign language interface to Java than is possible for C because the semantic gap between ML and Java is comparatively small e Both languages are strongly typed and there are some good correspondences between the basic types in the two languages For examp
6. the range of a value environment to include a static member reference written member c id where c is aclass and id the name of a field or method Con structors for class c are represented by member c lt init gt The initial environment E under which a program is typed is extended to include packages and classes as struc tures using the member references to fill in variable envi ronments with appropriate bindings for fields methods and constructors 10 a T Llw T ATEST T Xa T1 Te Sa Tay T Xa T Figure 11 Method type conversion 6 5 Typing rules for language extensions The typing rules are presented in Figure 12 in the style of the Definition First note that TE ranges over type envi ronments that map type identifiers to types paired with datatype constructor environments VE ranges over value environments ranges over environments that include type and value environments and C ranges over contexts that in clude environments amongst other information Rules statfld and fld assign types to field access expres sions Rules statmth and mth do the same for methods and incorporate subsumption on method types Rule supmth is similar to mth but starts the search at the superclass Rule cast allows an expression to be cast up or down according to the widening and narrowing relations defined earlier Rule patcast deals with cast patterns The first premise simply ensures that constructors are not rebound As with oth
7. Interlanguage Working Without Tears Blending SML with Java Nick Benton Andrew Kennedy Microsoft Research Ltd Cambridge U K nick akenn microsoft com Abstract A good foreign language interface is crucial for the success of any modern programming language implementation Al though all serious compilers for functional languages have some facility for interlanguage working these are often lim ited and awkward to use This article describes the features for bidirectional inter language working with Java that are built into the latest version of the MLj compiler Because the MLj foreign inter face is to another high level typed language which shares a garbage collector with compiled ML code and because we are willing to extend the ML language we are able to pro vide unusually powerful safe and easy to use interlanguage working features Indeed rather then being a traditional foreign interface our language extensions are more a partial integration of Java features into SML We describe this integration of Standard ML and Java first informally with example program fragments and then formally in the notation used by The Definition of Standard ML 1 Introduction Functional language implementations nearly all provide some way to call external C functions 4 9 12 but direct in terworking with a low level non typesafe language with no garbage collection is never going to be easy or pretty Most functional programmers
8. U ClassType c ClassType T JavaType c option JavaType T JavaType T JavaType T array JavaType T array option JavaType JavaType C Type Figure 6 Java types ml boo1 bool ml byte Int8 int ml char char ml double real ml float Real32 real ml int int ml long Int64 int ml short Int16 int ml c c option mI T 1 ml T array option ml T Ti Ta ml void 71 Tn ml T1 x x mI Th gt unit Figure 7 Translation from Java types style used by The Definition 13 4 2 c ClassType ExtClass U MLClass tT Type TyVar U RowType U FunType UConsType U ClassType Class types are either external obtained from existing Java code and represented by the fully qualified name of the class or are internal introduced through _classtype ic MLClass TyName x ClassType x TypeSet x MethEnv We write class t c 7 ME for elements of MLClass Here t is a stamp that identifies the class and allows recursive ref erence in its definition c is the superclass 7 is a set of con structor types with zero or one elements and ME specifies the methods as a set of bindings of the form id 7 The set of classes that are exported by means of a compiler direc tive is given by ExpClass C MLClass We let ec range over ExpClass U ExtClass Finally we define JavaType C Type by the inductive definition presented in Figure 6 Figure 7 defines a tota
9. _classtype id pat ty exp with local dec in method dec end gt TE VE in Env c class t c r t ME for fresh t TE fide gt le D where VE id member c lt init gt lt init gt T staticmethods c C C TE VE VE this c v C F erp gt T CF method dec gt ME method dec C F id exp and method dec id T ME Specifications C TEF ty gt 7 CE ty gt d class spec C TEF method spec gt ME Cl _classtype id ty typ with method spec end gt TE VE in Env c class t c 7 t ME for fresh t where TE id c VE id member c lt init gt Chkty gt r C F method spec gt ME CF id ty and method spec gt id T ME method spec Figure 12 The typing rules 11 sometimes requires type constraints to be added in unpre dictable algorithm dependent places More speculative further work might include adding pa rameterized classes in the style of GJ 2 or defining uni form representations of ML types to be enforced only on the ML Java interface so that ML values could be passed to Java code for purposes such as serialization for persis tence or mobility It might also be interesting to take the object oriented aspects of MLj further for example by al lowing more general subtyping and overloading on ML val ues Such a language would no longer be SML however and would probably be less natural as an object oriented
10. a io InputStream in is interpreted as having type java io InputStream option Fields not qualified by final are mutable and their types are interpreted using ML s ref type constructor So a field declared by public static byte b is given the ML type Int8 int array option ref 3 5 Method types Java method types are interpreted as follows First void methods are considered as having unit result type similarly methods that take zero arguments have unit argument type Second Java has a syntax for multiple arguments but ML does not so methods with multiple arguments are given a single tuple argument type The alternative a curried func tion type presents no problems but the syntax of method invocation inside ML would then be very different from the syntax in Java Finally when arguments and results are ob jects or arrays their types are interpreted using the option type constructor as described earlier Consider the following two prototypes taken from the system class java lang String public static java lang String copyValueOf char int int public java lang String toString Their types are interpreted respectively as char array option int int gt string option and unit gt string option 3 6 Overloading and implicit coercions Java permits the overloading of methods the definition of multiple methods with the same name within a single class The methods are distinguished by their argument typ
11. a method prototypes Note that only one version of this map is required as functions can only be exported however if Java supported first class methods then it would make sense to define its dual jZ that reversed the polarities for argument and result types With these definitions we can formalise the exportable ML types as dom j for fields and domj for methods 6 2 Relations For two Java types T and 7 we write T lt w T whenever values of type T can be converted by a widening reference conversion 8 5 1 4 to type T or by the identity or by the injection represented by SOME a gt a option This re lation is defined inductively in Figure 9 Likewise we write T gt n T whenever values of type T can be converted by a narrowing reference conversion 8 5 1 5 to type 7 or by the identity as defined in Figure 10 We write T lt a T whenever argument values of type T can be converted by method invocation conversion to type 7 which we define to mean either widening reference con version on Java type or the identity Finally for method types of the form 7 X X Tn T we write T Sm T when ever method type T can be converted to method type 7 Following Java we support contravariance in the argument types but no variance in the result These last two relations are given in Figure 11 6 3 Class lookup We define various helper functions on classes Their formal isation is straightforward
12. and getY y and move xinc yinc x x xinc y ytyinc and moveHoriz xinc this move xinc 0 and moveVert yinc this move 0 yinc end _classtype ColouredPoint x y c with Point x y getColour c java awt Color and move xinc yinc this move xinc 2 yinc 2 end end Figure 2 Coloured points in MLj both to these arguments and to the bindings introduced by local The ColouredPoint class derives from the Point class passing two of its constructor arguments straight on to its superclass constructor It has no local declarations and a new method that simply returns its colour In order to im plement this method using Java s class mechanism the com piler will probably store c in a Java field but note that the only means of accessing it from MLj is through the method provided Because the declarations are local to the class instance it is not possible to gain access to the corresponding dec larations for other instances of the class In Java private fields for other instances can be accessed directly for exam ple to implement an equals method In MLj this can be emulated by providing appropriate get and set methods for the fields then hiding these by a signature as explained below The special identifier this has the same meaning as in Java referring to the object on which a method was invoked It is used in Point to define horizontal and vertical move ment using the mor
13. and or method names used in the generated bytecode which the compiler is otherwise free to choose An ML class type may be bound to multiple type identifiers for example via structure re binding However two ML class types with the same stamp generated when the class is defined or a functor is applied may not both be exported Together with the requirement that the superclass of an exported class must be external or exported we believe that this allows the compiler to pick method names so as to avoid the accidental or unsound overrides which might otherwise happen when a superclass method was hidden by a signature and a subclass then over rode that method This potential conflict between object extension and width subtyping is well known see 15 for example 6 Formalisation A complete formalisation of the ML Java interface would end up specifying the static and dynamic semantics for a substantial part of the Java language We do not attempt to do this the interested reader should consult 5 Rather we give only the static semantics the typing rules for our language extensions moreover we omit certain details such as access control and checking of class and method qualifiers 6 1 Types and translations We start by extending ML types with a new category of class types ranged over by c and specified formally in the PrimType bool int char real Real32 real YPE Int8 int Int16 int Int64 int T PrimType
14. and static methods provided by classes overlaps the scoping of ML value bindings provided by the module sys tem and mutable fields are similar to ML refs Experience with the MLj 0 1 extensions showed that they were extremely useful but that there was plenty of scope for improvement Amongst other things the strict separation of primitive types was unnecessarily annoying there was too much baroque syntax associated with the embedding of Java in ML some of which was rarely used because there were better ways of using existing ML constructs to achieve the same effect and one often wished to treat Java fields and methods in a more first class way This article describes the revised design of the inter language working extensions that is being implemented for the next version of MLj and the rationale for that design The new extensions are much more of an integration of Java concepts within ML than an interface between the two languages though for compatability with SML we have stopped short of trying to design a fully fledged natural object oriented extension of ML We also sketch a formali sation in the style of the Definition of Standard ML 13 We assume a knowledge of ML and a passing familiarity with Java Note that for clarity of presentation we omit certain features of the ML Java interface in particular the use and definition of Java interfaces and the formalisation of certain aspects 2 Design goals We wanted ML c
15. as possi ble so that a programmer can use it without to much of a mental context switch To attain simplicity as many ML concepts as possible were re used for ex ample packages are identified with structures and sub packages with substructures but this was done only where it makes sense semantically for example static methods are like ML functions but non static virtual methods are not e Compatibility correct programs written using SML 97 should typecheck and execute without alteration This severely constrained the syntax extensions that we could use but we believe that our design is tasteful and unobtrusive We have not quite managed to pre serve all the equations which hold in SML 97 since for example Charges Mey and let val x h i in x x end are not contextually equivalent as Java can check ob ject identity e Safety one pleasant aspect of Java is that type safety is built in In contrast to C programs cannot cor rupt the store leave pointers dangling and so on However ML goes further insisting that values are bound explicitly at their definition whereas in Java the possiblity of a default null value can lead to a NullPointerException To retain the spirit of ML we are quite strict about values of Java class and array types insisting that null values are checked for explic itly Java notion ML notion new syntax primitive type base type class name type identifier array type arra
16. cations of a principal con structor e The optional ty exp specifies a superclass type ty and an argument or tuple of arguments exp to pass to the superclass constructor e dec is a set of SML declarations that are local to a single instance of the class e method dec is set of instance method declarations de fined using the syntax already used for ordinary func tions but with optional qualifiers abstract final and protected preceding the method identifiers e We follow Java in allowing several classes to be defined simultaneously by mutual recursion using the keyword and to separate the declarations In keeping with tradition and to demonstrate that classes are usable in MLj without reference to Java Figure 2 presents a variation on the classic coloured point example A striking aspect of the new construct is the absence of any direct support for field declarations Instead the decla rations following local are evaluated when a class instance is created but are accessible from the method declarations for the lifetime of the object In this example we have mim icked private mutable fields using ref bindings x and y with initial values provided by arguments to the construc tor xinit and yinit The methods which may be mutu ally recursive as suggested by the and separator can refer structure PointStr struct classtype Point xinit yinit with local val x ref xinit val y ref yinit in getX x
17. e arg are the argu ments to one of the constructors defined by the class We avoid the need for any new syntax in MLj by binding the class name itself to the constructor function If there is more than one constructor then the binding is overloaded For example the constructors for javax swing JButton ap pear as bindings to the identifier JButton inside the struc ture javax swing This is illustrated in Figure 1 in the construction of JLabel and JButton objects As with methods constructors can be used as first class values and implicit coercions are applied using the same rules For example val labels map javax swing JLabel A B expression pattern exp gt ty 4 6 Casts and typecase id gt ty A new syntax is introduced borrowed from O Caml 14 12 to denote Java style casts It can be used to cast an object up to a superclass val c JButton My button gt Component Explicit coercions are sometimes required when passing Java objects to ML functions as coercions are only applied im plicitly when invoking Java methods The same syntax can also be used to cast an object down to a subclass with Java s ClassCastException thrown if the actual class of the object is not compatible A safer alter native that combines downcasting with Java s instanceof is the use of gt inside ML patterns This can be used to provide a construct similar to the TYPECASE of Modula 3 3 and other lan
18. e general move method However we do not support super as its semantics in Java confusingly differs depending on whether it is used to access a field in which case it has the same meaning as a cast up to the superclass and so is superfluous or to invoke a method where it has a different run time semantics namely to ignore the over riding of the method in the subclass Instead we provide a syntax exp method name that can be used only within a class definition on objects of that same class and means invoke method method name in the superclass ignoring any over riding of the method in the current class It is used in ColouredPoint to redefine move using the move method defined in Point making coloured points faster movers than plain points By the magic of virtual method dispatch the moveHoriz and moveVert in herited by coloured points also inherit this speed increase We allow references to this in the superclass construc tor arguments and in the local declarations Unfortunately this opens up a type loophole as methods invoked on this _classtype C with m this m2 and m2 0 end _classtype DO C O with local val x this m in m2 hd x end val dobj D Figure 3 A small type loophole may make use of local identifiers not yet bound Outlaw ing this completely is too strong a restriction as many classes set up initial state through methods in the super class and the w
19. e would be no means of distinguishing such expressions from those used for static field access Here exp is an ML expression of class type and field name is a Java field name As with static fields non final fields can be used as first class ref values class name method name 4 4 Methods exp method name Static methods are mapped to ML value bindings of func tion type Again we improve on Java and permit such functions to be used in a first class way by eta expanding where necessary val colours map val0f o java awt Color getColor red green blue Here we have made use of the automatic insertion of the SOME coercion as discussed in Section 3 6 as the getColor method is interpreted as having the type string option gt java awt Color option but values of type string are passed to it Non static virtual method invocation uses the syntax exp method name where exp is an expression of class type and method name is a method defined or inherited by that class There are many examples of this in Figure 1 the label setText invocation again illustrates a coercion from string to SOME string and the pane add invocation il lustrates class coercions to Component option and over loading as the add method has many alternative argument types 4 5 Object creation class name exp In Java new instances of a class are created using the syn tax new class name arg arg wher
20. eaker restriction of allowing only methods in the superclass to be invoked does not fix the situation as the example in Figure 3 demonstrates The behaviour of this program is ill defined in fact it is likely that the ex ception List Empty will be raised when m2 attempts to take the head of a list that has yet to be defined The root of the problem is the combination of object initialisation and dynamic method dispatch on the object being initialised The same problem exists in Java 8 12 5 and enforcing strong restrictions would have reduced expressivity without completely closing the hole because of virtual method invo cations inside an external superclass constructor As mentioned in Section 3 6 Java allows overloading of methods We support this in _classtype declarations in order to extend existing Java classes that include overloaded methods No special syntax is required the method name is simply repeated in separate declarations as in the example below _classtype C with m x int process ints and m x string option process Strings end 5 3 Class types in signatures _classtype cmod class name ty ty with method spec end Corresponding to the class type declaration there is a class type specification construct for SML signatures Here ty is the type of the constructor argument s bound by the pat tern expression pat in the corresponding class type declara tion and ty is the supe
21. er pattern expressions in ML the pattern elaborates to a value environment that gives types to variables bound to the pattern in this case the type specified in the cast and a type for the match itself in this case a type from which a value is cast Rule class dec elaborates a class type declaration to pro duce a type environment TE with the new type and a value environment VE with the constructor The first premise deals with the formal arguments to the constructor with TE present in the context so that type constraints can re fer to the new class type c The second premise elaborates the superclass type c The next two premises elaborate the arguments to the superclass constructor exp and local decla rations dec respectively both typed in a context C contain ing value bindings for the constructor arguments VE the constructor for the new class VE and this Finally the method declarations method dec are elaborated in the pres ence of the environment F built up by the local declarations to produce a method environment ME In the corresponding rule class spec for signatures notice that the constructor type ty is optional allowing for the hiding of constructors in signature matching 7 Conclusions and further work One immediate area for further work is improving the type inference process for our extended language The main prob lem with is in resolving method overloading the typing rules above do not specify ju
22. es Furthermore method invocations implicitly coerce arguments up through the class hierarchy The combination of these features can lead to ambiguity which Java com pilers resolve statically by picking the most specific method with respect to an ordering on argument types rejecting a program if there is no unique such method MLj allows implicit coercions on method invocation us ing Java s reference widening coercions together with an ad ditional coercion from 7 to Toption for any Java reference type T We do not allow Java s numeric widening coercions to be implicit as the spirit of ML is to use explicit conver sions such as Int64 fromInt for these We do not allow ambiguity to be resolved by Java style most specific method rules as these interact unpleasantly with type inference our intention is to have typing rules and an inference algorithm such that a program is accepted iff there is a unique resolution of all the method invocations with respect to the rules Use of the most specific rule during inference can lead to type variables becoming bound and hence ambiguities far from the point of the rule s appli cation being resolved in unexpected ways 4 Accessing Java from ML 4 1 Packages subpackages and classes If one ignores the class hierarchy and non static fields and methods i e a non object oriented fragment of Java then Java packages and classes can be seen and are used as a minimal module syste
23. functions or even inside methods defined in other class declarations Variables captured by such decla rations are implemented using the same mechanism as used for inner classes in Java the compiler generates instance variables that are filled in when objects are constructed Java also extends its new construct for object creation to allow the definition of a new unnamed class and at the same time create an instance This provides a kind of first class function mechanism and is used extensively for callbacks in GUI programming MLj supports a similar syntax class name exp with method dec end It is used in Figure 1 to create an ActionListener object in which the actionPerformed method is over ridden to pro vide functionality specific to a button component In fact ActionListener is an interface for conciseness we have omitted discussion of interfaces in this article 5 5 Class types and functors The Java language and the JVM do not currently support parametric polymorphism Therefore we restrict the types of methods in classes to be monomorphic However by using SML s powerful functor construct it is possible to parame terise classes on types and values Figure 5 gives an example When applied to a particular type T the functor provides a new class type J and functions wrap and unwrap that con vert values between T and J The specification of J in the signature of the result hides both the class constructor and i
24. guages Suppose that a parser was written in Java and used subclassing of a class Expr to represent differ ent node types Then we could traverse the parse tree using case analysis case expr Expr of ce gt CondExpr gt code for conditionals ae gt AssignExpr gt code for assignment The pattern id gt ty matches only when the examined ex pression has the class type ty in which case the identifier id is bound to the expression casted down to type ty The new construct is a pattern like any other It can be used in val bindings such as val x gt java awt Window y to give an effect similar to downcasting in expressions but raising ML s Bind exception when the match fails It can also be used in exception handlers such as val result f y handle e gt java lang SecurityException gt 0 in order to handle and possibly deconstruct Java ex ceptions The order in which handlers appear is impor tant In the example below IllegalArgExn subclasses RuntimeException so if the handlers were switched the sec ond handler would never be reached fun test x do_some_java x handle y gt IllegalArgExn gt f y _ gt RuntimeException gt g x Finally the behaviour of Java s e instanceof c can be emulated by case e of _ gt c gt true _ gt false 5 Creating Java classes in ML So far we have seen how to access external Java code from ML We now turn to the problem of creating ne
25. his safety in our Java extensions to ML and so interpret a value of Java reference type as non null instance Nevertheless when a Java field of reference type is ac cessed from ML or a value of reference type is returned from an external Java method invoked by ML it may have the value null and this must be dealt with by the ML code Also it should be possible to pass null values to Java meth ods and to update Java fields with the null value Fortu nately the ML basis library already defines a type that suits this purpose perfectly datatype a option NONE SOME of a The val0f function of type a option gt a can be used to extract the underlying value raising Option when passed NONE We interpret values of Java reference type that cross the border between ML and Java as values of an option type For example a stand alone Java application must have a method main with the following prototype public static void main java lang String Inside ML the single argument to this method is treated as a value of type string option array option meaning a possibly null array containing possibly null strings 3 4 Field types Java fields qualified by the keyword final are immutable and their types are interpreted as indicated above us ing option to denote the possibility of null values for ob jects or arrays For example the field declared in the java lang System class as public static final jav
26. ire us to use a predictable uniform representation for ML values which would inhibit many of the optimisations performed by our compiler How ever it seemed unduly restrictive to prevent classes created from within an MLj program but which do not get exported to the external Java world from making free use of values of arbitrary ML types This introduces a slight complication into our model as some MLj classes are now regarded as exportable and others as purely internal the details are explained later Table 1 summarizes the correspondence between Java concepts and existing SML concepts or new features that we introduced The code in Figure 1 illustrates many of these and we will use it as a running example throughout Two buttons control the incrementing of a common counter that is displayed in the centre The code is for JavaSoft s Swing GUI framework 3 Types 3 1 Primitive and class types The Definition of Standard ML 13 does not specify the base types of the language and the Standard Basis library speci Java type ML type boolean bool byte Int8 int char char double real float Real32 real int int long Int64 int short Int16 int java lang String string java lang Exception exn java math BigInteger IntInf int java util Calendar Date date Table 2 Correspondence between types in Java and ML fication does not prescribe particular sizes for numeric types instead leaving it up to the implemen
27. l function ml that maps syntactic Java types onto their ML interpretation It is extended to a function that maps Java method prototypes to ML function types The mapping from ML types to Java types is given in Figure 8 It is necessarily partial and splits into two variants j is used to translate types for values that are exported re sults of functions and final fields and j for values that are imported arguments to functions The notation j just indicates simultaneous definition of both maps at primitive type where they coincide The difference between the two ml Ti x x mI Ta gt mI T j boolean boolean j gt Int8 int byte j char char j real double j Real32 real float j int int j Int64 int long j gt Int16 int short J ec ec j ec option ec j r arvay 2 Peo j 7 array option ji O j ec option ec j 7 array option jy 0 ji m X X Tn gt unit void G n J gt m JE Ti X X Tn gt T j r G T j7 m Figure 8 Translation from ML types is that the option tag on a non primitive type is permitted for export but required for import Java does not make the distinction between non null and possibly null values so we have to assume the worst when importing values from Java Observe that ml oj and mlo j are the identity on Java types The two maps are used to define a mapping jt from function types to Jav
28. le The numeric types are a close match Strings are immutable vectors of possibly null characters in both languages Array bounds are checked in both languages Neither language has explicit pointer types e Both languages have automatic storage management Furthermore because we compile ML code to Java bytecodes we actually use the same garbage collector for ML and Java objects so there is no need to deal with references between independently managed heaps e Exception handling in the two languages is similar There are however still significant differences between the two languages the concepts of objects classes inheritance and dynamic method dispatch which are at the heart of Java have no natural counterparts in ML and Java lacks many features of ML such as parametric polymorphism and higher order functions We did not wish to burden users with the complexities of a separate Interface Definition Lan guage IDL as is used for COM and CORBA so the natural if unusually bold approach was to extend SML with types and terms corresponding to Java constructs Doing this well is a very tricky language design problem the unattainable ideal would be an object oriented conservative extension of ML which still maintains the spirit of ML but which also corresponds naturally and predictably to the type system of Java The first version of MLj release 0 1 extended SML with types and syntax which covered essentially
29. m having equality status 3 2 Arrays Java arrays have virtually identical semantics to ML arrays their size is fixed at creation time indexing starts at zero equality is based on identity not value and an exception is raised upon out of bounds access or update Therefore the ML array type constructor array corresponds to Java s array type constructor The single glitch is Java s unsound covariant subtyping on arrays and its corresponding dynamic check on array update to fix up the unsoundness For ML arrays imple mented using Java arrays this check always succeeds and is therefore unnecessary but unfortunately must introduce some performance overhead lIn fact we depart slightly from the basis specification in adopting Java s use of Unicode for characters and strings the basis prescribes ASCII 8 bit characters 3 3 Null values In the Java language variables with class or array types known collectively in the Java literature as reference types are allowed to take on the value null in addition to object or array instances Operations such as method invocation field access and update and array access and update raise NullPointerException if their main operand is null ML does not have this notion and values must be bound explicitly when created Thus operations such as assign ment indirection and array access and update are inher ently safer than the corresponding operations in Java We wished to retain t
30. m providing a way of carving up the namespace for fields and methods into manageable chunks We therefore chose to model them using the SML module system Top level packages in the Java world are reflected in ML as a collection of top level structures with subpackages as substructures Classes are reflected as three separate bind ings as type identifiers as values of function type used to construct instances of the class discussed later and as structures containing value bindings that reflect static fields and methods For example within the package java lang reflected as a structure lang inside a top level structure java the class Integer is mapped to an ML type identi fier Integer to a value identifier Integer and to a struc ture Integer There is no problem having types values and structures sharing a name as they inhabit different names paces in SML open package 4 2 Import as open open classname Packages and classes interpreted as structures can be manip ulated like any other structure in SML they can be rebound constrained by a signature passed to functors and opened Opening of packages as structures is analogous to Java s import package construct for example the declaration open javax swing in Figure 1 is roughly equivalent to import javax swing However when used with classes as structures the open mechanism is more powerful permit ting unqualified access to static fields and methods
31. ode to be able to read and write exter nal Java fields call external Java methods and treat exter nal Java objects in a first class way storing them in ML data structures passing and returning them from ML func tions We also wanted ML code to be able to define new Java classes which extend existing external classes and im plement external interfaces with methods written in ML These classes should be accessible and usable either from within the ML program or by other external Java code In addition to these basic goals we wanted the interface to have a certain flavour At first we took the view that the interface could be slightly ugly when compared with ML itself as it would only be used by library writers to provide a functional wrapper around an existing Java package in deed the strangeness of any new syntax would serve as re minder that the programmer was doing something reserved for experts However once we discovered how useful and pleasant it was to have straightforward safe interoperabil ity with Java s standard library code and third party Java applications and sometimes even to develop new mixed language applications from scratch we began to think that this should be made as convenient and natural as possible Therefore in the most recent version of the foreign language interface we have aimed to provide e Simplicity the syntax used to access Java classes and to create new ones should be as lightweight
32. rclass The method specifications method spec list function types for each method The types in the signature must correspond exactly to those in the corresponding declaration but methods can be omitted in the same way as value bindings can be omitted from an ordinary SML signature This lets the programmer hide methods from users of a class corresponding to private methods in Java or to share methods amongst a number of classes in a single module but to hide them from clients of the module corresponding roughly to package access in Java signature POINTSIG sig _classtype Point int int with getX unit gt int and getY unit gt int end _classtype ColouredPoint int int java awt Color Point with getColour unit gt java awt Color end end Figure 4 A signature for coloured points A similar treatment of privacy is used in Moby another ML style language with OO features 7 Figure 4 presents a signature that might be used to con strain Point to be an immovable point when used by clients of the module In the specification for ColouredPoint the methods inherited from Point are not listed explicitly but are still accessible It is not possible to over ride or inherit a method and at the same time reduce access to it in keeping with Java s own rules 5 4 Inner classes There are no restrictions on the scope in which a _classtype declaration can appear As with Java 1 1 classes can be nested inside
33. sley 1996 L Huelsbergen A portable C interface for Standard ML of New Jersey Technical report AT amp T Bell Laboratories January 1996 See http cm bell labs com cm cs what smlnj D Jeffery T Dowd and Z Somogyi MCORBA A CORBA binding for Mercury In Practical Aspects of Declarative Languages First International Workshop volume 1551 of Lecture Notes in Computer Science Springer Verlag January 1999 X Leroy Camlidl user s manual version 1 0 March 1999 See http caml inria fr camlidl htmlman X Leroy D R my J Vouillon and D Doligez Objective Caml user s manual 1998 See http pauillac inria fr ocaml R Milner M Tofte R Harper and D MacQueen The Definition of Standard ML Revised MIT Press Cambridge Mass 1997 D R my and J Vouillon Objective ML An effective object oriented extension to ML Theory and Practice of Object Systems 4 1 27 50 1998 J G Riecke and C A Stone Privacy via subsump tion Theory and Practice of Object Systems 1999 To appear
34. st how and where the resolution is done We do not wish to insist on explicit type constraints being added all over the place but it does not seem possi ble to use the usual syntax directed inference system with constraints solved on the fly by unification because ambi guities are sometimes only resolvable by considering a whole compilation unit The right thing to do is to gather up the constraints generated by the above rules and try to solve them all together for each top level structure and this is what we plan to do Our current working version however uses essentially the same algorithm as we use for SML this 1 1 TIX XTn gt T Im X60 XT gt T Expressions C longvid member c id Cr erp gt c statfid id T staticfields c fid id T fields c C F longvid gt T C F exp id gt T C longvid member c id Senni CF erp gt c oa ol statmth id T staticmethods c St mth id 7 E methods c ETEN C H longvid gt T C F erp id gt T C F erp gt c 1 supmth id T methods super c T Sm T cast CK exp gt Cryst Se Or Tian T C E exp id gt T CF ezp gt ty gt T Patterns vid Dom C or is of C vid v CF ty gt rT T LSwT ort nT patcast Ch vid gt ty gt vid gt T v T Declarations C TEF pat gt VEp T Crtysc C F ezp gt T class dec C dec gt E C E method dec gt ME H T lt mT OC Cl
35. t true as the following example demonstrates structure S struct val x ref 5 val y x end It is not possible to express this kind of aliasing using Java mutable fields Methodologically the absence of static non final fields is no great loss as it is poor object oriented style to provide direct read write access to what is essentially a global variable 5 2 Creating instantiable classes from ML _classtype cmod class name pat ty exp with local dec in method dec end The export of structures as classes provides a means for Java to call ML but it does not allow for the creation of class libraries with an object oriented interface neither does it allow for the specialisation of existing Java classes with new instance methods coded in ML For this we introduce a new construct whose syntax is shown above This introduces a new class type class name defined by the following elements e The optional class modifier in cmod can be abstract or final and has the same meaning as in Java e The expression class name pat acts as a constructor header with pat specifying the formal argument or tuple of arguments to the constructor Any variables bound in pat are available throughout the remainder of the class type construct an idea that is borrowed from O Caml 14 12 Unlike Java multiple constructors are not supported a future enhancement might allow additional construc tors to be expressed as invo
36. tion Hence we were able to match ML base types to Java primitive types avoid ing the need for unpleasant coercions when passing values of base type to and from Java Table 2 gives the correspon dence that we used The first eight entries in the table are the Java primitive types The remainder are class types which can be referred to from within ML using the same syntax as in the Java language so for example java lang StringBuffer is a Java string buffer and java awt Color is a Java colour This syntax works because of the interpretation of Java packages as structures and subpackages as substructures discussed later There arises the question of which Java types should be given equality status within ML that is permitted as ar guments to ML s polymorphic equality operator For the base types listed in Table 2 the Basis Library forces the issue all are equality types except for real Real32 real exn and Date date For other class types there are three alternatives equality by identity Java s operator user defined equality Java s equals method or no equality at all The first can be rejected as being outside the spirit of ML and would in any case conflict with equality by value on strings and big integers the second also does not have the right flavour as is an equivalence relation for all appli cable types in ML and user definability would break this therefore we decided to exclude general class types fro
37. ts method and thus is exportable in the sense described in the previous section The class types IntListWrapper J and IntFunWrapper J can then be used in Java code to pass around objects that wrap up ML values of type int list and int gt int If one wished to use these wrapper classes to for example store ML values in Java collections one would also have to include a hash function in the class functor Wrapper type T gt sig _classtype J val wrap T gt J val unwrap J gt T end struct _classtype J x T with get x end fun wrap x T J x fun unwrap j J j getQ end structure IntListWrapper Wrapper int list structure IntFunWrapper Wrapper int gt int Figure 5 Using functors 5 6 Exporting classes To make a class visible to the Java world it is exported us ing a compiler directive Its methods must be exportable ac cording to the same rules that were described in Section 5 1 Non exported classes are used only within an MLj pro gram so no restrictions are placed on the types of their methods Note however that when a class overrides a method from a superclass its types must match exactly a method in a non exported class that over rides an external Java class or an exported MLj class must therefore also have exportable type There is another restriction on what may be exported caused by the fact that exporting classes and overriding im ported methods both fix the actual class
38. version of ML than say OCaml 14 because of the need to match Java Indeed our extensions have already become more like an object oriented extension of SML than we originally in tended The main limitation of our approach is that the exten sions are non standard and specific to Java Foreign in terfaces based on COM or CORBA by contrast allow in terworking with components written in many different lan guages We did try using our extensions plus a Java ORB to make ML interface to CORBA components this was suc cessful but the CORBA bindings for Java were a great deal more unpleasant to use than a direct mapping of CORBA to ML would be Nevertheless the interlanguage working extensions de scribed here are we modestly believe far more pleasant to use than any comparable system There is no need to worry about linkers interface definition languages stubs marshalling and unmarshalling or memory management working with Java from ML is much like working with Java from Java and sometimes better In particular our deci sion to map Java constructs to ML ones where possible but not to be afraid to extend ML where such a mapping is not natural seems to be have been a good one The latest version of the MLj compiler is available from http www dcs ed ac uk home mlj Acknowledgements The evolution of the ML Java interface has benefited greatly from our many discussions with George Russell Dave Halls Audrey Tan Ian Stark
39. w Java classes inside ML 5 1 Static classes As we have observed already static fields and methods are orthogonal to the object oriented nature of Java and are reflected as bindings in SML structures We follow this cor respondence in allowing the export of SML structures as Java classes containing only static members This requires no new language constructs instead a compiler directive is used to specify which top level structures are to be exported as named classes The signature of the structure is interpreted in the fol lowing way e Value bindings with function types are exported as public static methods with the same name provided that the function type is exportable e Other bindings are exported as static final fields with the same name provided that the value type is ex portable In essence an exportable type is one that safely captures the way in which a field or method can be used from the Java world Thus pure ML types such as int list are not permitted as Java programs have no way of knowing how these are represented For Java reference types the option type constructor must be applied whenever it is possible for Java to construct null values This is true for method arguments because a Java program could pass in null but not for method results or fields We do not provide for the export of mutable fields Whilst Java s mutable fields can be modelled using ML s first class refs the converse is no
40. y type null value NONE void type unit type multiple arguments single tuple argument mutable fields ref type package structure subpackage substructure importing a package static field value binding static method function binding opening a structure non static field access non static method invocation and object creation function binding casts gt in expressions instanceof gt in patterns class definition _classtype private fields local declarations private package access methods signature matching Table 1 Analogies between ML and Java e Power Many of the constructs that we provide corre spond quite closely with those found in the Java lan guage both syntactically and semantically but there were a few places where we were able easily to improve on Java for example making methods and fields first class and by introducing a type case construct Just as important as our goals is one of our non goals We decided that at least at this stage we would not al low arbitrary ML values such as closures or values of user defined datatypes to be passed to external Java code This a seemed less useful than the ability to pass values the other way any external Java code that could do anything interesting with an ML value would be better written in MLj b would potentially compromise safety by for ex ample allowing Java code to mutate supposedly immutable ML values and c would requ
Download Pdf Manuals
Related Search