hello! > Although similar, I don't think the two libraries are close enough to > perform this mapping successfully. I think such an approach will provide > shallow interoperability that initally looks good, but worsens the more > complexity you introduce. My personal feeling is that cross-compilation > (like http://www.go-mono.com/java.html) doesn't add as much value as > "bridging"...
I think you should handle specially a few classes, and the rest would come from an existing class library like GNU Classpath. > (c) Complex pass-by-value objects which likely as not have no > representation in the other framework; imagine sending eg a > javax.swing.JButton to .Net (remember it cant instatiate it directly as > .Net doesn't understand the Java class definition). How is .Net going to > handle this piece of data? It is a problem for a full bridge, but not for a common subset. For example, take the .NET Common Type System (CTS): it defines a subset of the features available to languages (and it is for example a subset of C#, not every C# feature can be exposed to the CTS). Trying to solve the very complex problem of a perfect mapping is the path to oblivion, you want to make a compromise, and go for a subset. CORBA for instance defines a nice subset that maps to a number of modern languages. > Since this is a .Net focused list, I guess there is greater interest in > making Java work with .Net than the other way round. Therefore, > obtaining or producing some specification of the Remoting binary > protocol seems a critical early step. This may mean reverse-engineering > it from the shared source CLI. Well, I would be interested in having a BinaryFormatter implementation, as we do not even have one today, but from the looks of it, its probably the worst thing we can do. I really want to encourage people to work on a CORBA implementation. Miguel _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
