A funny idea

[Jeff Varszegi]

I was reading over some of the technical information about the Java Language Conversion stuff. Very interesting. .NET and the Java platform are pretty similar, C# and the Java language are pretty similar (even though I believe that C# is more flexible, and hence my favorite), .NET Remoting is similar to RMI, etc. etc. etc. I wonder why nobody's developing a language to front end both platforms. You could write your stuff in this language, hopefully incorporating the best features of .NET and Java, and then just compile to MSIL or Java bytecodes! I know it's not something you could knock off in an afternoon, but it wouldn't be all that hard for the right people to do. Anybody writing in the new language would be free from vendor lock-in worries. If a new target platform similar to Java or .NET popped up, you could just write a new preprocessor to emit intermediate language for the new one and voila! your old applications would be available. You'd have a front-end platform and a target platform. The implementers of the front-end platform would actually have somewhat of an easy job, because they wouldn't have to write the system logic to support all the functionality, just the logic to get everything into the intermediate form of the target platform. Regards, Jeff Varszegi

[Paul Watson]

I am confused. Are you suggesting a language or another layer? regards, Paul Watson Bluegrass South Africa Anna-Jayne Metcalfe wrote: "Cynicism has it's place in life - but it should be kept well away from your inner self." Crikey! ain't life grand?

[Jeff Varszegi]

It seems that the word 'layer' means lots of things to lots of people, and its potential for meaning has been reduced even further of late by Microsoft marketspeak, similar to what they've done to the word 'stack'. If by 'layer' you mean 'layer of abstraction', uh huh. I don't know what you would call it but a front-end platform. The rights to Java are owned by Sun, and the rights to C#/VB.NET etc. are owned by Microsoft, right? So the language would have to be new. But as we know from C#, it wouldn't have to be that different from existing languages. You could even use an existing non-proprietary language, as long as it had clean support for OO features. It would have to compile to both .NET and Java platforms, which means that there would have to be a decent effort made at abstracting the common APIs of each. That would be good, though-- both the BCL and the Java core API have usability problems, although they're not severe in either. So anyway, there'd have to be a language and an API. You could write your application in this language, and compile it today for Java. Then tomorrow you could decide to deploy the same application on .NET, recompile it, and away you'd go. You could write commercial software and easily provide versions for all platforms supported by .NET and the Java platform. Regards, Jeff Varszegi

[Daniel Turini]

Jeff Varszegi wrote: I wonder why nobody's developing a language to front end both platforms. You need to search more before saying such things. Not to mention VS.NET 2003 already includes such a tool, "Visual J# Binary Converter Tool (for Java-Language Bytecode to MSIL Conversions)". Search MSDN for JbImp (or your "c:\Program Files\Visual Studio.NET 2003\" :) ) Jeff Varszegi wrote: If a new target platform similar to Java or .NET popped up, you could just write a new preprocessor to emit intermediate language for the new one and voila! It's not this simple. It's not only bytecode: you need the whole framework support, too. More info on the Mono Project or DOTGNU. Not to mention that whole Web Services thingie that nobody seems to remember why they started doing it :) Trying to make bits uncopyable is like trying to make water not wet. -- Bruce Schneier By the way, dog_spawn isn't a nickname - it is my name with an underscore instead of a space. -- dog_spawn

[Gumaro]

It sounds like a good idea but in practice it seems that will be a hell to make all the different versions of Java to integrate what you are suggesting, when I learned Java it was so cool!!!... Then I realized that I should be very careful on selecting the right version of the libraries and classes even the environment if I wanted to make it run on all the operating systems and Java versions. Personally I wouldn't like to write code (in a new language or for a new layer) that keeps me busy verifying/thinking that the code will run as it should.... I hope god forbids that the code I create in.NET is integrated some how with Java. Let’s keep it simple Java or .NET doesn’t mix. :cool: Omar

[Jeff Varszegi]

Daniel Turini wrote: It's not only bytecode: you need the whole framework support, too. I know. That's what I said in my reply to Paul Watson-- that the common API of each platform would have to be represented by a new API. It would serve as the intersection of functionality available via the BCL and the core and extended Java APIs, no more-- but they have a great deal in common. This is not the same thing as is provided by the J# converter etc. I don't think that it's possible to write a program that does normal simple things like access databases, send email, etc. and just deploy on both Java and .NET, no matter what the docs on the J# conversion tool (formerly known as the Java Language Conversion Assistant, I think) would have you believe. I've heard about lots of problems people've had moving code from the Java platform to .NET, and it's to be expected; it's not in Microsoft's best interest to make it work perfectly. The second you posted is a 'bridge' that mainly serves to ease generation proxy classes for a different target platform. I've already read the third article, and it's also not what I'm proposing; it is certainly cool, but it's about making components on different platforms work with each other. The fourth link is another exercise in providing proxy classes. The first link I hadn't seen, and it is closest to what I'm talking about, although still not the same thing (or as powerful). The guy's aim is to enable you to write programs in Java and deploy them on .NET, basically to provide a fully-functional JLCA. What I'm talking about is a little better. Do you remember the first human-language translation APIs that were implemented for wide use? IBM's translation engines were pretty representative at the time, and I will speak of them because I know them best. Each language pair (and sometimes direction) needed a different plugin; installing the Russian-English language pair enabled translation back and forth, but then installing French-English did NOT provide ability to translate between Russian and French. Modern translation engines don't work that way. They all translate human language into an intermediate format and then transform it to an appropriate target language. This means that you can get the benefit of translation to and from all previously suported languages when you implement a plugin for a new one. Web services is not what I'm talking about, either. I just think it would be nice to write a component in a language and be ab

[Daniel Turini]

Jeff Varszegi wrote: This is not the same thing as is provided by the J# converter etc. I don't think that it's possible to write a program that does normal simple things like access databases, send email, etc. and just deploy on both Java and .NET, no matter what the docs on the J# conversion tool (formerly known as the Java Language Conversion Assistant, I think) would have you believe. It is possible, indeed. IKVM even runs Eclipse! Jeff Varszegi wrote: e first link I hadn't seen, and it is closest to what I'm talking about, although still not the same thing (or as powerful). The guy's aim is to enable you to write programs in Java and deploy them on .NET, basically to provide a fully-functional JLCA. What I'm talking about is a little better. Why is is better than IKVM (a full-blown JVM written in .NET)? Jeff Varszegi wrote: I know. That's what I said in my reply to Paul Watson-- that the common API of each platform would have to be represented by a new API. It would serve as the intersection of functionality available via the BCL and the core and extended Java APIs, no more-- but they have a great deal in common. I see: the lowest common denominator of the lowest common denominator. What I'm asking is: why is a "translation" or another layer between frameworks better than: A: A JVM written in .NET B: A CLR written in Java Since both exist? Trying to make bits uncopyable is like trying to make water not wet. -- Bruce Schneier By the way, dog_spawn isn't a nickname - it is my name with an underscore instead of a space. -- dog_spawn

[Daniel Turini]

Jeff Varszegi wrote: and the rights to C#/VB.NET etc. are owned by Microsoft, right? No, at least C# and the CLR are open ECMA standards. Trying to make bits uncopyable is like trying to make water not wet. -- Bruce Schneier By the way, dog_spawn isn't a nickname - it is my name with an underscore instead of a space. -- dog_spawn

[Jeff Varszegi]

Daniel Turini wrote: What I'm asking is: why is a "translation" or another layer between frameworks better than: A: A JVM written in .NET B: A CLR written in Java Since both exist? Well, for one thing it would be integrated. It would allow for future expansion, instead of person A working on a project to translate some code from Java to .NET and person B doing the opposite. Those projects have nothing in common. It would also allow for expansion-- all you'd have to do is write a module to transform from the intermediate form to something that would run on another platform and you'd get things working for both .NET and Java at once. I'm not talking about emulating a .NET environment in a JVM and vice versa; maybe I'm misunderstanding what you're saying. I doubt seriously that (as I hinted at before) I can write a Java application using JDBC and just use the IKVM to run it using the CLR. But maybe I'm wrong! That's always possible! To sum up: just because .NET is an "ECMA standard" doesn't mean that it's out of Microsoft's greedy clutches. Mono won't make it into the data center for quite some time (although I applaud Mono and all who work on it) due to the reluctance of IS managers to go with non-Microsoft tech. The reason most of them will go with .NET in the first place is the Microsoft brand. Microsoft will most likely keep introducing new features that will make it harder and harder for people to use Mono; much of this will occur due to programmers thinking that proprietary MS extensions are part of the MS .NET implementation that conforms to the open spec. Java is also not out of Sun's greedy clutches. Check out some people's troubles with the JCP to see what I mean. They've threatened to start charging for Java, too (seeing as every attempt of theirs to make a successful app server has flopped!). I didn't know that the rights to C# aren't owned by Microsoft. Thanks for the info. I do a lot of reading, but it's not obvious where to find some of this information (at least to me). I've knocked around Microsoft's site a fair bit, done lots of programming-oriented book reading, and the rest of the time I've hung out at sites like this, where knowledgeable people like yourself enlighten me. I think that there have been lots of realizations in the last ten years as to what's needed in a comprehensive object-oriented platform, and the net output of this knowledge thus far is the Java platform and .NET . Mono is the first completely open-source attempt

[leppie]

EMits either MSIL or Jababytecode. Has compilers for C#, vb, Java, bf, and C. It does need alot of work still but its coming along really nicely :) www.dotgnu.org[^] leppie::AllocCPArticle("Zee blog");
Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.

[Jeff Varszegi]

It looks like a patent application's been made on the .NET API, though. Dunno how that affects Mono. It will be interesting to see how things play out. At the very least, Ximian is to be applauded for even attempting to sever the link between Windows and the .NET platform. Thanks again for taking the time to give me so much useful info. Jeff Varszegi [edit] Sorry, I pasted the wrong link in the first time. [/edit]

[Jeff Varszegi]

Dude, this is great! But I'm still a little bit in the dark... the current coding competition on their site is to implement the System.Windows.Forms API. But doesn't that fall under the Microsoft patent of the .NET APIs? I mean, is DotGNU trying to create a separate platform, or just free up .NET a little, and support output of compiled code that will run in a .NET runtime engine? These IP issues always stump me. If DotGNU is guaranteed to be free for all time, I am all for it. Your curious pal, Jeff Varszegi

[leppie]

It probably best to check out their mailing lists, or chat on irc. leppie::AllocCPArticle("Zee blog");
Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.

[Jeff Varszegi]

I searched on "dotgnu patent infringement" and came up with some interesting stuff. I think that this thread has some interesting reading. If you read two past the first post, the guy makes some interesting points, including that DotGNU should probably move to different APIs to avoid patent infringement. It looks like the main thing right now keeping DotGNU free is that it's developed in Australia and India, outside the reach of U.S. patent laws. But the fact that they're choosing to implement a patented MS API means that any U.S.-based DotGNU contributor or user should probably keep thangs on the down-low, until the air clears a little more. Regards, Jeff Varszegi

[Jeff Varszegi]

I searched on "dotgnu patent infringement" and came up with some interesting stuff. I think that this thread has some interesting reading. If you read two past the first post, the guy makes some interesting points, including that DotGNU should probably move to different APIs to avoid patent infringement. It looks like the main thing right now keeping DotGNU free is that it's developed in Australia and India, outside the reach of U.S. patent laws. But the fact that they're choosing to implement a patented MS API means that any U.S.-based DotGNU contributor or user should probably keep thangs on the down-low, until the air clears a little more. Regards, Jeff Varszegi [edit] Here's another interesting one. Cheers [/edit]

[Daniel Turini]

Jeff Varszegi wrote: I doubt seriously that (as I hinted at before) I can write a Java application using JDBC and just use the IKVM to run it using the CLR. But maybe I'm wrong! That's always possible! I never saw it (as I also think JDBC sucks, so I don't have much interest), but I think it should be possible, because IKVM uses GNU CLASSPATH, and there's JDBC 3.0 support for GNU CLASSPATH already. If you don't know it already, GNU CLASSPATH is a rather complete GPLed Java base library (currently, JDK 1.4), with the purporse of easing the implementation of Java everywhere. What IKVM needs to do now is "only" the bytecode ---> MSIL part. It's done at runtime, but it's not interpreted: it uses System.Emit, so you can think of it being "doubly JITTed", as the first step is MSIL generation, and the second step is taken by the CLR, which JITs the code. And, with IKVM, you can actually create a class in Java and override some of its methods in VB.NET. IMHO, this is not a good design, but it's possible. There are some fundamental differences between the two platforms (IKVM blog is great for this!), like checked exceptions, and this would be very hard to workaround. Jeff Varszegi wrote: To sum up: just because .NET is an "ECMA standard" doesn't mean that it's out of Microsoft's greedy clutches. Mono won't make it into the data center for quite some time (although I applaud Mono and all who work on it) due to the reluctance of IS managers to go with non-Microsoft tech. Oh, I think it will. Mono will open a series of enterprise-class .NET applications (like the one I work on) for Linux, OS390, Solaris and FreeBSD. IMO, there's not much sense in running Mono on Windows, unless you are a Mono developer. Jeff Varszegi wrote: In the past, people wrote mainframe applications that used CICS and suchlike things for integration, right? Well, then the next thing came along, and C/C++ apps had to communicate with mainframes. And then Java came along, and there were lots of companies that made money building bridging applications to let Java call mainframes etc. Aaah, good old APPC (LUA 6.2) and the 32Kbyte limit on COMMAREA... Trying to make bits uncopyable is like trying to make water not wet. -- Bruce Schneier By the way, dog_spawn isn't a nickname - it is my name with an underscore instead of a space. -- dog_spawn