Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I just got myself an android phone and I'm dying to start coding on it !
However I'm not a big java fan, although I can live with that, I would like to know if there're reasonable alternatives for the android virtual machine.
I've done a medium sized project using clojure, however from the reviews I read, it's very slow when running on android. How about scala ? I read that some people did experiments with it in android, is it "fast enough" ? How big is the learning curve ?
Cheers,
Ze Maria
There's the NDK which allows you to write parts of your program in C or C++.
There's ASE that allows you to write scripts in python and maybe other languages. There's no python compiler despite you might hear otherwise.
I have read something about scala but since I wasn't really interested I did not pay attention.
There's definitely quite a few people doing Android development in Scala. Of particular notice, there's even a plugin for SBT, the prefered builder for Scala projects, with Android-specific targets.
As for learning curve, I can't speak for Android development itself, as I haven't done that. As for Scala, you can be productive very quick, but learning all the particularities of the language takes time. You don't need to learn all the particularities -- I have seen people write non-toy programs with barely any experience -- but some people can't stand not knowing something about the language they are using.
Also, a lot of Scala code out there is very declarative. If you look at the SBT build files, for example, they are mostly declarative. Some people get very upset by that, for some reason.
I'm guessing what I'm trying to say is that it depends mostly on you how well you'll take to Scala.
As for speed, Scala code can be as fast as Java code, though that may call for avoiding the more high level abstractions in exchange for uglier, but fast, code. It depends a lot of what kind of computation you are doing, though.
Android 2.2 adds jit to the VM which is supposed to make loading Clojure programs much more efficient. Clojure produces a lot of small classes which take a while to load when the android program starts up. this should be alleviated with the enw android though its not intolerable now.
Just noticed that some Scala examples can be found in trunk: http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/docs/android-examples.
I haven't tried myself but it's encouraging.
There's a port of JRuby to Android, as well, which I've played with and seems interesting. http://ruboto.org/
"fast enough" - you are running applications on a mobile phone that question relative to what you expect it to do.
Also java's performance has been increased through the years. But also run you are just coding in java. Google has created a tool that take java byte code and converts it to .dex (Dalvik Executables). Dalvik the VM implementation that java used is optimized for this platform. Which mean you can program in a high level language like java which provides many helper classes which means you will be more productive.
They do have a NDK but I believe you have to still have a java front end and have your java code call the NDK code when necessary. You pretty much only want to write the native code when you really need to optimization. Alot of java classes like java nio and the opengl classes are just wrappers to low lever calls that use hardware resources directly.
I probably over answered you question a little.
There is also Lua, which you can use with the Corona SDK.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Updated(for clarity and to reduce ambiguity):
I'm going to start tinkering around with android apps. I was planning on writing the in C++ using the NDK (since I have more experience in C++ and prefer it to Java) but came across the following on the Android NDK page:
you should only use the NDK if it is essential to your
app—never because you simply prefer to program in C/C++.
I was under the impression that you should use the language that you prefer, as long as it fits the job. Could somebody explain why it is so heavily advised not to use C/C++ for android development?
Original:
I'm going to start tinkering around with mobile apps, specifically android which is the OS of my current phone, and I was wondering if writing the app in C++ (or at least the core, then wrapping in Java) was an acceptable option.
Some background, I'm a computer science major who has taken 3 C++ courses(intro, intermediate, OOP, and am taking an STL course in the spring) and only 1 Java course(intermediate). Because of this, I am more comfortable with C++ and prefer it to Java. I came across the following on the Android NDK page:
Using native code on Android generally does not result in a noticeable
performance improvement, but it always increases your app complexity.
In general, you should only use the NDK if it is essential to your
app—never because you simply prefer to program in C/C++.
I was under the impression that you should use the language the fits
the job as well as one you're familiar with
I may want to port the application to another mobile platform, such
as iOS, that supports C++ but not java
While Java is a high level language and thus should make development
faster, I feel like development would be slower because I would have
to relearn almost everything (since I have only taken one class on
the language)
Any advice would be much appreciate.
ps: many of the answers on this subject are from years ago and there are very few follow up answers that mention the NDK allowing the development of full native apps on android 2.3 and newer.
Think of it this way. You have the ability using the Java SDK to build a full working application that takes advantage of 100% of the APIs available to developers. There is nothing you can do with the NDK that cannot be done with the SDK (from an API perspective), the NDK just provides higher performance.
Now look at it in reverse. If you choose to write an application 100% in the NDK, you can still write a fully functional application, but you are limited in the number of framework APIs you can access. Not all of the Android framework can be accessed at the native layer; most APIs are Java only. That's not to say that all the APIs YOU may need aren't available in the NDK, but nowhere near ALL the APIs are exposed.
Beyond this, the NDK introduces platform-specific code which expands the size of your distribution. For every device architecture you intend to support, your native code must be built into .so files (one for armv5, armv7 and x86) all packaged up into the same APK. This duplication of executable code makes your app 3x the size (i.e. a "fat binary") unless you take on the task of building separate APKs for each architecture when you distribute the application. So the deployment process becomes a bit more work if you don't want your APK to grow in size significantly.
Again, while none of this is prohibits you from doing what you choose, it points out why Google describes Java as the "preferred" method for the majority of your code and the path of least resistance. I hope it sheds some light on why the documentation is worded the way it is.
If you're only going to develop one app in your life, use the NDK.
If you're aiming at learning Android development with the intention of developing more than one application during your lifetime - and want to be able to properly support them all - you're very likely to do better in the long run if you learn Java and use Android's Java SDK instead.
The programmers at King use C++ for their game logic. And they seem to be doing fine judging by their turnover.
In my experience, C++ is for problem solvers and Java is for problem avoiders. I love either language, but C++ is quite rewarding when you write good code. However, it may just take several moments of wizardry to get there.
You could recommend C++ for Data scientists as well, who would normally get their job done by, say, Python or R. C++ can do the same with as good or not better performance, but it just takes being a genius in the language. That is why I'd never not recommend C++ to the one that wants to do it - I'd just give a heads up to the treat that they're in for.
I found this interesting article from:
http://betanews.com/2014/07/22/why-c-is-the-perfect-choice-for-modern-app-development/
C++ was built specifically for platform independence and as such is found on every single operating system in existence. Your typical mobile user may know that Android apps are written Java and iOS apps in Objective-C, but what many don’t know is that there is more C/C++ code in memory on your devices than anything else. C/C++ drives much of the technology of small devices (like the kernel, which interacts with the hardware, as well as typical run time libraries) and the telecommunications networks that enable these devices. More importantly for a development team, is that there are C/C++ interfaces and libraries for anything you need to do on any device and platform. The Android NDK toolset is a great example of full C/C++ support that was added originally for game development teams to enable them to get the best possible performance out of the device by avoiding Java and the Android Java runtime Dalvik, the virtual machine on which Android Java code is executed on. It has been regularly improved to enable every Android service.
I would say use java for main app. But if you have some c++ code you need to port or some library you need that is efficiently implemented in c++, then use ndk for those bits
I don't see any reason to not use C++ for normal android development , If you have extensive experience in working in C++ and with complex OS like windows or any other such, then you can grasp android quickly and is not as much complicated as the other OS are. while learning java or working without learning it would be more frustrating and complex !
The most important consideration is that the compiled Java code will run on all android devices unchanged, whereas the native code will need to be compiled for all target platforms.
The general intent for both Java and Android is that you write the majority if not all your app in Java and use native things only when there is no other option... so everything about writing the app will lend itself to doing so in Java.
You'll spare yourself a lot of aggravation in bridging between the native and Java worlds by writing in Java.
As well, you will do yourself a big favor if you take the plunge and learn Java. Not only will your Android app be the better for it, but you will expose yourself to a significantly different approach to OO and you will be a better programmer for it.
Add to that the fact that you will side-step a whole bunch of security risks by writing in Java.
In my mind, this is a no-brainer - use Java.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a history of hating Java, having used it pretty regularly in the late 90's during the 'slow as balls' era. As such, I never really learned it well. From what I understand, Java is actually a pretty good language to use these days. I've been thinking about diving into it because of Jython and Clojure. That is to say, I'd like to program in Java and use inline Jython or Clojure where appropriate. But truthfully, I'll probably just be programming in Jython/jRuby and calling up clojure from there.
Which brings me to my question. I know both of these languages can be called from Java, but is that necessarily good practice? Should I even bother learning java if I just want to use Jython as the primary language? Seeing as how that's a large part of my motivations here, I'd like to know that I'm not terribly misguided before jumping in. I'm aware there is a very high risk for projects to become a kludge if done in multiple languages like this.
I'm still learning about the JVM and the like, so I apologize if this question is painfully obvious.
Jython can be viewed as a cross compiler from Python to the Java Virtual Machine. As such, to get the most out of Jython you'll obviously have to learn Python, and probably will need to learn Java.
You can skip some of the Java learning, but at the end of the day, Java and the JVM grew up together. That means that Java code tends to lend understanding of the JVM. It is possible to gain understanding of the JVM without Java, but that's not a path well travelled. Any Jython code that imports a Java library will immediately have you searching Java documentation, so if you avoid leaning Java you're going to learn it piecemeal anyway.
You will have to decide if a piecemeal approach or a formal approach is more appropriate for you and your situation. A lot of deciding which path to take is knowing how you learn best.
As far as the "slow as balls" period of the 90's, that's when I was learning Java. Personally, I feel it is better to describe it as "slow as balls if you did incredibly stupid things with Java". Now I think people have built up a sufficient skill set to avoid translating C directly into Java. That said, I do occasionally encounter the 2000+ line method, so perhaps I'm being a bit rosy in my projection. The entire JVM is laid out in such a manner that good object oriented code runs faster, and if you're constantly trying to go to "other" objects for all the data you need locally, you'll just stack thrash the JVM.
Regardless of opinions, the JVM is now the hot Java item. There has been "other language" support by one means or the other for over a decade now; however, the excitement around Domain Specific Languages seems to have sparked an interest in compilation technologies and the JVM. The other languages benefit from the JVM being an easy target to hit with built-in cross platform support, excellent performance, huge availability of libraries, and generally good documentation. Learning Java and the JVM will help you with a lot of the JVM supported languages, as many of them don't flesh out their library space in favour of hooking into a pure Java library.
I'd say it's worth knowing Java even if you plan on only using other JVM languages. I use JRuby and Scala, and have played around with Clojure. If you are building things to run on the JVM, knowing Java is a bit like knowing C when working natively–you don't have to know C, but if you do, you can write the bits that need speed in C and wrap them in a Ruby or Python library or whatnot.
It's worth knowing the basic principles of how Java works in terms of things like interfaces and annotations and how the classpath works because otherwise you are working with basically a leaky abstraction. What happens when your interop isn't very good? This is especially true if you are planning to do Clojure and Jython!
The other reason to know Java is simply because if you are using code in the Java ecosystem, you have to be able to read and write Java. You need to write a library? Yes, you can probably write it in Clojure, but if you want other JVM language users to be able to use it, you should probably have written it in good, idiomatic Java. Scala is close enough to Java for this purpose; Clojure or Ruby or Python, not so much. Just being able to read and comprehend Java programs is very important too.
The other great benefit is simply that you get more libraries and they are better tested. You need a double-ended queue? Check the Java Collections Framework. Good random number generation? java.security.SecureRandom. UIs? Well, Swing, AWT and SWT are... okay, bad example. Knowing the benefits and shortcomings of these only comes from doing some Java programming and learning the various ways not to suck at Java.
From a couple of years experience of using Clojure (plus many more years of Java...) here is my perspective:
You don't strictly need any Java experience to write Clojure code - Clojure is a full language in its own right and you can write perfectly capable programs without using any Java.
You will need to set up the JVM environment - the Java environment has some rules about where code gets loaded from (i.e. the "classpath") that need to be followed to get a working environment. Not a big deal, and most IDEs will do it for you, but it can be a hurdle for people completely new to the JVM world. I'd suggest careful following of the setup instructions for whichever IDE/toolset you choose.
There are some Java-related concepts that are helpful to understand - for example, Clojure harnesses Java exception handling features with (try ... (catch ...)) etc. so it's useful to be somewhat familiar with the Java approach to exception handling.
Ultimately you will probably want to use Java APIs - bacause a huge amount of the value of being on the JVM in the first place is in having access to the huge diversity of libraries and tools that are available in the Java ecosystem. You don't need to write any Java code to use Java APIs from Clojure, but you do need to know enough Java (method signatures, data types etc.) to be able to read the JavaDoc documentation of the APIs and convert this into an appropriate Clojure function call. Often, this is as simple as (.someJavaMethod someJavaObject param1 param2) but sometimes it can be more complex (e.g. when you need to instantiate a subclass of some Java class to pass as a parameter)
Java isn't a bad language to learn anyway - while I'll readily admit Java has some weak points (as do all languages!), it's still a great, simple, high performance, cross-platform, object-oriented language that has a lot of value. Even if you only do a few short tutorials and never write anything substantial in Java, I'd still recommend it for the learning experience.
I believe most of the above would also apply to Jython.
I can't speak for Jython, but if you want to really get to grips with clojure, you want to understand its trade-offs compared to Java, especially wrt memory/gc and the basics of Clojure/Java interop. You also need at least an abstract understanding of how the clojure collections are implemented unless you really don't care about performance - that's not to say that clojure is particularly inefficient, but more the opposite: the implementation of its immutable collections is fairly unique and tailored to clojure's stance on persistence and performance and it helps to understand the underlying details when you're trying to improve on performance issues.
For all of that, I don't think you actually need a lot of Java knowledge. Being able to read Java fairly well, a basic understanding of the concepts, and a knowledge of where to find the documentation is probably enough.
I think if you want to do a hybrid Clojure/Jython project the interoperation details are most crucial. That probably means you have to know in some detail how classes, interfaces, some of the standard library and (to a minimal extend) generics work in Java and how to deal with all of those in your chosen languages since the interoperation necessarily reduces to the more basic Java constructs. Some of this is tricky and can be confusing, and in clojure's case at least the documentation often refers back to Java concepts and documentation for obvious reasons, so you have to make sure you read both, closely.
I would definitely learn java and learn it well, not only because Clojure is built on top of the JVM but also to get anything done you will be calling Java libraries all the time, and you may even need to dip into Java occassionally.
On another note it would be expand your mind to understand Java's OO concepts and pain poaints too and this will enhance your undersatnding of Clojure too.
Above all, study the Java libraries. Part of the joy of using the JVM is having access to "it's already been done" libraries, as well as to parts of the core language that accomplish certain tasks with optimum performance on the JVM. In addition, some languages (e.g. Clojure) purposefully dip directly into Java and don't completely discourage it in your own code, so if you want to be able to read others' code Java basics are a must.
As for the rest of "learning Java" (design patterns, concurrency in Java, etc.), I wouldn't waste your time unless/until specific projects requirements demand it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I noticed that this was asked in the following post. Has anyone used both and can conclusively tell me which is better? It seems like python might be a little easier to implement and faster?
By this time, both implementations are reasonably mature and solid, and their functionality is pretty similar (I don't think it's quite 100% equal yet, but, moving in that direction). So, if you already know only one of the two languages, I'd say "just go for it". If you already know both, you don't need my advice;-).
If you know neither, but are rarin' to try some of the non-Java languages that are (more or less;-) supported on the JVM side of GAE (I believe this includes Scala, server-side Javascript, JRuby, etc), then it's worth trying. If you know neither, and don't want to risk a "not-first-class-supported language", I'd definitely agree with your observation that Python's faster to learn (but of course I'm biased in favor of Python;-).
I have used both, and my conclusion is that biggest difference is in libraries. In theory both have good libraries to do almost everything but in practice many libraries don't work with app engine:
All Java libraries are pure Java and should work, but as app engine does not allow threads and not even all *java.** dependencies it is... lets say problematic.
Python on the other hand have way less libraries out there, and many are just wrappers for native C libraries, which don't work either. :(
As both versions have such bad support for libraries, I call it tie. For very simple "just to show some content" -web app you don't need any external libraries of course.
I use now Python because it rules. ;)
"Better" is always subjective. For GAE, the choice of which is better for you depends on what you're most familiar with. If you've got experience with Java, use that, and if you've got experience with Python, use that. I don't think there's any objective criteria that would point to one being "better" than the other.
Its not just the language that you need to consider here. Libraries, frameworks, and tools are also relevant factors.
If you have no background in either language or web development, I would suspect Python would be easier to get off the ground with. It has been around longer, there is likely more support and knowledge available. Doing something simple is generally simple to do and the Python framework is in my opinion more lightweight.
Despite this, I would rather use Java. However, my reasons are controversial and I don't want to troll :D.
Python was the language Google AppEngine was originally designed for, and it has been supported for longer than Java (which only got included comparatively recently). Additionally, Guido van Rossum, the creator of Python, works on the Python side of AppEngine. The same can not be said about Java's creator.
It seems that there is more documentation and articles about Python on AppEngine than Java, probably because Python has been used in AppEngine for longer.
My advise: Use Python.
But that doesn't mean Java is a bad choice, because it is not, I just think Python is a better choice in this instance.
Python ( subjectively speaking )
.py chosen here for all gae projects for reasons more readable, less lines code, higher level same time java has more ways to solve a given problem. Approx estimate same function with python is 1/10 the code compared to java.
i use python, becouse always can get the best of django in appengine
I use Groovy (Grails) with GAE. It has Java's library universe and you should have roughly the same LOC compared to Python. Yeah, its not 100% Java (if you want to), but very close.
The BIG difference is roughly the JavaVM speed, that's one of the reasons Groovy (Grails) has gained so much popularity - especially people like my who dislike Python .)
It maybe possible to use Jython in appengine so you could use both. One thing I would say about the python productivity vs Java productivity argument is Java has excellent IDE's to speed up development where as Python is really lacking in this area because of its dynamic nature. So even though I prefer to use Python as a language, I don't believe it gives quite the productivity boost compared to Java when using a new framework. Also I have as yet not been able to get the python version of google app engine to work in Netbeans which is a royal pain.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I always asked myself if it would be possible to make a Java to C++ converter.
Maybe a tool that converts the Java syntax to the C++ syntax?
I am aware that the languages differ, but simple things like loops where the semantics match 1 to 1.
Is there such a tool? Or is it possible to make one?
It's possible to do anything given enough time, money and resources. Is it practical? Beyond trivial examples not really. Or rather it depends on what constitutes an acceptable error rate.
The real problem is that the idioms are different in Java to C++. Java to C# for example would actually be far easier (because the idioms are much more similar). The biggest of course is that C++ has destructors and manually managed memory. Java uses finally blocks for this kind of behaviour and has garbage collection.
Also Java has a common Object supertype. C++ doesn't.
The generics to templates would be nigh on impossible I would imagine.
The Firefox HTML5 parser is written in Java and converted to C++. But I think the converter used there is quite specific for this project. Interestingly, it turned out the resulting C++ parser was faster than the old parser written in C++.
I'm also writing a converter as part of the H2 database, under src/tools/org/h2/java. The idea is to allow converting a subset of the H2 database to C++, so this is also not a general purpose translater.
And there is the open source project J2C.
So there are ways to convert Java to C++. But don't expect the translator support all features, and don't expect the resulting code to be any faster than a good Java JVM.
Is is possible, no question, but it won't be so simple. It would be a Java compiler which generates C++.
If you want to do that from scratch, it will be very hard, you have to do all the work javac and the JVM do for you (e.g. garbage collection).
Btw. Google has a Java to JavaScript compiler (included in GWT)
There is one, bit I am not sure if it actually works.
Java to C++ Converter-Tangible Software Soulutions.
It is weird how there are c++ to java converters, but only 1 java to c++ converter.
As said it would be tough to convert Java to C++ but we can have an applicaiton or tool that generates code in Java and equivalnet C++ code.
I know one applicaiton which generates code in C++/Java/C# given a model which has its own way to deifine it.
That tool belongs to CA and name is CA Plex.
Search on www.ca.com
There are programs out there that claim they can do this, but none have gained enough popularity to be frequently mentioned, so we'll leave them at "attempts". Making a converter would require a lot of AI built into your program. The difficulty is increased tenfold when swing is involved because GTK/wxWidgets/Qt/win32 API all differ greatly from swing. But it is possible. Not that the code quality will be great, and no guarantees your program won't crash due to separate memory handling methods, but it's possible.
The main issue is that java is a language that is written and designed to talk to a VM. I suppose it would be possible, but all you would be left is a very poorly optimized application with a self translating layer doing what the VM already does. I mean, sure, it is possible, it still wouldn't be a solution for anything i could think of. If your looking to make your sluggish java app native, maybe your thinking too hard, just use an application like JET, its actually quite good, and will give you the benefits a native app would bring. Of course if the VM is already doing what the app is asking it to do just as well as native code could(it happens.. sometimes :P) it might change nothing.
Java to c#, tho, sounds more reasonable, as both the languages are written in similar ways, talking to a framework as such, but this would still leave code very much unoptimized as code written from scratch for a particular framework can not be bested.
http://www.tangiblesoftwaresolutions.com/Order/Order_Upgrade_Instant_CPlus_Java_Edition.htm
Depends on the domain of where the code will be used, from a learning perspective perhaps it might be interesting.
i just found this via a google as I remembered seeing one in Univeristy that created code based on uml.
Java to C would actually be the easiest. Remember you need to convert the language, If you do that, the required libraries can be converted by your new compiler. In other words Swing and AWT should not be a big problem...
I would start by taking a good look at the Java Native Interface (JNI). The JNI is a part of java which allows it to be used with C and C++. The reason I would start here is that it becomes fairly obvious how parts of Java may be implemented in C. Once I had a grasp on basic structures, like how Java Objects can be mapped onto C structures (struct) and how pretty much everything in Java is an Object including arrays, I might peek at the Open JDK source code.
The actual converter would have to convert all the imported Java libraries (and their imported libraries and so on...) which means you would need the source code for everything. This conversion no small task since the Java libraries are large.
The process would be time consuming, but no AI should be required. However, I see no reason to perform a conversion like this. It looses the portability of Java and would not gain the efficiency of C (except that it would be compiled to native code, but it would be better to compile the machine code directly from the Java).
Something neat would be a tool , that translate java to "C++ using Java API" (like GNU GCJ CNI), one problem remain is to manage array.length (array not vector) ...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I just saw a comment of suggesting J#, and it made me wonder... is there a real, beneficial use of J# over Java? So, my feeling is that the only reason you would even consider using J# is that management has decreed that the company should jump on the Java bandwagon... and the .NET bandwagon. If you use J#, you are effectively losing the biggest benefit of picking Java... rich cross platform support. Sure there is Mono, but it's not as richly supported or as full featured right? I remember hearing Forms are not fully (perhaps at all) supported.
I'm not trying to bash .NET here, I'm just saying, if you are going to go the Microsoft route, why not just use C#? If you are going to go the Java route, why would J# enter the picture?
I'm hoping to find some real world cases here, so please especially respond if you've ACTUALLY used J# in a REAL project, and why.
J# is no longer included in VS2008. Unless you already have J# code, you should probably stay away.
From j# product page:
Since customers have told us that the
existing J# feature set largely meets
their needs and usage of J# is
declining, Microsoft is retiring the
Visual J# product and Java Language
Conversion Assistant tool to better
allocate resources for other customer
requirements. The J# language and JLCA
tool will not be available in future
versions of Visual Studio. To preserve
existing customer investments in J#,
Microsoft will continue to support the
J# and JLCA technology that shipped
with Visual Studio 2005 through to
2015 as per our product life-cycle
strategy. For more information, see
Expanded Microsoft Support Lifecycle
Policy for Business & Development
Products.
The whole purpose of J# is to ease the transition of Java developers to the .NET environment which didn't work so well (I guessing here) so Microsoft dropped J# from Visual Studio 2008.
For your question, "Is there a real benefit of using J#?"..
in a nutshell... No..
Instead of J#, I would rather prefer IKVM (http://www.ikvm.net/) to convert my JARs to .NET assemblies as well as access Java APIs in C#.
One of the killers I've found with J# in the past is that there is no built in support for referencing web services. That alone has been enough to deter me from it ever since.
C# syntax is so close to Java (and better in some ways) that you might as well learn C# instead of J#. And since C# is more widely used, you can easily find Java --> C# tutorials on google or check out http://www.asp.net/learn and watch some videos.
I don't think it's a matter of which language is better. In the .NET world there are some inconsistencies between the libraries different languages provide. There are certain functionality that is available in VB.NET that you might like to use from C# but can't. I remember I had to use J# to use some ZIP libraries that were not available in any other language in .NET.
I have used J# as an easy interim step to port a java library into C#. It made for a good way to port code I don't plan to maintain from Java to .Net. However, all new development is being done in C#.
Strongly agree that syntactically C# beats Java hands down, so there is really no reason to lament the demise of j#. Now trying to get c# compiling to Java bytecode might be an interesting move as Sun's hotspot jvm is great software.
Or, for a bit of fun with what might well become the next generation of Java, how about Scala on the CLR...