Slashdot Mirror
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".
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.
Check out http://www.microsoft.com/net/whatis.asp for an explanation on what .NET is. Take special note that .NET is not the Common Language Runtime, or the C# programming language, or Visual Studio.NET, or Visual Basic.NET, or the SOAP Toolkit, etc. Those are part of the .NET Framework, or the platform that enables you to build .NET services (since .NET is all about XML-based web services).
As far as what benefit you gain, that's twofold. With the .NET Framework, specifically the Common Language Runtime, you gain the ability to easily work with objects across many different languages, without any grunt work to get in the way (such as making sure you write everything as a COM object, and doing your own reference counting, and making sure you initialize and deinitialize COM). And since all the objects from code targetting the CLR are exposed as COM objects, you can even use them from languages that don't support the runtime, such as C, non-Managed C++ (aka, C++), VB6, Delphi, or any other language that supports COM objects.
.NET itself is more about server-server communication over the web. By passing around SOAP messages (via SSL, when security is an issue), you can implement anything from alerting users that they're being out-bid on something like eBay, to providing stock quotes more easily (without having to "scrape" html pages), to offering choice hotel information when you book a plane flight, and so on. Yes, all of that can be done now, but .NET aims to make it much easier. The potential for XML-based web services is pretty much bounded only by your (editorial your) imagination, and since it's all based on standard communication methods (HTTP(s), SOAP), you won't have to define new protocols for passing data around each time you want to do something new.
There are similar things out there, such as XML-RPC, but they don't focus as much on providing web services as .NET does.
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.
Java and C# are already pretty similar...how am I going to know at a glance which one I'm looking at. Surely the differences between the two (which are subtle, but certainly there) will catch people up all the time.
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.
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.
Yes, I'm quite serious. I have several friends that run Linux, and several people at my dapartment at the university, as well as at a small company I also work for, run Linux. No one runs any java apps. Two of my friends use Java in classes, so they have the VM (and development packages) installed, but they never use it for anything but class projects.
I had a JVM installeed for a while recently, as I tried to run a roleplaying accessory (pcgen) written in Java, but it was just far too slow to be useful, so I removed the stuff again.
/Janne
Trust the Computer. The Computer is your friend.
Talk to Sun. It's not that Microsoft wanted to stop supporting Java; they loved the concept. They had, until Sun stepped in, the fastest JVM available. It's quite the opposite of bloated, considering Microsoft has not been permitted to update it since 1.4, which means it's lacking the bulk that Sun has been scrambling to add.
Oh well, I'd like to see Java stand up to DirectX.NET.
Let me give some input from the perspective of a systems engineer rather than a software developer. Someone who has to run the crap you programmers put out.
That sounds like a marvelous idea. And the next time a nasty virus/worm creeps in that exploits some flaw in Outlook, you've just lost all your corporate data because that worm will crawl from component to component thrashing everything in its path, completely oblivious to Microsoft's so called security. All in the name of integration. Does it still sound like such a great idea? There's nothing you as a developer can do to stop it, because all you're doing is writing tools for a fundamentally flawed platform. You can't fix the platform, and you can't choose a better one. You're locked in to Microsoft.
There's nothing wrong with using a single vendor as long as you're not locked into that vendor. Any production systems engineer will tell you there has to be a back-out plan before you make any change. Where was the back-out plan when people started choosing Microsoft? With Unix, if you don't like one vendor, choose another. If your code is well written it takes little to no effort to port it and recompile (if any porting is even necessary). Switching from MySQL to Oracle? I don't know about C, but in Perl, it's as easy as changing one line of code (if you were foolish enough to hard-code your DSN string). Want to port your business logic server but not your clients? If you want to switch from Microsoft to some other vendor, well.. Good luck, and have fun re-writing your application from scratch. I said I'm not a developer, but I'm a systems engineer who occassionally writes useful tools to make my job as a systems engineer easier. I write AND TEST those tools on my desktop Linux box. I run them on $500,000 Sun Solaris servers. I generally don't even have to change one line of code. I can do that in C/C++, Perl, PHP, Java, Python, and any number of other languages. I can even write a program in C that interacts with another program written in Perl. Try writing a tool in C# or VB or some other new proprietary Microsoft language or even one of the standard languages like C. Now try compiling that code and running it on a Sun server. Won't work.
The people who think Microsoft is the best solution, generally have lived their entire lives locked into Microsoft and don't know of a way out. This is how Microsoft has made its billions, and how despite all its devistating flaws, remains a top competitor.
"We can make this work, but you're going to need a screwdriver, pocketknife and some duck tape."
Ahem. Only about 40% of the .NET framework APIs have been submitted to the ECMA. We'll see if the other %60 make it and in what form. :)
KangarooBox - We make IT simple!
Gotta love the title:
Apply here to screw Java: Microsoft recruits more J# developers
Sigged!
This is not the same as perl.
.Net creates the possibility of writting code/systems that could not execute before, just that now, this code can run efficiently.
.net you'd be copying a chunk of memory, having the process update fields directly, and then copying it back.
Its not that
Currently with COM, cross language inter program communication (or cross machine program communication even in the same language) a lot of time has to be spent reading, interpreting, and converting data types (especially object types) into the native language of the program. So if you had a payroll tax program on another machine and you wanted it to update your employee record (object), you might have code that reads something like:
UpdateTaxes(MyEmployeeObj)
Under
Under traditional systems, the object your passing has to go through packing and unpacking of each field, in both directions
C++ is faster than C# so why would I use .NET?
C++ is marginally faster than C#. However, C# is Hella easier to code in. No worries about pointer-math. No concerns about garbage collection. You don't have to write COM interfaces... I can write code that does the same job, in half the time that performs at 98% the speed it would if written in C++.
With the time saved, I can go home and download more pr0n.
--Quidquid latine dictum sit, altum sonatur.
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