Slashdot Mirror
Does .NET Sound Like Java?
zero asks: "Looking over at the MS Web site, a lot of the ideas behind .NET remind me of Java - and so does the hype around it. I remember when it was said that Java would revolutionize the way things work by having applications loaded on-demand off the network (for example)... sound familiar? It would be interesting to hear what the Slashdot community thinks of what MS is doing better (or what they think they're doing better) in their plans for .NET, and how much potential they have."
Amazing! You're wrong on practically every point!
.NET software is (will be) run server-side.
.NET can be kept so that it is not open sourced.
.NET compile down to bytecodes. Sure, you can decompile Java, but there's nothing to say you can't do that with .NET too. And the .NET spec is more open than Java's.
.NET is comiled and must be run on platforms that it is compiled for.
Java software is run client-side, while
You're thinking of the XML Web Service stuff. We're talking about the Common Language Runtime, which can be used to write client code too.
Other differences include that Java, by its very nature, is open source (that means that you can always read the source - that doesn't mean that it is free though...). OTOH,
I don't know where the hell you got this idea from. Both Java and
Further more, Java is an interpreted language and can run on any platform.
Wrong. See all the other posts in this thread.
And since M$ has its dirty hands all over it, we can presume that it will be some time before compilers are available for non-M$ systems - and even then not 'legal' compilers.
Wrong. It's a fully open standardised spec.
How about even *remotely* checking your facts next time before posting?
OK, something that that has been at the back of my mind for a few months now.
1) MS talk about releasing Office on a pay-per-use basis over the net.
2) MS release a fairly powerful computer with a network port on it. They call it a games console, make sure it has a nice graphics card, and then try to get it into as many living rooms as possible.
3) MS come up with something that looks like a JVM.
4) MS make sure it has a security model, bytecode verification etc...
etc..
Is the X box going to be a Network Computer ala Sun's Network Computer that Microsoft said was a bad idea a few years back?
I've used Java on and off for a few years. And I've played with the Visual Studio .NET beta recently.
.NET is very much centered around a Java like architecture. MS has added some useful features, and altered VB and VC a lot to bring them into line with the new runtime environment. It also required W2K (big surprise).
.NET runtime environment along with VB and C#.
.NET world (most VB apps I've seen could care less about the internet/web/online world). All this does is abuse their installed base of VB products and generate more rewrite/headaches for existing apps.
.NET is definitely modeled heavily after Java. I think it was a mistake to go so heavily in that direction. Net based applications are still heavily outnumbered by local and client/server applications in most businesses and that isn't going to change soon. They are abusing/abandoning their enterprise customer base to chase the internet application development market. Bad Move. Java is a good design for somethings, but not for everything.
The structure of the
VC++ now has two modes: Native mode where it generates native machine binaries and uses standard API, and Managed mode, where it generates code and API designed to run in the
C# is Java. What else is there to say. It has a few more bells but that's it.
VB has been really ripped apart. Most of the data types are changed, restricted or gone. No more variants. Arrays are always zero based, always dynamic. Declaration, scope and instantiation all behave exactly like a Java environment now. There's threading now and better Try/Catch exception handeling.
I think it was a BIG MISTAKE to rip VB apart to make it more java like. Sure, you get threading and some other nice things, but at the expense of a lot of things that VB 6 and earlier could do before but can't anymore. Porting old code wil be a nightmare at best, impossible at worst. Most existing VB applications will need to be majorly overhauled to just compile in VB.NET.
They should have left VB mostly the way it was. It was designed for entry to mid level RAD and it worked best that way. They could make C# the Java killer, web development language and maybe keep what they did with VC++. Instead they tried to drag the large base of VB programmers into their
Yes,
MS could at least have redesigned it a bit to clean up some java mistakes. It looks like they copied the Java design so completely, they took it mistakes and all. So much for "Innovation".
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
here
here
here
It's 10 PM. Do you know if you're un-American?
When Java was first introduced by Sun, Microsoft understandably saw it as a threat, because it suggested a network architecture where Java servers (most all of them surely running Solaris) would distribute executable content to clients running any platform at all, including but not limited to Windows. Microsoft understood that to allow this would be to allow Sun control over the server realm, while they would have at most a (perhaps considerable) slice of the client realm. They understood that, in a highly networked world, having control only over the client was irrelevant, especially considering that the distribution executables were not limited to their client.
Now, five or ten years later, Microsoft is finally reaching the position that Sun was in back then, in that they finally have a more or less respectable server OS, and can finally begin the move to a more server-centric network architecture. Now, like Sun with Java, they are able to create a scenario in which they can control the servers and thus the rules of the game. Programs running off .NET servers may well be able to run on other platforms (e.g. a Linux version might not be out of the question, and Mac support seems pretty likely to me; the fact that they happen to control the most common client platform is just icing on the cake for them now), but they'll control the market and make their money off the server.
This is why they were willing to settle with Sun on pretty unfavorable terms, and this is why the outcome of the antitrust case may become at least partially irrelevant. Microsoft has adopted the tactics of their enemy, and are using those tactics in an attempt to win the next battle, as they choose for it to be fought.
DO NOT LEAVE IT IS NOT REAL
I've been trying out .NET in two projects for the last couple of months (using beta1).
There is a lot of stuff here that we've already got with servlets and other non-MS technology, but MS as usual packs it with a quite good IDE and quite some code is generated for you (For the purists among us: this is optional).
A very promising part of it all is ASP.NET (formerly ASP+) which has 'server-based GUI-elements'. This is really just a framework handling programmatic manipulation of forms, listboxes etc so you're finally not having to do Print "$e"; and so on. It gets especially handy handling tables listing data with alternating colors and such.
I just couldn't bring myself to touch the darn VBScript or JScript in ASP so the new language C# (almost like Java - but alas, an all new object model to learn) was really what made ASP.NET attractive to me at all.
"There is no substitute for thinking" - Bjarne Stroustrup
Does ".net" sound like "java"?
Obviously not. Try saying them both out loud in quick succession and you should be able to hear the difference.
Next question...?
--
http://www.gimbo.org.uk/
Ok, I will take your bait. I went to DICE.COM and did searches for Oregon (where I am) unrestricted hire-type. I searched for the words "java", "J++", "C#", "windows", and "unix".... Wonder what I found?
documents that say "J++": 13
of those:
# that say "unix": 7
# that say "windows": 3
documents that say "C#": unknown. Dice not setup to handle that.
documents that say "java": 372
of those:
# that say "windows": 102
# that say "unix": 188
# that say "windows" AND "unix": 77
# that DO NOT say "windows": 270
# that DO NOT say "unix": 184
# that DO NOT say "windows" OR "unix": 159
documents that mention "unix": 480
of those:
# that say "windows": 156
# that DO NOT mention "windows": 324
# that say "java": 188
# that say "windows" AND "java": 77
documents that mention "windows": 365
of those:
# that say "unix": 156
# that DO NOT mention "unix": 209
# that say "java": 102
# that say "unix" AND "java": 77
So, now for all of those who keep going off about M$ implementations, or M$ having 85% of the market share -- trying checking the market sometime instead of believing M$ propaganda.
http://www.google.com/profiles/malachid
But it's done the Microsoft way. Look at it from Microsoft's perspective to see the differences.
Before, MS controlled the source layer. (C, C++, VB) Source was compiled to an object layer that was defined by the CPU (not MS).
Now, Microsoft inserts MSIL, a meta-object layer. MSIL is owned and controlled by Microsoft. They create momentum by providing 27 languages that all compile to MSIL. (How many of those 27 MSIL shells will be updated a year from now to support .NET 2.0?) Trying to integrate non-MSIL code with MSIL code will be a new hurdle developers will have to face, and in most cases, won't be cost justified. To succeed, third party tools will need to directly support MSIL,
Sun did the same thing by creating a meta-layer of Java .class files, but today there is a Java engine for most platforms. Do you expect the same level of support from Microsoft?
The key for me will be to see how third party vendors are allowed to link with MSIL projects. Watch Microsoft and see what methods they use to lock developers to their platform.
I predict Microsoft will protect their Windows investment by the usual methods. First they will only support their own operating systems. Then they will provide broken support for other platforms where it is easier to migrate to Windows than stay on non-Microsoft platform.
I hope I'm wrong, but just in case I've just finished pulling the last com.ms package out of my J++ project and am ready to migrate back to an open JVM. I'd rather not take advantage of Micorosoft's tools that allow me to easily port my Java code to C#.
It will make your wife look better (and thinner), the flowers smell more fragrant, your black and white tv will become color and HD TV cable ready.
.NET brings easy 1-2-3 COM programming to you in the form of the all powerful and easy (as in your first girlfriend) VB Script.
Don't really understand Java? The ATL Dispinterface got you down? Don't worry, because
10 print "I rule d00d"
20 goto 10
I wrote this a couple of weeks ago about the .NET CLR (Common Language Runtime), which is the virtual machine thing:
This is the main bit I'm interested in. It's quite a daring move, since what
they've done is made a virtual machine like Java's, but completely opened
the specs and submitted it for standardisation, which is more than Sun ever
did with Java. It's bizarre, since virtual machines promote
cross-platformness, which is the *last* thing you'd expect MS to be
interested in, especially given their track record. What it looks like is,
firstly a great way to counter the DoJ (and to survive a company split, if
the worst comes to the worst), but secondly it implies that MS have so much
faith in their ability to write fast VMs (which, given the blinding MS Java
VM, is not unfounded) and the Win2K kernel family as a host OS that they're
prepared to take the challenge repeatedly thrown at them: to level the
playing field somewhat. Plus, it makes Win32 coding a hell of a lot easier by abandoning the hell that is the existing Win32 API and MFC for something much cleaner,
and you don't have to abandon whichever language you're coding in already,
since the Common Language Runtime will run all of them, eventually.
Basically, they're going to try and do a Java-like thing better than Java.
And I wouldn't be surprised if they tried to swallow Java whole in the
process (e.g. making the CLR run Java bytecode, or a Java language -> CLR
compiler)
Oh yeah, and there's all the XML stuff and
low-level-services-provided-over-the-net thing, which is quite interesting.
And Microsoft being the ultimate repository of all your personal data, which
is obviously petrifying.
Since then, I've realised a couple of other things:
1) It's a great way for MS to move off Intel-centricity, which isn't so important on the desktop (though it'd help with porting stuff to the Mac) but is one of the main things killing WinCE development, since every time you write an app you have to compile it for every processor that WinCE runs on. And since MS is moving more and more into the embedded market, this is obviously vital.
2) Looks like I was right on the Java-swallowing:
http://www.theregister.co.uk/content/4/16392.html
IMHO (after going to a MS /NET Developers conference) C# is like Java. .NET (which is not C#) is a general vision of XML based services on the Internet - including support in a wide variety of DB and server products for XML and related protocols (Soap et al).
http://www.acooke.org
If .NET handles the 30 odd languages they claim to support, with easy extendability for more.
If they make .NET a standard, allow others to freely innovate on it (with none of the licensing restrictions Sun likes to impose to keep companies like IBM in line).
If they can make sure .NET really is vendor neutral, so shipping the .NET foundation is not like shipping the JVM which is little more than a commercial Sun product.
Then HECK YEAH, I'll take an open, free, extendible, cross-platform platform any day, especially if it ships with millions of Windows machines, has solid development tools, and is available on the platforms I like to use such as the Debian standard install (not a non-free directory).
I think from a technical perspective the .NET platform fulfiles the promise of Java, and with things like SOAP Microsoft may indeed get the benefits of going truly open with their platform. That promise is still as exciting as when Sun made it so long ago. Finally, I can see no reason that .NET won't support Java, and C# offers a reasonable alternative from a techinical perspective.
"In essense, while Microsoft advocates the ability to run diverse code on their platform, Sun advocates writing standard code for all platforms."
The question seems to be how important is that whole "diverse code" thing? I mean, do I want a team of a dozen Java programmers? Or do I want 2 Prolog guys, 4 C++ guys, an APL geek... How do I crosstrain them? When people say "the best language for the task at hand" do they consider the factor of having people crosstrained in that language? Great. You know Smalltalk inside and out. You can make it run 100x faster than C++. So I implement my UI in Smalltalk. Now you go on vacation, and it crashes. I'm screwed. I can't train every programmer in every language.
www.HearMySoulSpeak.com
...if they have automated products that can convert an existing Java project to .NET/C# project.
Grabel's Law
If Microsoft can deliver on a *cross-platform* solution.
If .NET handles the 30 odd languages they claim to support, with easy extendability for more.
See Microsoft's use of future tense and this list of JVM languages.
If they make .NET a standard, ...
What motivation does MS have to lose control of their market? I don't have links readily available, but all I have heard is of MS planning to take the C# specification to ISO, which has nothing to do with standardizing their whole platform. Even if they did, any takers on rewriting Win32? Ask the WINE people how easy it is.
If they can make sure .NET really is vendor neutral, so shipping the .NET foundation is not like shipping the JVM which is little more than a commercial Sun product.
And .NET won't be a commercial MS product. I have not seen MS even try to claim that anything they produce for .NET won't be owned by them. Read carefully.
Then HECK YEAH, I'll take an open, free, extendible, cross-platform platform any day, especially if it ships with millions of Windows machines...
Aha. Windows machines. That's right. .NET is supported on Windows machines. It should make doing Windows network development nicer, with a compact version in various devices acting like embedded Java. MS supports Windows. They make Windows. What motive do they have for changing that? When did they say they were changing that?
I think from a technical perspective the .NET platform...
Try reading the technical documents. Here's one on SOAP. Read it. It's not that exciting. It specifies that you can use normal XML Schemas with a few extra rules and an envelope that mimics HTTP functionality.
You can do little new with SOAP and .NET from a non-Windows computer that you couldn't do with normal HTTP and CGI. SOAP provides almost nothing on top of standard XML. There's nothing new under the sun.
If you want open and exciting, try Linux or FreeBSD. If you want cross-platform software, try something open like C, Perl, Python, PHP, Ruby, or anything else on the list. They also interoperate just fine. Unix had cross-language interoperation working in the 70s. It's called pipes, and it's at least faster than SOAP.
- Tom
- Tom
"O, to grace how great a debtor daily I'm constrained to be."
As a beta tester, I think I have a bit of authority on the subject :)
.NET more successful than JAVA, such as:
.NET platform doesn't limit you in language choice... you can use C#, VB, Perl, or any one of the other 15 or so supported languages. Plus, the architecture is extensible, so support for additional languages can be plugged into Visual Studio with ease. I know the Java bytecode isn't tied to Java the language, but realistically, that's the way Sun as limited it.
.NET ran as an ASP service on a test website for 52 days before the auto-detection kicked in and spawned a new process. Since that time it ran up until beta 1, at which time it was shut down to update it. One such test website is Ibuyspy.com
They are doing a number of things that will make
1. Any Language. The
2. Native execution. There are two options for compilation. The first, JIT, would be used on servers and such where users upload scripts and similar items. On first run, they are compiled into NATIVE x86 code (assuming you are on an x86 processor). The other option is mostly for desktop apps: when the app is first installed, the built-in MSIL compiler reads the MSIL on the CD and writes native x86 code that is fully optimized for the processor on which you are installing... so years down the road when the Pentium-6 is out, and you install that program, it will be fully optimized for the Pentium-6.
3. Cross-platform. Let's just say that more than Win32, MacOS, and WinCE are on the roadmap for the Common Language Runtime. More will be revealed with this in time.
4. Security. Native x86 code is unverifiable.... you cannot guarantee that the code won't do something stupid and overwrite its own memory or deref an invalid pointer. But the MSIL is verifiable.... the system can cast all the calls it makes against its security context. This allows apps downloaded off the web to be executed, knowing that even though they are compiled down to native code from MSIL, they aren't going to do anything funky behind your back. It also gives admins in a corporation complete control. There is a lot to the security subsystem, so I suggest you read up on it for yourself.
5. ASP Enhancements: First of all, IIS/ASP.NET will monitor all the processes and components... if there is a memory or resource leak detected (or a timer expires), it will spawn a new process and start funneling all new sessions to that process... when the last session to the old process closes, it will be terminated and the resources reclaimed.
6. More on ASP: Secondly, when you write an ASP app from Visual Studio, you design the forms and such in a RAD environment using an event-driven model (think VB). However, the server automatically cast the forms down to the highest HTML that the browser supports.... visit the page with IE 6 and you won't be able to tell the difference between it and a regular app. Visit it with Netscape 3, and you'll see a regular static page. The difference here is that the programmer doesn't have to worry about it.
7. Distribution. With desktop apps, an x-copy will actually suffice as the install routine. All apps install their custom components into their own dirs. The system repository tracks all versions of all DLLS installed, and automatically produces the proper version for the proper app at launch time. No more DLL hell.
These are just some of the improvements. As far as stability goes, the pre-alpha version of
For those who automatically blast it just because it is from Microsoft, get ready to be steamrolled just like everyone else was when MS took over the world with Win3.1/95. For the rest of you, read up on the MS documents. There is a lot of good stuff in there.
-
The IHA Forums
Natural != (nontoxic || beneficial)
Java isn't slow at all. In fact, in terms of raw execution speed, it's probably one of the fastest object-oriented languages next to C++.
What is slow about Java is its startup. And that's because you are loading a fresh JVM everytime you start up a Java application. If you did the equivalent with C/C++, you'd have to load many megabytes of libraries before you could start any C/C++ program, something that would make things like starting up any GUI app crawl to a halt. If you use Java the way those kinds of environments are supposed to be used, start up a JVM and do all your work inside that, it is very fast. Compilations fly, windows pop up instantaneously, etc.
But since people aren't going to change their work practices overnight, Sun is working on addressing the startup speed by introducing something equivalent to precompiled, shared libraries for C++. That way, you should be able to start up JVMs very quickly.
Incidentally, if your only experience with Java is through Netscape applets in Netscape 4, the JVM that comes with Netscape 4 is outdated and very slow. Furthermore, it takes forever to start up even compared to the unenhanced modern JVMs. Under Galeon or other browsers, applets start up quite quickly already.
Java's language design is very conservative, and it's a lot easier to compile into efficient code than, say, Perl or Python (when Perl or Python beat Java in benchmarks, it's because of highly optimized library code in those languages, not because the languages themselves are compiled well). In fact, because Java's language design is so conservative, it is actually not all that much easier to write Java programs than, say, C++; Python, Perl, and Smalltalk are certainly a lot more convenient. Java's advantage over C++ isn't convenience, it's safety, simplicity, and runtime support.
What is really big and complex in Java is its GUI and "enterprise" libraries, and other languages should be so lucky. Swing is still by far the best designed object-oriented GUI toolkit I have ever used (and I have used quite a few). Java's database libraries are great, and so are its support for persistence and distributed computing.