J#
fuze writes: "It's basically a way for Java developers to migrate their Java apps to .NET.... even provide a 'convenient' migration tool... check it out on MSDN." News.com has a story describing Microsoft's plans to suck Java into .Net, and some commentary saying basically, "No one will use it".
Maybe I missed the point, but it's a migration tool. It's not meant to take the place of Java, or even really compete with Java, other than it makes it possible for developers to take their existing java code and move it to the .NET platform with relatively few changes. This means the old objects are now accessible to all .NET languages (C#, VB, Managed-C++, and all the other marginal languages that have been ported), making it less painful to move over to C#. Until the old modules are reimplemented, they're still available. Moreover, even non-.NET languages will have access to those objects as COM objects, since that's a benefit of the CLR. So if you want to write code in C, or non-managed C++, you can still get at those objects (which you couldn't do before without extra work).
And in other news Microsoft has publicly announced plans for the following projects:
.org (DON'T even ask what it is)
1. GNU#.net (RMS finally gave up and was hired my MS)
2. OSX.net (Steve jobs has now finally ground his teeth all the way off)
3.
Spotted this on the GNOME Weekly Summary:
:)
Hello World in C# using the GTK toolkit
The syntax does look pretty clean.
It's not quite up to Java GNOME functionality yet, which is now compilable to native binaries, with gcc3 (For those of us who couldn't care less about platform independence but really like Java as a modern language). More choice is always good however.
Microsoft are still strongly implying (at least) that Visual J++ is Java. Uh, wait, didn't a court tell you to stop doing that?
Tsk, tsk, Bill. There's no "other" in that sentence.
The focus seems to be on J++ developers, not Java developers. But personally, I will use J# iff:
Basically, I can live with loading J# and hitting compile once for each of my Java projects. If it's any more hassle than that, I agree, it's not worth my while.
However, I'm keeping an open mind. Microsoft's decision to not include a JVM in WinXP concerns me, as does the increasing size of the Sun VM. I love Java and want to keep using it purely, but I'm not going to cut off my nose to spite my face. If Microsoft and Sun collude to make it hard to use Java and easy to use J#, I could be swayed. I hope not though.
If you were blocking sigs, you wouldn't have to read this.
This is the perspective of someone with a couple of years experience in "enterprise" development, i.e. apps that have a UI that is probably a bunch of data entry forms, a database at the back, and a "business logic" layer that looks at the input, massages it, acts on it, sends it to the db, etc.
.NET language can be accessed by another .NET language.
These sorts of apps are not very sexy compared to writting an OS or a game or something, but they're what 90% of developers in the world work on.
A typical enterprise app will need to have a bunch of different front ends (e.g. web interface, a simple gui for data entry clerks, a bunch of reports) etc. Also, you'll have lots of people working on different bits and peices, and lots of changes going on all the time, e.g.say a sales manager comes up with a new promotional scheme that gives volume discounts you need to update your app to handle the calculations.
So with all these people working on apps that are evolving rapidly, you can end up with spaghettii code pretty quickly. If you want to have something that's maintainable, you really need to use OO and come up with an object model that seperates the user interface, the business rules, and the data layer.
The problem with this is that it is hard to have an object model that works well over distributed systems, and hard to have an object model that can be used by developers using multiple languages.
COM is a start to allowing objects to be used from multiple objects, and over distributed systems, but it has limitations, largely related to the fact that different languages don't have the same idea of basic data types.
.NET solves this by making all languages share a virtual machine that defines a bunch of basic data types, and a base 'object'. This means that any object created in one
So you can have a your web front end people write ASP (VB) pages that interact with business logic written in c# without having to compromise your object model.
There is always the fact that Java is being natively excluded from Win XP.
Uhh, hello? Didn't Sun just sue Microsoft? Aren't a bunch of other companies, including AOL and Real arguing with MS right now over bundling of products? It's not as if MS are saying that you can't run Java, they're just saying that it's a piece of third party software, you have to install it yourself, just like you have to install, say, WinAmp if you want it, or Photoshop.
Sorry, but I think Microsoft are doing the right thing here, or at least they are doing the least-worst thing.
Isn't it all supposed to be about choice? A world where Java is the only language (and we all know how responsive Sun have been to the wishes of the community, can you say ECMA standard?) would be a poorer world than one where Java/J2EE and C#/.NET have to compete on features and quality.
There's one way out of this for the Anti-Microsoft camp: get Java to be like C, SQL and FORTRAN, an ANSI standard. Until we see that, this battle isn't one for the engineers, it's marketeer vs marketeer.
I'll admit that I have never done any large scale programming, but this statement about language lock-in seems entirely false to me. I have done programming for research purposes and combined C with C++, C with Scheme, and used tools mostly written in C call Fortran libraries. I have seen and used examples of Perl and Python programs accessing common C libraries.
Where is the lock-in?
Reality or nothing.
I ask the question :- if you were a director/shareholder of a company like Microsoft would you
.NET that ultimately play back into your desktop Windows (XP) market, or
a) play to your strength and leverage your current market domination and try to eliminate competing standards while creating new "standards", eg
b)go open source, support Java, employ open standards, go cross platform, etc etc and risk losing any market dominance you have now?
Legally, you would have no choice at all. If a director fails to act in the interest of shareholders, the penalty can be a jail sentence and a ban from ever running a company again, at least under UK law. Yes, that's right, you can go to jail for doing the "right thing". Unless you could prove that it was in the best interest of shareholders - who will tear you apart if you miss your quarterly earnings target - there is no option for you but (a).
The reason corporations put profit before everything else is because the law - created by the governments, who represent the taxpayer - have decreed that they must do so. It would be a little hypocritical to criticize a thing for acting in accordance with its nature.
Well, I understand that as a self-described "rabid Slashdotter," this might be news to you, but your entire premise is pretty wacked.
- your grip on the server market appears to be slipping
Hate to break it to you, but Microsoft's server market share has never gone down since NT first came out.
great companies such as google.com are proving that you can grab web market share fairly quickly with a better product
Well, seeing how Microsoft/MSN gets around 7 times the number of unique visitors that Google gets, and that they hang around the site around 25 times longer than Google's, you tell me how concerned they are.
technologies such as Linux, VM Ware, WINE and Java are threatening to nibble away your desktop market
They are? Funny that Microsoft's desktop market share, just like its server market share, went up over the past year. Guess they better be on the lookout for OS/2 and Amiga, too.
having some spectacular white elephants such as MSN on record
See above about MSN.
I think that the shareholders of Microsoft would be pretty relieved that it's one of the best performing stocks this year. Oh, and they're probably happy as Hell that they don't listen to Slashdot hype, otherwise they might've traded all their Microsoft shares for stock in VA Linux, Red Hat, and Sun, thus watching their kids' college funds go *poof*!
For now, yes, the .NET framework is only available for Windows. However, Microsoft has committed to providing a reference implementation for the *BSDs (FreeBSD, I believe), and other projects like Mono have sprung up to bring an implementation to Linux and other unix-like operating systems. Since Microsoft has submitted both the CLR and C# to ECMA for standardization (say what you will about ECMA, but at least it's a standards body), anybody can write their own implementation. Sun's backed out several times on submitting Java to ECMA.
That would be true, if it were the case that CLR bytecode only ran under the VM. However, that's not the case at all. The CLR has the ability to compile its bytecode down to native code for whatever machine you're on. Most likely the way this will happen is that CLR bytecode will be "shipped" (in a box, or as a download), and as part of the installation that bytecode will get compiled to your platform. What that means is that, taking a Windows-only view for a moment, when you buy Office.NET (just as an example -- I don't know whether Office.NET will be targetting the CLR or not), it won't matter whether you're running on a 32-bit x86-based system, or on a 64-bit iTanium (or whatever AMD's 64-bit chip is called), the same version will run on both. And with native speed, because after installation, you'll be running native code. Obviously, it's developer choice whether or not to compile down to native code, but that's the point -- the choice exists. And given full CLR implementations on other platforms, I don't see any reason why pure CLR bytecode wouldn't be perfectly cross platform, even to the point of compiling down to native code and running as a native app on your chosen system. Perhaps this is how we'll eventually see IE, Office, etc on Linux? (Through the efforts of Mono)
Ok, with COM and COM+, you could f.e. use a component written in C++ in VB or vice versa. However, when you're debugging your VB application and the error you receive is inside that C++ component, you're out of luck. (You can, in a way, compiled VB stuff in VC++, but it's a nightmare). With the CLR, you're not. You can step into that C++ component directly from your VB code. And if that C++ component uses a serie of C# components, no problem there.
The main advantage is here: development is faster in a team where every programmer can use the language he/she likes the most. Even if you're not familiar with C++ in the example above, you can pinpoint the developer who wrote the component that in line xyz his code bugs when you supply it the parameters your VB application passed to it. File the bug your bugtracker system et viola. The C++ developer can even use your VB application to debug his own code, without having to write a testapp in C++ that will supply EXACTLY the same inputparameters.
With COM and COM+ you don't have that.
Never underestimate the relief of true separation of Religion and State.
J# lets J++ and most Java developers get in on the .NET action. I say most because the version of Java supported by J# is 1.1. And yes, almost all of the hardcore Java developers are using Java 2 now (as they should be), but there's a large percentage of people still coding to the 1.1.x standard, either because they're still doing applets or because they haven't gotten all that serious about Java development.
The Java code doesn't compile to Java bytecode, but instead to CIL, the Common Intermediary Language (formerly MSIL), so that it can run under the Common Language Runtime, just like C#, VB.NET, JS.NET, Perl.NET, Python.NET, etc. It improves the interoperability because I can then take any Java class and use it like it was any other .NET class. Someone write a sweet applet or chat server or ssh client in Java? Cool, I'll take the .java files and compile them to CIL and now I can use the classes directly in my C# programs, extend them, whatever, just like they were C# files. And vice versa, and with any other .NET language.
Personally, I know it's not officially a migration tool, but I view this as more of a migration tool than anything else. Otherwise, you're going to be left using an older version of Java. It's important to note, though, that Microsoft isn't alone in this Java on .NET thing, so I think a lot of people need to calm down about it. What I mean is that other companies are going to be putting the Java language on .NET, just like other languages are being ported to .NET. And these companies will be using Java 2. So, I don't think that anybody should dismiss this concept just because Microsoft itself is only supporting Java 1.1 with it, because it's going to happen. For now, though, it is an important release so that Microsoft can support their Visual J++ users. As for a true migration tool, that's the JUMP tool (Java User Migration Path to .NET), which is coming out later, and from everything I've heard, will be for migrating Java 2 as well Java 1.1 code, probably to C#.
That said, I think there's a good benefit to it. A lot of Java programmers just flat out like the language, the whole WORA jive never mattered to them. It's really not a huge event, though, it's just one more language coming to .NET. One interesting thing, though, is that .NET programs run quite a bit faster under Windows than Java programs do. So, once a current Java is on .NET (and probably also a little bit with the older Java available via J#), Java on .NET is going to be pretty tempting to people wanting to squeeze better performance out of Java, especially if they really don't have much interest in non-Windows platforms. Interestingly enough, Microsoft could parlay this into its advantage in that .NET platform could ironically enough become the best platform on which to run Java programs. (Based on the few ports I've played around with in J# today, my really tiny code ( < ~30 LoC or so) runs faster in the 1.3.0-C JVM, while the larger stuff is running faster in the .NET CLR.)
Anyway, I really like the move, I'm glad somebody has finally put something out there which separates the Java language (which is pretty nice IMO) from the whole Sun vision of Java as a platform. Hope this helped...
>Well, seeing how Microsoft/MSN gets around 7 times the number of unique visitors that Google gets, and that they hang around the site around 25 times longer than Google's, you tell me how concerned they are.
considering that google is a search engine , and msn is just a mess, I would consider your statement to be a glowing endorsement of google. People get what they need 5 times faster!.
And it's true because you said it!.
You are right in that the advantage of CLR is that it is a level of integration better than COM, which is itself a level of integration better than the flat-DLL/library API function call interfaces that the original poster was happy with.
but
development is faster in a team where every programmer can use the language he/she likes the most.
Is it really? It hasn't been tested in the real world yet. IMHO, that's not a team, that's a collection of individuals going off in all directions. IMHO a project that's written in 5 different styles in 5 different languages would be a 'mare to maintain, extend or even to complete.
I'm all for picking the right tool for the job, and writing the project in the best language (or two) for the job, but in a medium-to-large project, it is important that code is collectively owned, well-integrated and understood by more than one person.
How will that work if everyone codes in thier pet language? Do you now expect Joe VB to learn not one but ten new lanuages? Or to not understand 4/5 of the project he is working on, even with the source? Language choice should not be made on personal whim, but as a group decision on language suitablity.
I see this as having the potential for of a whole new level of code impenetrability.
My Karma: ran over your Dogma
StrawberryFrog
I keep reading about this on sites like this. It should be pointed out that even the JRE (java run-time environment) for jdk 1.4 is well below 10 megabytes (mainly depending on the platform). Of course if you download the full jdk you have a bigger download, mainly because that includes, among others, various tools and the source code for most of the API. But even then we are talking about 30 or 40 MB.
Go check out Opera or netscape, both have an optional download for the JRE 1.3.x. I think it was about 6MB. The JRE includes everything you need to run Java applications. It is hardly bigger than MS jvm and does a lot more.
Incidently, there is currently a beta of an enhanced 1.3.1 JDK that includes an activex component that fully replaces microsoft's JVM. Yes that's right, you can now run all your applets in IE using jre 1.3.1. Of course it doesn't support the MS specific extensions of the JVM.
Jilles
First, a disclaimer, I am not a Microsoft advocate. Those guys can stick it up their ass. That being said, I will do what it takes to do my job and get paid.
The issue here is that *many* Java developers have been trying to code quality front-end applications on Windows using Java -- and have failed (or fallen very short). *I* am one of those people who have done so. I know many other Java developers who have failed to meet their expectations reasonably when coding on Windows.
If I know that my target platform is only going to be Windows, but I can't use any of the Windows libraries... what good is Java? Its not. So I have to go back to C++. But C++ is a horror in its own ways.
Too many in the Java community are zealots about what Java should and shouldn't be used for. The idea that if it isn't WORA (Write Once Run Anywhere) then it shouldn't be written in Java is completely ludicrous, IMHO.
Some Java developers want the elegance of Java with an easy way to utlitize Windows native libraries without having to write convoluted JNI interfaces all over the place.
The answer is J#. However, I was perfectly happy with the idea of C#. C# has some compilation advantages and syntax advantages over Java that I really love.
I have extensive experience with Swing (Java GUI libraries), and they just simply don't cut it for serious front-end application development. The more complex controls such as JTable and JTree are full of bugs, they are difficult to use, and complicated. If you want less complicated controls, you have to buy a proprietary vendor's API and use those, instead. The Windows 'look and feel' does NOT look and feel like Windows. Because of the MVC design, you have to import practically every single class in Swing into your programs.
AWT was much more compact and easy to use. It also was pretty snappy; however, it suffered from lack of GUI controls.
I don't see anything wrong with J#. If it works for you and serves your purpose, use it. If it doesn't, then don't.
But a little competition in the Java marketplace (or any marketplace) never hurts. Maybe it will light a fire under Sun's ass and get them to contribute more to the front-end side of Java -- which has been ignored for far too long.
Better yet, maybe they will open-source Java, instead. Even better.
Actually, if you are looking for less complicated tree and table components, check out the ones included with Ganymede.
I wrote them because I needed them for Ganymede development, and Swing hadn't quite come along yet. I kept them because they are simple to use, they are pretty high performance, and you can do fancy tricks like node dragging ihttp://www.arlut.utexas.edu/gash2/doc/javadoc/arl ut/csd/JTable/baseTable.htmln the tree with little-to-no effort.
You can read the Javadocs on them here and here.
They are licensed under GPL, along with the rest of Ganymede.
- jon
Ganymede, a GPL'ed metadirectory for UNIX