Charles Ditzel has pointed out the NET2Java NetBeans plugin, which purports to convert C# and VB code to Java. It's not finished, but the project is still early in development and, given that it's an open project, we could have a fully working analogue to Microsoft's Java-to-.NET converter sometime in the future.

Mr. Ditzel is one of the more vocal Netbeans supporters out there, but it's hard to deny that Netbeans is gathering a very active plugin ecosphere. With JSR-198 (A Standard Extension API for Integrated Development Environments) being finalized, who knows? Perhaps plugins like this might be broadly portable across editors and Java would have a broadly available converter for whatever .NET apis we found useful. Any candidates? :)

I can understand the desire to translate C# to Java, but would people really want to translate VB to Java. I would think having a skilled developer port it over makes more sense. There are all sorts of things one might do in VB that would be terrible in Java, so can a translation program beautify bad code?

peter

Is this VB 6 or VB.NET? I'm assuming VB.NET since it is much more C#/Java like.

VB 6 is an entirely different animal.

I'm guessing that it is just purely code that gets converted. I'd be really impressed if an entire VB app got converted correctly to Java/Swing.

Is this VB 6 or VB.NET? I'm assuming VB.NET since it is much more C#/Java like.VB 6 is an entirely different animal. I'm guessing that it is just purely code that gets converted. I'd be really impressed if an entire VB app got converted correctly to Java/Swing.

There is a product which claims to do this for pre-.NET versions of VB: http://www.diamondedge.com/products/Convert-VB-to-Java.html

Is this VB 6 or VB.NET? I'm assuming VB.NET since it is much more C#/Java like.VB 6 is an entirely different animal. I'm guessing that it is just purely code that gets converted. I'd be really impressed if an entire VB app got converted correctly to Java/Swing.

There is a product which claims to do this for pre-.NET versions of VB: http://www.diamondedge.com/products/Convert-VB-to-Java.html

I've used it. Not too bad, but the resulting code suffers from the same issues as writing a Java app from scratch like one would in VB.

The problem really is VB (not the conversion tool) and the things it allows you to do. Like late binding, default properties, DAO/RDO/ADO, With statements, using Form instead of new Form. And if you've done usercontrols... .

Try converting VB6 app to VB.Net. Many of the same issues. A dll project is not too bad, but if a project has forms, it doesn't work so well.

Not too bad, but the resulting code suffers from the same issues as writing a Java app from scratch like one would in VB. The problem really is VB (not the conversion tool) and the things it allows you to do. Like late binding, default properties, DAO/RDO/ADO, With statements, using Form instead of new Form. And if you've done usercontrols... . Try converting VB6 app to VB.Net. Many of the same issues. A dll project is not too bad, but if a project has forms, it doesn't work so well.

I think it is even worse than if you simply coded a Java app like VB, because of the number of weird hacks needed to get around what VB (pre .Net) allows you to do. However, in terms of porting, it is at least a start.

Is this VB 6 or VB.NET? I'm assuming VB.NET since it is much more C#/Java like.VB 6 is an entirely different animal. I'm guessing that it is just purely code that gets converted. I'd be really impressed if an entire VB app got converted correctly to Java/Swing.

I would believe it is VB.Net since it is called "NET2Java".

I've written a source to source VB.Net converter to Java that might be of interest to folks who are interested in this topic. VBeeJ For Java has an advanced type inference mechanism that creates interfaces and stubs for any unknown types and methods. Your converted Java code compiles, including all calls into the .Net platform that are unknown on the Java platform. VBeeJ For Java also has a plugin architecture to support .Net API's running on top of Java. So, for example, the free trial download demo generates the plugin for the .Net XML API. You can actually use the .Net XML API in Java, in any Java context, using this plugin. link: http://www.beelucid.com/products/vbj

Yay, so now it is easier to convert unlayered, tightly coupled and mostly procedural VB code into unlayered, tightly coupled and mostly procedural Java code. I'll get right on that...

But it does buy you some sort of platform independance so that you can get your VB & C# code off the microsoft platform...

It is still up to you to make that code nicer - but you can take your time doing that...

Woudln't it be more useful to create a compiler that can take C# and produce bytecode out of it so that it can just run on the VM directly?

Your clever, just like the guy who created IKVM. I only wonder how hard it would be to do this.

Mainsoft's Grasshopper product provides that for specific areas (ASP.NET -> J2EE).

In general, it's hard to do since CIL is (roughly) a superset of the JVML, allowing for things like "unsafe" code accessing memory through pointer references, etc. which do not map nicely at all to what one can do with JVML.

cheers,
dalibor topic

Mainsoft's Grasshopper product provides that for specific areas (ASP.NET -> J2EE).

In general, it's hard to do since CIL is (roughly) a superset of the JVML, allowing for things like "unsafe" code accessing memory through pointer references, etc. which do not map nicely at all to what one can do with JVML.

cheers,dalibor topic

I haven't kept up with the latest changes in .NET 2.0, but assuming one doesn't use things like delegates or unsafe code, most of it should map fairly well for .NET 1.0. With .NET 2.0, it's probably better to manually port the code. I've ported stuff from Java to .NET 1.0 and 1.1 in the past and it is straight forward easy.

peter

Isn't that great! Microsoft has got the Java converter since many many programmer years ago. The Java Jedi strikes back! :)

This can only be a good thing.

I've been 'forced' to migrate from Java to C# where I work.

After working with C# for a while now, I can honestly say that Java is a better language.

C# is full of useless 'features' that only encourage bad coding.

Operater overloading
Exclusively Unchecked Exceptions
Completly disorganized source file structure
Region tags that only encourage messy code
Pointers
etc.

To me Java is better because it *doesn't* have 'features' like those.

I applaud the developers of this converter and long for the day when NetBeans will come standard with a C# to Java converter the same way that Visual Studio comes with a converter.

Sun needs to get organized behind this.

This will give amunition to those of us who are trying to go back to Java.

This can only be a good thing.I've been 'forced' to migrate from Java to C# where I work.After working with C# for a while now, I can honestly say that Java is a better language.C# is full of useless 'features' that only encourage bad coding.Operater overloadingExclusively Unchecked ExceptionsCompletly disorganized source file structureRegion tags that only encourage messy codePointersetc.To me Java is better because it *doesn't* have 'features' like those.I applaud the developers of this converter and long for the day when NetBeans will come standard with a C# to Java converter the same way that Visual Studio comes with a converter.Sun needs to get organized behind this.This will give amunition to those of us who are trying to go back to Java.

Then I think a java to C# converter would be more usefull, you can always write java and have simple and solid code. I would be very happy with a java to c# converter on the source level, we can all port our frameworks seay to .NET. Oofcourse SUN and other JAVA dependend companies would not be to happy about that.

Another thing is that I agree with you and even want to take it a little further. I was sick of JAVA and everything around it for a while and thought that .NET would bring relieve, oh boy was i punished when the moment was there when i had to do some proffesional .NET. The .NET tools suck and they are not any faster also. Eclipse is so much more developer driven, smarter and intiutive. I think that applies for netbeans and intelliJ too (didn't do that much with it so i dont really know). I think it is like marriage, after 7 years you'v seen it and start to look at others but when you try some you discover that it is not that bad what you had. And you know what she actually worked on herself and became even more attractive then she was before, I fell in love again with her. The next next release she promised me to have full hot code swap, fields, methods the works. When that moment arrives i am sure that i will never leave her anymore. Because then she will be the only one with a compiler that has all the advantages of a dynamic language.

C# is full of useless 'features' that only encourage bad coding.

It looks like Sun's dumbing down effort was perfect for you.

C# is full of useless 'features' that only encourage bad coding.

It looks like Sun's dumbing down effort was perfect for you.

Java was designed with a considerable amount of experience of what can go badly wrong in terms of language previous design, and avoiding those issues. That features like operator overloading can sometimes encourage bad coding is well-known, and nothing to do with Java being 'dumbed down'. Java, for better or worse, was designed to be a practical language for real robust development. I see a real issue with proposed additions to C# and VB.NET in that they could end up with everything any developer could ever want, but as a result could easily lead (like earlier VB versions) to unmaintable code.

Java was designed with a considerable amount of experience of what can go badly wrong in terms of language previous design, and avoiding those issues. That features like operator overloading can sometimes encourage bad coding is well-known, and nothing to do with Java being 'dumbed down'. Java, for better or worse, was designed to be a practical language for real robust development. I see a real issue with proposed additions to C# and VB.NET in that they could end up with everything any developer could ever want, but as a result could easily lead (like earlier VB versions) to unmaintable code.

Yes, because we know that there is no maintainable code written in C++, C#, Ruby, or any other language with operator overloading. Java can be just as unmaintainable as any other language - depending on who is writing the code. But if you enjoy the dumbing down, then all the power to you.

Yes, because we know that there is no maintainable code written in C++, C#, Ruby, or any other language with operator overloading.

Which is, of course, not what I said.

Java can be just as unmaintainable as any other language - depending on who is writing the code.

No. The point of removing features that can easily allow unmaintainable code to be produced means simply that less unmaintainable code is produced, and it depends less on who is writing the code. To put it bluntly, poor programmers can do less damage with Java, and clever hackers can produce less obscure code.

Having frequently seen the effects of both over a long career as a developer, I am content with most of the choices made in the design of Java.

Which is, of course, not what I said.

What you said was...

<blokquote> I see a real issue with proposed additions to C# and VB.NET in that they could end up with everything any developer could ever want, but as a result could easily lead (like earlier VB versions) to unmaintable code.
Languages don't produce unmaintainable code, programmers do.

No. The point of removing features that can easily allow unmaintainable code to be produced means simply that less unmaintainable code is produced, and it depends less on who is writing the code. To put it bluntly, poor programmers can do less damage with Java, and clever hackers can produce less obscure code.

Once again, you're blaming the language and not the brain dead programmers that produce unmaintainable code. Wouldn't you rather have the option of operator overloading and decide on a company-wide, or per-project policy basis? Or maybe
we should have int a = 1; int b = 2; c = a.add(b); That would be consistent. But instead we have that "nice" syntax for things like BigInteger and StringBuilder.

The other poster pointed out "unsafe" code. In C#, using native code is completely trivial. It basically comes down to writing a declarations for the native code functions you want to use. Of course, you need to use "unsafe" code. Now Sun thinks that nothing lies out the Java universe so you wind up with crap like JNI.

Having frequently seen the effects of both over a long career as a developer, I am content with most of the choices made in the design of Java.

So you expect Sun to protect bad developers from themselves?

Which is, of course, not what I said.

What you said was...<blokquote> I see a real issue with proposed additions to C# and VB.NET in that they could end up with everything any developer could ever want, but as a result could easily lead (like earlier VB versions) to unmaintable code.

Languages don't produce unmaintainable code, programmers do.
Indeed programmers do. Which is why it is a really great idea to have languages that help prevent that.

No. The point of removing features that can easily allow unmaintainable code to be produced means simply that less unmaintainable code is produced, and it depends less on who is writing the code. To put it bluntly, poor programmers can do less damage with Java, and clever hackers can produce less obscure code.

Once again, you're blaming the language and not the brain dead programmers that produce unmaintainable code.

Yes, because aren't we all 'brain dead' occasionally? Well, freely I admit I am. I make mistakes in coding - often embarassing ones. I need a language to protect me from my mistakes, but maybe that is just me.

Wouldn't you rather have the option of operator overloading and decide on a company-wide, or per-project policy basis?

But you can. You can use a language other than Java (I very occasionally use JRuby or Groovy in such situations). What Java protects you from is developers choosing to use such features whenever they feel like it.

But instead we have that "nice" syntax for things like BigInteger and StringBuilder.

Ah, well that is one of aspects of Java design I dislike. I think it would make sense to have operators for java.math.* classes, for example. Not having this makes coding financial logic with BigDecimal a mess. But, that is not the same as the ability to apply operator overloading anywhere - I want the use of math operators in the language extended, not operator overloading.

The other poster pointed out "unsafe" code. In C#, using native code is completely trivial. It basically comes down to writing a declarations for the native code functions you want to use. Of course, you need to use "unsafe" code. Now Sun thinks that nothing lies out the Java universe so you wind up with crap like JNI.

Sorry, but I disagree. I really don't think that using native code should be trivial in a language designed for safety and easily portability. If you want portability, you want to only rarely wander outside the Java universe.

Having frequently seen the effects of both over a long career as a developer, I am content with most of the choices made in the design of Java.

So you expect Sun to protect bad developers from themselves?

I don't expect it, but I'm very glad they do.

Languages don't produce unmaintainable code, programmers do.
Indeed programmers do. Which is why it is a really great idea to have languages that help prevent that.

Except a language won't help prevent that.

Yes, because aren't we all 'brain dead' occasionally? Well, freely I admit I am. I make mistakes in coding - often embarassing ones. I need a language to protect me from my mistakes, but maybe that is just me.

I'll buy that for something like manual memory management, but not in the case of operator overloading where a simple code review should immediately reveal a misuse. Years ago, a co-worker of mine told me about this gal that used to name her variables after her pets. It should be one of those "Houston, we have a problem" and time for a little talk moments.

But you can. You can use a language other than Java (I very occasionally use JRuby or Groovy in such situations). What Java protects you from is developers choosing to use such features whenever they feel like it.

Now I'm real confused, if it's not OK for Java, then why is it OK for Groovy or JRuby or...? But even Java will allow programmers to string together syntax that compiles and does what it's supposed to do, but looks like an entry in a obfuscation contest.

Ah, well that is one of aspects of Java design I dislike. I think it would make sense to have operators for java.math.* classes, for example. Not having this makes coding financial logic with BigDecimal a mess. But, that is not the same as the ability to apply operator overloading anywhere - I want the use of math operators in the language extended, not operator overloading.

And so java.math.* classes now get special status like String and the numeric primitives? How is that supposed to work?

Sorry, but I disagree. I really don't think that using native code should be trivial in a language designed for safety and easily portability. If you want portability, you want to only rarely wander outside the Java universe.

I never understood that mentality that Sun has pushed so hard. I live in the real world where I want to reuse code and not in some sandbox where I'm actively discouraged from leaving.

Except a language won't help prevent that.

Sure it will. By not having features that have been well established as assisting unmaintainable code to be written.

Yes, because aren't we all 'brain dead' occasionally? Well, freely I admit I am. I make mistakes in coding - often embarassing ones. I need a language to protect me from my mistakes, but maybe that is just me.

I'll buy that for something like manual memory management, but not in the case of operator overloading where a simple code review should immediately reveal a misuse.

That is not the point. The point is avoid misuse, not to have to look out for it. Ths point is that the meaning of Java code should be clear without having to look up what someone has decided '+' means.

<blockqiote>

But you can. You can use a language other than Java (I very occasionally use JRuby or Groovy in such situations). What Java protects you from is developers choosing to use such features whenever they feel like it.

Now I'm real confused, if it's not OK for Java, then why is it OK for Groovy or JRuby or...?
I don't understand why this is confusing. Sometimes you want to play about with a language that isn't safe. But a general purpose language like Java should be as safe as possible.

But even Java will allow programmers to string together syntax that compiles and does what it's supposed to do, but looks like an entry in a obfuscation contest.

Ah, well that is one of aspects of Java design I dislike. I think it would make sense to have operators for java.math.* classes, for example. Not having this makes coding financial logic with BigDecimal a mess. But, that is not the same as the ability to apply operator overloading anywhere - I want the use of math operators in the language extended, not operator overloading.

And so java.math.* classes now get special status like String and the numeric primitives? How is that supposed to work?

It isn't special status. Math operators should work as expected between math objects. If anything has special status it is String, but I guess people were used to the use of '+' for concatenation in languages like Pascal.

I never understood that mentality that Sun has pushed so hard.

So it seems :)

I live in the real world where I want to reuse code and not in some sandbox where I'm actively discouraged from leaving.
And because I develop in the real world and want to re-use code, I have the opposite view.

Sure it will. By not having features that have been well established as assisting unmaintainable code to be written.

Sun got to make that decision for Java, but Sun or you don't get the final word on "well established". In fact, I think most programmers would disagree.

That is not the point. The point is avoid misuse, not to have to look out for it. Ths point is that the meaning of Java code should be clear without having to look up what someone has decided '+' means.

Once again, you're missing the point. An operator is just a function (or method). Now it either makes sense or not. Java is not going to save someone from giving a method a goofball name that doesn't reflect it's intention. Besides, most programmers aren't blindly using methods when first encountered even if it seems to be obvious what it does. There is usually some context which necessitates docs.

But a general purpose language like Java should be as safe as possible.

We were talking about operator overloading in this context. So by your logic, C#, Ruby, and other languages that have operator overloading are not "safe"....Because they are general purpose languages.

It isn't special status. Math operators should work as expected between math objects. If anything has special status it is String, but I guess people were used to the use of '+' for concatenation in languages like Pascal.

The builtin numerics and string do have special status in the language. So how do you propose that BigInteger, Decimal, Vectors, Matrices (the rest of the math/engineering classes) or whatever get operator overloading, but it's not available for general developers?

And because I develop in the real world and want to re-use code, I have the opposite view.

Except you live in the Java sandbox, where only Java is re-used.

Sure it will. By not having features that have been well established as assisting unmaintainable code to be written.

Sun got to make that decision for Java, but Sun or you don't get the final word on "well established". In fact, I think most programmers would disagree.

No, it is indeed well established that operator overloading can potentially lead to confusing code. What is up for debate is how much that matters. I think it does.

That is not the point. The point is avoid misuse, not to have to look out for it. Ths point is that the meaning of Java code should be clear without having to look up what someone has decided '+' means.

Once again, you're missing the point. An operator is just a function (or method). Now it either makes sense or not. Java is not going to save someone from giving a method a goofball name that doesn't reflect it's intention.

Just because people can give goofball names to methods is no excuse to extending that to operators.

We were talking about operator overloading in this context. So by your logic, C#, Ruby, and other languages that have operator overloading are not "safe"....Because they are general purpose languages.

Not as safe, in terms helping to encourage the production of clear code, no. You seem to keep pushing me to an extreme point of view. This is a matter of degree, not absolute safety or otherwise.

It isn't special status. Math operators should work as expected between math objects. If anything has special status it is String, but I guess people were used to the use of '+' for concatenation in languages like Pascal.

The builtin numerics and string do have special status in the language. So how do you propose that BigInteger, Decimal, Vectors, Matrices (the rest of the math/engineering classes) or whatever get operator overloading, but it's not available for general developers?

It would not be operator overloading. It would be a language extension. I would give them special status as well.

And because I develop in the real world and want to re-use code, I have the opposite view.

Except you live in the Java sandbox, where only Java is re-used.

No, I use bash, python, ruby, SQL, and even occasionally C and C++ as well (and Smalltalk about once a year!). I find Java is easily the best for code reuse.

C# is full of useless 'features' that only encourage bad coding.

It looks like Sun's dumbing down effort was perfect for you.

You having a bad day Frank?

You having a bad day Frank?

It was a great day. I didn't have to write any Java code.

I think it's feasible to do convertion on C#/VB to Java, or other similar convertions.

And there are aslo a Java to JavaScript convertion:
http://j2s.sourceforge.net/

Things depend on how depth is your convertion. Reusing those libraries of C#/VB into Java may require long and deep converting, I think.

This popped up the other day. http://www.alphaworks.ibm.com/tech/compass?open&S_TACT=105AGX59&S_CMP=GR&ca=dgr-jw01awnestedarchive

As mentioned by a previous comment, why not just use a common runtime for both Java and .net. A good example, used by the JBoss Rules project , is Apache IKVM allowing the Java Rules engine to run under .Net. Paul , FirstPartners.net

You can convert your C# program to java using this C#2java converter cloud application. Its free , very easy to use and you dont have to install or download it, just submit your C# code and it will be converted to java instantly.

Try using Codeporting's online .Net to java converter . It is a web-based application that converts your .net app,projects and files to java in the cloud which means you don't have to download it just upload your .Net code and it will be converted to java instantly.