Related
To make development portable to Java, does it make sense to do the whole development on J# vs C#? What happens to missing bits in Java that exist in C# like lambda expression and so on?
What is the best way to achieve portability?
I definitely wouldn't use J# - it's not supported any more, and it only supported Java 1.1.4 anyway, IIRC.
I would personally recommend keeping the overall architecture consistent between the two languages, but then write the code separately, manually, taking into account the different idioms in the different languages.
If your codebase uses data-driven tests, it would be good to share that data between the two languages, as a way of helping to ensure data portability.
I suggest you don't use J# anymore as it has been discontinued. The last version has been shipped with Visual Studio 2005.
In addition to J#-specific language extensions and .NET CLR support, its runtime library implements Java 2 Collections Framework (without the java.util.concurrent extensions, though) and even some JFC/Swing, via the Supplemental UI Library.
So you'll be limited to the Java 1.4 API.
Given that J# has been discontinued long ago, I wouldn't suggest you invest your time into it.
If you really need portability between JVM and CLR, I'd take a look at IKVM (implements Java 1.7 API on top of CLR), Scala for .NET (discontinued circa Scala 2.10) or languages like Ruby (JRuby/IronRuby) or Python (Jython/IronPython).
Alternatively, you can generate your C# for .NET -- there're Java to C# converters available.
Is .net 2.0 an overhaul of .net 1.1? in other words if you are let's say following a book written for .net 1.1 (ASP.NET 1.1/C# 1.1) then do you have to "unlearn" something which is totally different in advance versions such as 2.0 3.5?
I am reading a book by Richter "Applied .net framework programming", that's why I wanted to know some points from experienced folks.
For the most part, what you would learn in a .NET 1.1 book applies to .NET 2 (and .NET 3.5/4). The one major exception, and the reason I never recommend anybody start with .NET 1.1 now, is generics.
The handling of collections was made dramatically better in .NET 2+. Prior to .NET 2, collections were all not type safe (ie: ArrayList). After .NET 2, we had the ability to use type-safe, generic based collection classes (List<T>, so you can do List<int>, etc).
This dramatically changes how people write code (or should!). I'd strongly recommend starting with a .NET 2+ book to learn today. Learning from a .NET 1.1 book will teach you bad habits, because you'll be learning collections that have almost no purpose in current .NET code.
That being said, .NET 4 is now released, and there's no real reason not to start there, if you can...
It is a significant change from 1.1 to 2.0. 2.0 introduced generics as well as new classes to deprecate and replace functionality offered by older 1.1 classes. It would still be good to know 1.1 code and objects, because you'll still see them in the wild, but I wouldn't base my beginner's knowledge upon a 1.1 text. Keep in mind, .NET is now up to 4.0, so even starting at 2.0 would be behind the times, but not nearly as bad as 1.1.
I would find a resource that at least covered C# 3.0/.NET 3.5, and sprinkle in knowledge of 1.1 as needed.
There are a few libraries that were 'overhauled' and some that were deprecated. We are at .net 4.0 by the way.
Here is a list of changes that were blogged on MSDN
http://blogs.msdn.com/b/brada/archive/2005/11/14/breaking-changes-between-net-framework-1-1-and-2-0.aspx
.NET 2.0 introduced a lot of new functionality. Specifically for ASP.NET the inclusion of datasource controls, the provider model, sitemaps, ... were introduced.
If you want to learn ASP.NET now or will buy a book I suggest you rather look for something about 2.0 or 4.0. Preferably the latter if possible.
Since 3.5 Ajax and several related controls for that got introduced with the framework, you could add an extension to 2.0 if needed. That's a major improvement to the whole ASP.NET framework as well so be sure to check that out as well.
It's not a complete "overhaul" but there are significant changes. Much of what you learn will carry over but why not just learn the latest version?
In general, .NET 2.0 is a superset of what is implemented in .NET 1.1. A few functions in 1.1 may have changed in 2.0, and some classes may have been deprecated, but on the whole you shouldn't have to "unlearn" anything. You will have a lot of new stuff available to learn, but you can write code that compiles to the 2.0 framework using your existing 1.1 knowledge and skill set.
For the most part MS did not make that many breaking changes between 1.x and 2.0. 3.0 and 3.5 are library released that just extended the 2.0 runtime with things like LINQ, WCF, WPF and WF. 4.0 has many breaking changes does to a reorganization to support the Client Profile (the libraries avilable on a cutdown client like the Windows Phone) vs the full profile (what you would run on a server).
#Zai based on your comment I have always found the Programming C# series a great survey of what exists within C# and the .NET Framework.
If you have a 1.1 book just burn it. Why bother, go read the MSDN and learn your generics, extensions, and lambdas up front. Sorry don't burn it, recycle it, cut the binding off and put it in a printer tray.
Microsoft has always been releasing platforms which are backward compatible. Given the fact that we are already on 4.0 version of the framework, I would suggest starting with 2.0 framework as most of the books would cover the basics which almost remain the same. The exclusions would be things like Generics as mentioned above.
I wouldn't suggest directly jumping onto 3.5 or 4.0 framework as there will a learning curve involved in getting to know the specifics related to those framework.
.NET Framework 1.1 is almost seven years old. I recommend you discard your .NET 1.1 book, even though it's from a great author. Don't bother learning .NET 1.1 at all.
Even to the extent that there are parts of .NET 1.1 that have not changed in all this time, the way things aer done in .NET has changed dramatically in the intervening years. Generics, LINQ, WCF and many more things make the entire mindset very different between .NET 1.1 and .NET 4.0. A book written for .NET 1.1 will be teaching you to think the wrong way about things, and you'll be very surprised when you find other developers asking you "why did you do it that way?"
I have just started working on a reusable library. This library is going to be pretty big and since it involves communicating with external devices over various communication media (such as RS232, TCP/IP, Radio etc), I am thinking about providing support of performing operations that involves communication, asynchronously.
I have read the .NET guidelines, various articles etc. Many sources refer to future developments in .NET 4.0 regarding asynchronous programming.
I have 2 options:
Forget .NET 4.0 and implement the library using best pattern/method available today.
Read, learn and play with .NET 4.0 so that my library gets benefit of up-to-date language and framework facilities.
Considering that release timeline of my library goes till mid next year (2010) and quality of library matters more than release date (Yes, I am lucky), what option would you recommend?
If you suggest option-1, is there anything I can do to make my library ".NET 4.0 friendly" (easy changes in future to use advanced parallel features)?
If you suggest option-2, how stable the current parallel features in .NET 4.0 or how much rework you expect because of working on beta platform?
You say that your library is due to be released next year - do you know what version your customers are likely to be running? .NET 4.0 will still be quite new at that point. If your customers aren't willing to run it, that rules it out.
If you can use .NET 4.0, I'd say that the PFX bits are likely to lead to much cleaner code. It's really nice. Things are still changing though... I know that there will be some changes between beta 1 and beta 2. My guess is that beta 2 will be a lot closer to the final bits though.
EDIT: Okay, so if you can use .NET 4.0, I would do so. I have a lot of faith in the PFX team, and it's a very nicely designed library. One difficulty is that while there are loads of blog posts and some documentation, there aren't "real world applications" books yet - and you'll find that some of the blog posts will be slightly out of date already. I suggest you start with the PFX team blog as well as the documentation in beta 1. Just be aware that things will change...
I would clearly go with option 1 - write your library using the idioms that work now.
As for making future transitions easy, make sure you design the public interfaces well. Use the same principles as always, i.e. keep them clean and don't expose internal implementation details.
Regarding your first point, all 3.5 or even 2.0 assemblies can be used from .NET 4.0. As of 2.0, .NET is fully backwards compatible (till 2.0 anyway).
Here's the deal: I'm in the process of planning a mid-sized business application that absolutely must support Win2k. AFAIK, official .NET support for Win2k was scrapped a while ago (IIRC, it stopped at version 2.0).
Now, I already wrote (ages ago) libraries in C++ that allow me to accomplish the end result (i.e., finish this project) just as quickly as if I was writing this application with the help of the .NET Framework -- so .NET's RAD "advantage" is almost negated.
I'm sure a lot of people here deal with business applications that need to support old OS's. So, given my library situation, what advantage(s) are there for me in using .NET over native C++ and vice versa? I'm just not sure which of the two is right for the job -- because it seems that I could use either. Then again, there's that framework support issue to deal with...
I will gladly add more information, if required.
The last .NET version that runs under Windows 2000 is .NET 2.0 SP2. It does include the features required by System.Core.dll (that is part of .NET 3.5).
The answer is YES, you can use .NET 3.5 SP1 under Windows 2000 if you're not going to use .NET 3.0 libraries (WCF, WF, WPF, CardSpace). But you have LINQ, LINQ to XML, LINQ to SQL.
The only thing you need to do is to deploy three core .NET 3.5 SP1 files:
System.Core.dll
System.Xml.Linq.dll (LINQ to XML)
System.Data.Linq.dll (LINQ to SQL)
Disadvantages of this method (read carefully):
Not sure whether it's permitted or forbidden by the EULA (end-user license agreement)
This scenario is not supported by Microsoft.
I'd look to see if Mono (mono-project) works for you. i.e. runs on win2k - if it does it would allow you to port your app to MS .NET and later OS versions should the need arise later in the project. Any .NET is going to be easier than C++ IMHO :)
The biggest difference is that you are (or your boss is) more likely to find developers to maintain your .NET code after you move on to other things.
C++ has the advantage of giving you job stability - although that might not be what you want. :)
I think, given your situtation, it boils down to what you feel more comfortable in writing. If C++ is a comfortable language for you, do that. It will help get you into the code and make it easier to finish.
I would also take care to keep the future in mind. If the Win2K requirement drops that might require you to rewrite if you wrote in C++. It might not. Just keep it in mind while you decide how to proceed.
You can develop with .NET but set the compiler options to target the .NET 2.0 framework. If the OS gets upgraded in the near (or far) future, you can upgrade your program to target the 3.5 framework. I would go this route as it allows for easier future maintenance by others.
Have you considered Delphi? You can download Turbo Delphi for free and it you can easily write code targeting Windows 2000. With Delphi, you'll get an excellent RAD (arguably better than anything you'll find in C++...unless you use C++ Builder).
Delphi creates native code, and has no runtime requirements.
Of course, the downside is if that you don't know Delphi (which is Object-Pascal) you have to familiarize yourself with a new language. However, if you know C++, you'll feel at home in Delphi in no time.
We Want to Run Our C# Code on the JVM
My company has a large C# code base. Well over half of this code is our core engine for creating, reading, modifying, calculating and writing Excel workbooks. We frequently get questions from customers and potential customers asking whether we are going to build a Java version of our engine - many of them are not at all interested in the UI. We even have a few customers who have taken the trouble to use our .NET library from their Java applications.
So, we would like to build a Java version of our core engine, ideally without maintaining a separate Java source code base.
Eric Sink described this problem very well. I am in a similar position except for the fact that our software license includes royalty free deployment, making Eric's choice of Mainsoft a nonstarter for us.
I have been Googling the likes of "c# to jvm" every few months for several years now with no joy. Having spent ~7 years developing similar software for Java, I am confident that the .NET APIs we use in our core engine could easily be encapsulated and we could accomplish everything we need using the Java libraries. So, if we only had a C# -> JVM compiler we could build our core engine for Java and we would no longer have to turn away Java developers who would like to use it.
I am not asking for the technical reasons why Sun does not do a C# compiler. I recognize that Java has no properties or an unsigned 64 bit long, etc... For the sake of argument, just assume that all of these technical issues could be dealt with by extending the JVM and / or other means.
And I am not asking for yet another debate on why one language / stack might be better than the other. The reality in our business is that there are plenty of potential customers using each.
Why Should Sun do a C# Compiler? (IMO of course)
Making it easier to run C# code on the Java platform means more developers and more software for the platform. Is there anything more important to the success of a platform? Jonathan Schwartz is a software guy. I will leave it to others smarter than me to decide whether or not he took on an impossible job as President and CEO of Sun, but having met with Jonathan shortly after he joined Sun my impression is that he understands software and the need for a large base of developers.
So Why Doesn't Sun do a C# Compiler?
NIH syndrome?
The ghost of Scott McNealy?
Too many Java developers dislike or distrust anything related to Microsoft?
They agreed not to as part of taking the big bucks?
???
There must be a good reason. I just cannot for the life of me figure out what it is...
Firstly Sun has zero incentive to implement a C# compiler on the JVM because they have something very similar called the Java programming language.
Its also not really as simple as just implementing a compiler as the Java standard class libraries are not the same as the .net Base Class Libraries. You would end up having to change all the .NET API calls to Java API calls.
Micrsoft had a product called J# which was meant to be for Java to .NET conversion but in the end no one used it as the API was limited to pre Java 2 API so it was mostly useless. It would be the same if Sun implemented parts of the .NET BCL, as only the core portions of it are standardised and royalty free. Parts like ASP.NET and WPF, WCF etc are not part of the ECMA standards and so Sun would need Microsofts permission to implement those API's.
If enough customers want a java version to make business sense to port your application to java then do it, you just wont ever get any help from Sun via a C# to JVM compiler.
Joe Erickson wrote:
Making it easier to run C# code on the
Java platform means more developers
and more software for the platform.
This is an untrue statement. Running C# code on the JVM does not create Java programmers, it creates C# programmers who can execute on a JVM. It only expands the reach of C#, assuming the JVM also translates any microsoft specific calls (i.e. win32) into something that is platform neutral. So if Sun translates IL to Java Bytecode, the only group it helps is: Microsoft. And, given Sun's history with Microsoft during the original C#-Java schism/Visual J++ lawsuits...
Plus, you have to face the technical infeasibility, whether you want to or not. There are fundamental differences in the way the bytecodes are executed that are far more important issues than whether or not there's an unsigned long datatype.
If you must have C# on a non-Microsoft platform, use Mono
Why doesn't Microsoft do a C# to Java byte code compiler? Why don't you do it? There are open specs on each side...
"So, we would like to build a Java version of our core engine, ideally without maintaining a separate Java source code base."
Basically, you want to compile your C# code unmodified, and have it run in a Java-only environment.
IKVM is not what you want. IKVM is three main things.
a. ikvm - CLI implementation of a Java virtual machine (note that this uses Classpath (now OpenJDK) for the Java class library).
b. ikvmc - Compiles java bytecode to CLI bytecode.
c. ikvmstub - Generates java stub classes that call CLI code.
Note that all of these tools depend on CLI at runtime. What you want is exactly the opposite of IKVM, which is of course MVKI (Most Venerable Kompiler Intermediary) :):
a. mvki - Java implementation of a CLI virtual machine (presumably this would use Mono or DotGNU for the class library).
b. mvkic - Compiles CLI bytecode to Java bytecode.
c. mvkistub - Generates CLI stub classes that call Java
Note that none of these would require an existing implementation of the .NET Framework at runtime, so they should be satisfactory to your Java-only customers.
Unfortunately, as far as I know MVKI does not exist, so you're best off doing a manual port (which would inevitably be cleaner, albeit more work).
Edit: Based on the description of Mainsoft, it appears to be similar to MVKI, though I'm not sure what they do for the class library, and unlike IKVM it's not FOSS.
http://jsc.sourceforge.net/ is a c# cross compiler that can convert .NET code to Java (amongst other things).
Expose your .NET API as ASMX web services and you should be good to go.
EDIT: For more heavy-usage scenarios, it would be worth looking into Windows Communication Foundation (WCF). This has built-in, configurable support for security, streaming, different transport scenarios (HTTP, TCP/IP, local named pipes). You are not restricted to SOAP message encoding, but that would probably be the easiest way to interop with Java.
I'm not too sure about your exact scenario, but if you're dealing with large files and the .NET code and Java code are both running locally, you can just save the file to the user's hard drive using .NET and then fetch it from your Java app.
There must be a good reason. I just cannot for the life of me figure out what it is...
It is easy to believe that companies are non-profit organisations which have your interests at heart. It is easy to forget that the only purpose for a listed company is to make money for it share holders. This is a legal obligation and directors/executives have been sacked/sued if share holders don't believe they have failed to do this.
Sun makes Java free because it helps sell their hardware which how it makes money from Java. IBM makes Java free because it helps them make more money on their consulting.
If Sun were to spend money on a C# converter how would it make that money back and make a profit. Imagine you have to convince Sun's share holders. If you can, Sun will make a C# converter.
I wonder whether the Mono project could have made less work for themselves by targeting the JVM instead of developing and maintaining their own virtual machine from scratch. Development effort could have focused on a C# cross-compiler and porting clean-room implementations of the .NET libraries to the JVM. Sort of like an open-source version of what Mainsoft has done. You could then enable inter-language calls between Java and C# code in the same JVM, and deploy Applets and Java Web Start applications written in C#.
I know this might not be what your looking for, but here are some possible alternatives that (if not to you) could be useful to others.
C: You could port as much as possible to C. Now you can make a wrapper in C# and Java (and any other language that can communicate with C) that makes it feel native to their language while programming. The problem now is that you (or them, depending your license) has to build the C part for each platform.
Fantom*: A programming language that according to their home page,
is:
Portable: Write code portable to the Java VM, .NET CLR, and JavaScript in the browser.
Familiar: Syntax Java and C# programmers will feel at home with Fantom's evolutionary syntax.
Object Oriented: Everything subclasses from Obj. Value types when you need the performance.
Functional: Functions and closures are baked in.
Static and Dynamically Typed: Don't like the extremes - take the middle of the road.
Haxe*: (pronounced hex) is cross platform language that compiles to other languages. Soon C# and Java will be supported. It currently supports:
Javascript: You can compile a Haxe program to a single .js file. You can access the typed browser DOM APIs with autocompletion
support, and all the dependencies will be resolved at compilation
time.
Flash: You can compile a Haxe program to a .swf file. Haxe is compatible with Flash Players 6 to 10, with either "old" Flash 8 API
or newest AS3/Flash9+ API. Haxe offers very good performance and
language features to develop Flash content.
NekoVM: You can compile a Haxe program to NekoVM bytecode. This can be used for server-side programming such as dynamic webpages
(using mod_neko for Apache) and also for command-line or desktop
applications, since NekoVM can be embedded and extended with some
other DLL.
PHP: You can compile a Haxe program to .php files. This will enable you to use a high level strictly-typed language such as haXe
while keeping full compatibility with your existing server platform
and libraries.
C++: You can now generate C++ code from your Haxe source code, with the required Makefiles. This is very useful for creating native
applications, for instance in iPhone development.
Haxe Community. (2011, March 11). Haxe Introduction. Retrieved January 29, 2011, from http://old.haxe.org/doc/intro
You can learn more about why Haxe is useful here.
*I have never used this language and I don't know how well this would work.
I made a comment that should really have been an answer:
It is just not technically possible at this point to implement the C# spec on the JVM. C# supports pointers, unsigned types, user defined value types, true generics, passing by reference, and loads of other things. For a very C#-like JVM language, check out Stab.
Mainsoft fakes it. I am sure it takes enormous effort on their part.
Have fun.
Must break checked exceptions.
Must find a way to implement delegates (which are like single-method interfaces added no earlier than load time).
You can run your .NET code and Java code in the same interpreter! See the IKVM .NET-based JVM, and the Boo and Java wiki page for an example use case (using the .NET-based Boo language to write applications using Java libraries).
Joe, I suggest you investigate IKVM. You might find something there that scratches your itch
If i was doing something like cross platform cross language support, I would create a 'common api' since the languages are similar in syntax you could make a translator easy enough. Then instead of calling java or .net apis directly from the core, you would call your 'common api' which would re implement the java and .net apis you would need. In this way you could create a cross language sandbox if you will. Since the main differences in java and c# are object definitions, I would get those by reflecting the C# dlls, and then reconstruct the constructs, then it would be easy to have an interpreter run through and implement the function bodies and convert properties to getters setters already knowing the structure of the files. This of course is assuming .net 2.0, some of the features in 3.0 and 3.5 become very difficult to 'interpret'
It would be complex, but probably not as complex as reconstructing a core in java by hand, and having to have 2 teams working on them seperatly. If this idea sparks some inspiration i might create one. I would really rather see a simpler stable mono installation for mac.
Basically I think a code level interpreter based on a set of common api classes is something very possible to write with a team in a week or two.
Simple. Because Sun would rather not be sued by Microsoft. And while we as programmers might see no viable reason for a suit, keep in mind that Microsoft is quite a bigger company than Sun and has the power to boss them around.
Sun fortunately is in the position of being quite more open than Microsoft however. If such a demand exists, either open source or a third-party could make this compiler for Java and Sun wouldn't have to take the heat.
JACIL is an apparently dead project that attempts to do the reverse of IKVM. Perhaps some motivated folks could use it as a starting point for a viable .Net to JVM compiler.
I guess the better question is why don't you write a C# to Java byte code compiler, if you want one to exist. Waiting for corporate overlords to do something is a bad idea.
A suggestion for creating such an implementation: take Mono's or .GNU's C# front end. Don't bother writing your own.
I think you will find that the Mainsoft, Enterprise Edition tool allows you to run most/maybe all your .NET code under the Java JVM... Seems to be focused more on ASP.NET but will allow C#. It has been available for some time, pity they don't publicize it better!
Warning blurb follows....
Mainsoft® is Java-.NET
interoperability software that enables
IT organizations to move to
Java-enabled platforms such as Linux
while preserving existing investments
in .NET code and skills. The software
integrates seamlessly into the Visual
Studio® development environment,
enabling C# and Visual Basic
developers to rapidly develop and
maintain server and Web applications
that run on Windows, Java EE platforms
or both, thereby reducing application
development and maintenance costs,
time-to-production and total cost of
ownership.