[Mono-list] Re: Running .NET

[Robert Deviasse]

>I have not looked much into XSP. I'll have a look.
>What I was planing on doing is a mod_mono for allowing server extentions
>written with mono. The rest of ASP.NET was designed to be in a class lib
>and not to depend on a webserver, so that project can be seperate from
>mod_mono. mod_mono can be shared between an ASP.NET implementation, and an
>XSP implementation.

You're right. It definitely makes implementing XSP easier/faster.

>Another thing that might help to get XSP on mono would
>be to create a java compiler like Microsoft is doing with their new
>j++.net project. Create a java class lib that wrap the .net ones. It then
>would be posible to compile java programs for use with mono without code
>changes.
>

I'd love for Java to be able to compile to .NET, but only if:
* Java could be made to be a .NET consumer and extender with no Java visual
  language extensions (i.e. Java.NET classes can by compiled by a regular
  Java compiler, if the appropriate classes/namespaces are defined)
* When Java is a .NET consumer, it should look like regular Java code 
whenever
  possible.
* When Java is a .NET extender, it should look like regular Java code 
whenever
  possible.
* It were possible to compile large projects like Eclipse and GNU ClassPath
  into .NET without making any (major) changes. IMO, being able to do this
  would be a *major* win for Mono/Portable.NET.
Without something like this, I don't think it's worth the effort. (At least
for me.)

I'm not sure how feasable this is. My gut tells me that it's possible, but 
if
there will be a speed penalty when Java and C# need to use each other's
classes.

Ideally, it could be implemented similarly to the following:
* CLSCompliant compatible classes would derive from the DotNetCLSCompliant
  interface class. The DotNetCLSCompliant inheritance would act as a tag to
  the Java compiler, much like the Clonable and Serializable interface 
classes
  do now.
* .NET Properties would look exactly like their Javabean counterparts,
  i.e. the property myProperty would define a getMyProperty() and 
setMyProperty()
  method
* Classes with attributes would implement the:
           interface DotNetAttributes
		   {
				List getDotNetAttributeList();
		   }
  Each class would be resposible for implementing the 
getDotNetAttributeList()
  method. The main restriction on this method is that the returned List not
  change during the execution of the program.
* When Java is a .NET consumer, it would silently perform translations on 
types
  to make sure that no information is truncated. If such truncation 
guarantee is
  impossible a scheme similar to the COM->.NET proxy class would be used.
* When Java is a .NET extender, it would silently perform translations on 
types
  to make sure that no information is truncated. If such truncation 
guarantee is
  impossible a scheme similar to the .NET->COM proxy class would be used.
* When Java is a .NET extender, Javabean properties would appear to be .NET
  properties.
* When Java is a .NET extender, DotNetAttributes derived classess would 
appear
  to be .NET attributes.
* Java Native methods would be mapped to their corresponding CLR class 
method
  declarations, which may or may not be mapped to actual native methods.
* Delegates would be implemented via inner class callbacks.

The Java compiler for .NET would have to use all this information to 
generate
the right CLR code. If the assembly needs to compile attribute information 
into
the CLR code, the getDotNetAttributeList() code needs to be called by the 
compiler
during the code generation to get this information. This would definitely 
make
the Java compiler one of the more interesting for .NET, but if FORTH can mix
compilation and interpretation, why can't a Java compiler that compiles to
executable .NET byte code?;-)

Realistically, I see it implemented this way:
* To create a CLSCompatible Java class that can be used in .NET:
  * First create a C# prototype class with all the necessary attributes,
    properties, and methods.
  * Compile it as if it were an CORBA IDL definition to generate a Java
    stub class. The compilation should try to map things as close to Java
	style as possible (e.g. the myProperty property would be compiled as
	getMyProperty(), etc)
  * The programmer may now fill in the stubs (just like in CORBA).
* Alternately, Javadoc comments could be used to annotate Java code with the
  necessary CLR extension information and this would be used by the compiler
* To use a .NET module, it has to first be "imported" into the Java 
namespace.
  This importing involves using a tool to write a proxy Java class for each
  CLR class desired.

Either way, it's a lot of work and I think it would be more productive to 
port XSP to Mono directly.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp