Slashdot Mirror
Java vs .NET
CHaN_316 writes "Yahoo is running a story called 'Is Java Finished?' It provides a brief overview of the strengths and weaknesses of J2EE and contrasts them with .NET. Classic arguments are brought up like Java being great for portability while .NET ties you down to Microsoft products, etc. It's interesting that they bring up the Java Community Process, and how it is a rather slow moving procedure that is causing Java to become stagnant."
Dot Net doesn't look like a developer panacea just yet. If Sun keeps the enhancements coming and works to bring the development environment up to Visual Studio's standards (Yes, VS has its problems, but it has a lot of unique tools, like compile-and-continue, which save hours!), Java may well survive.
Dot Net is also anything but small. It's possible to create ROMmable Java applications in just a couple megs of flash memory. On the other hand, there's no such thing as embedded dot Net just yet. And if they continue with the execution model they've currently got, any piece of code is going to net a ROM many times larger than what's possible with Java. Either way, I'll want $699 for my fp, beeyotch.
The ".Net only works on Microsoft" is more than just a classic arguement. In fact, I think it's the most important factor to take into account.
.Net will never take off. After all, it hasn't during the 3 years its been out.
If I want to make some simple embedded device, if I have to option to use Java instead of having to license Windows CE for my product, why would I ever choose MS over Java?
Having worked with both Java and .NET, I would say that things like C#'s foreach statement make for easier and cleaner code, but Java 1.5 will leapfrog C# when it introduces generics along with its own version of foreach, and other timesaving features. Java's big failing, IMHO, is Swing. It is too big and too clunky, Java is crying out for a stripped down GUI library that is part of the API spec that will be as easy to work wit
Just raise the taxes on crack.
.NET ? Blowing J2EE out of the water ?
.NET ?
Are you serious ? Then:
Where is the appserver that runs
Can you cluster that appserver like J2EE-appservers ?
From the article:
The slowness of the JCP holds up the creation of additional standards and services, he pointed out. In addition, standards proposals aimed at portability -- Java's strong suit -- are also stagnant.... "In the meantime, people want faster, easier development."
Golly, I like slow, careful, and secure development of my enterprise backbone software. People may want faster inclusion of features, but they need stability and security.
The latest flashy feature doesn't do shit if your enterprise backbone is crashing or being hacked into oblivion.
You would think that a language or API that doesn't change every day would be praised with words such as "standardized" "stable" and "established".
But in Bizarro World (where we all are apparently living), we criticize it as "stagnant" and "slow moving".
Compare with the OpenGL/Direct3D discussions.
Carpenters don't buy from hammer companies that change their hammers every "release".
Any article that asks that question is automatically crap. Period. End of discussion.
Business isn't willing to pay for products, innovation and careers, so we get brands, mortgage commercials and layoffs.
Java originally promised to become a small, universal client-side platform for the delivery of applications to clients over the web. Java has almost completely failed in that mission: Flash is far more widely used, no browsers ship with the latest version of Java, and even if you stick to Java 1.1, there are numerous compatibility problems.
.NET will continue to exist in that space as well and probably take away market share. And because Sun's restrictive licenses on both the implementation and the specification of Java, I suspect Java has seen its best days in the open source world.
.NET, .NET is simply more of what Microsoft has always given us: a proprietary platform completely controlled by Microsoft. It's not primarily an alternative to Java, it's simply what Microsoft programmers will move to from MFC and Win32. Thankfully, it's at least a lot cleaner than Microsoft's previous APIs and systems.
What Java has become instead is a semi-open server-side platform. It's quite successful at that, but it is only one of many platforms in that space. PHP, Perl, Python, and
Now, about
So, Java has failed to become what it originally promised to become, but it is a fairly successful platform that won't disappear overnight. But Sun's dreams of industry domination are pipe dreams. Java could have become much bigger and more important than it has become, but Sun screwed up (and is continuing to screw up).
No Java has already been shoehorned in a long time ago. You just weren't paying attention. Also, just because the JCP goes slow, doesn't mean Java is stagnant. It means the JCP is slow. Trying look at jakarta.apache.org, and then tell me all this bs about stagnation and ill-suited purpose.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
People that argue that Java is stagnant mean that there are things the language needs, but it is taking too long to get them.
Sarcasm and hyperbole are the final refuges for weak minds
It's not up to developers. Regardless of developer preferences or platform capabilities, when the right sales people talk to the right managers, the
Java's philosophy of development is to expose low-level system interfaces to give developers greater control. Microsoft simplifies the development process; the developer has less control -- but the tools are easier to use.
.NET and Java and I've found Java's toolset to be much easier to use. This is simply due to the fact that there are many more vendors (open-source and commercial) that provide Java products. I can pick and choose which tools fit the particular project that I'm working on, and those tools will also run on any platform that Java runs on, so I'm not locked into a particular operating system while I'm doing development. I can decide to work in Linux one day and Windows the next, and use the exact same toolset for both.
.NET is simpler. But in that case I'll take complicated over simple any day of the week.
Says who?
I've developed applications in both
So I guess if your definition of simple is "you will use this tool and like it", then yeah,
Can't say that it will make a difference to me since I guess I'm the only person in the world who knows what platform they are devloping for up front.
While the rest of us aren't willing to make that restriction on ourselves.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
There are some good Java IDEs, no doubt, but none of them can touch Visual Studio for, well, any single thing you could possibly want to do with an IDE.
If you do any Java development try IntelliJ Idea.
Then come back and try saying that again.
-... ---
Um, excuse me, but it's very possible to create full-featured applications in assembly in just a couple of kB of flash memory. And in case you hate assembly, you can do the same thing in C++ for around 500 kB, and it will run faster than Java. Remember, embedded devices don't have the screaming fast processors that are needed to make Java appear fast. And they're not likely to have the few hundred megs of RAM that a JVM seems to think it needs, either.
Yeah, Java's nice - for the web. But given that people hate to wait on embedded devices, I can see why it hasn't been widely adopted. And given that embedded devices are often used for critical infrastructure (i.e. utilities, aircraft, nuclear plants, etc...), I'm not sure if I'd trust someone who can't master assembly to write code that controlled a something that could get me killed if an unexpected Out of Memory Exception was raised.
...those who are dealing with business realities and not philosophical preferences.
I'm sick of that oft-repeated lie. BOTH the alleged "realists" and the "idealists" are actually realists. The difference is how far ahead they are looking. If you only care about the next year or so, you don't mind supporting only Microsoft. If you care about 10 years down the road, you do. BOTH camps are being realists, but they don't have the same goals in mind. One just wants to finish his current project, while the other will sacrifice current comfort to help ensure that there's still more than one computer company 10 years down the road.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
The question shouldn't be "Should I be develping this on .net or J2EE?" It should be "Should I be developing this on the web at all?"
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Except that assembly and C++ are not binary compatible across multiple embedded devices. Take cell phones for example Your choices are:
1. Port and compile a version of your program for every cell phone in existence (quite a few platforms).
2. Write a Java MIDP application that works on all MIDP enabled phones.
Hmm.... which to choose, which to choose...
Javascript + Nintendo DSi = DSiCade
As someone has mysteriously marked the parent as "interesting" it might be worthwhile to provoke a genuinely interesting debate below it so that readers are not too disappointed.
The parent insists that no Java IDE "can touch" VS for "any single thing you could possibly want to do", but a moment later admits that "VS.NET doesn't have as robust a feature set as some Java IDEs".
Features like refactoring, perhaps, as found on the free Eclipse IDE, or the modestly priced IDEA?
Or, looking a bit further afield, we could ask how one might develop a complete workflow system in VS, as you can in WebLogic Workshop?
My clients do these things all the time, but VS has a long way to go to offer a competitive alternative to the Java tools available now.
This is stupid. I make money writing software that is for sale. Openness does NOT sell software to our clients. Good software, and fair prices, sell software. Openness would actually be a major setback to writing good software.
Why? Because we would need to massively increase our testing staff, to test on a good number of different machines to ensure compatibility. Because we would have to train them. Because even among VIRTUAL machines, and systems that obey standards or even run the same exact code, there are differences which can easily become dealbreakers.
As an example: we designed our application from the ground up to allow the use of multiple database systems. Heavy abstraction, only SQL-97 compatible statements, no system specific datatypes, etc. We closely followed standards to ensure compatibility. Still, when it came time to test the first database, it didn't work. The compatibility layer was never fully implemented by the new server, as a result of a feud with the first server. We had to rework the database layer completely, and it set us back at least three months.
If we had just said "fuck agility," and designed for one system (and rigidly sold THAT system) we would have saved a lot of time and money -- enough money to discount our software for those people who needed to invest in the more costly database. We could have spent that time making great new features. That's what matters to our clients, none of whom have ever not will ever use Linux or any machine not running an x86 chip. There's too much investment in legacy software requiring archaic things like DOS, floppy diskettes, and daisy wheel parellel port printers.
Openness and portability are at best liberal afterthoughts, and are by no means "the most important things" outside of your junior year Operating Systems class. What matters is cost effectiveness. If your market is not already locked in to wintel, then by all means use Java, chances are you'll recoup the extra testing effort with your first big mainframe sale. Ours was so locked. Writing in Java would have been a foolish waste of effort.
Hey freaks: now you're ju
And if for some reason we want a different platform (which we don't and won't), we'll have to recompile. Oh, the horror.
And that's why we have so many
"just recompile" is a great solution IF you didn't use a development model that locks you in. I use "just recompile" all the time on C and C++ programs.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Yeah, except that some people actually just, *gasp*, *like* to program in Java. It provides a nice, strongly typed, compiled, object oriented language (a niche none of those scripting languages fill) that's available almost anywhere while being FAR nicer to develop in than either C (too low-level and error-prone) or C++ (to damned friggin' ugly).
Moreover, Java provides a massive class library which makes it easy to write new applications without having to reinvent the wheel every time (and yes, I know about the STL, but it's still not entirely standard, it creates bloody HUGE application binaries, it takes FOREVER to compile, it's *impossible* to debug compile errors, and it isn't even as extensive as the Java APIs!)
Now, I would agree that Java is pretty well toast on the desktop, barring a toolkit revolution. I certainly wouldn't write an app using Swing. However, for other types of applications (like, say, Freenet), it can do an excellent job. And if you go with SWT, you can write some pretty damn nice GUI apps (just look at Eclipse, which is written entirely in Java).
But to dismiss Java out of hand because it doesn't mesh with your and some other zealots ideals is pretty narrow minded. Personally, I don't care if my app is somehow "tied" to Sun. As long as I can release my source code, who gives a damn if it runs on a proprietary substrate. That certainly didn't bother the KDE guys (or their users) back when Qt was non-free. Sure, there were people who complained, but there were also plenty of people who didn't give a damn (myself included).
Conversely, the ability to port easily (much easier in java than .net) to other platforms becomes a selling point down the road... but just becaue the abiilty/openness exists, doesn't mean you have to buy into it.
Make sure everyone's vote counts: Verified Voting
What the fuck are you talking about?
.NET, not because the language "has no future," something our clients couldn't care less about anyway, but because the application is a clusterfuck which needs to be updated. Writing it in a faster, safer language like VB.NET is not be considered a liability by anyone in this company. In fact, the eventual rewrite has been used to tease the development staff..."After this, you guys can relax and do that rewrite!"
Since 2002 when Visual Studio.NET "dropped support" for VB6, there have been several service pack releases for VB6. Our company, which has a massive set of applications written in VB6, has released an update every month for our VB customers, written in VB.
We will eventually be rewriting in in
A lot of people complained about having to essentially rewrite all their Java 1 applications when Java 2 came out because 1 had no future. Those people are what we call LAZY.
Hey freaks: now you're ju
Also it means more stability in specs. Writing specs takes some time but it pays off when you need to implement the spec.
"I think this line is mostly filler"
Let's say I have a class in package A and I want to move it to package B (in dotNet parlance, packages are namespaces). In dotNet, I'd have to personally touch every piece of code accessing that class and redo the import statements (dotNet: using statements) to reflect the change. Same goes for method name changes, public member changes, method signatures (parameter order, adding parameters, etc.), etc.
Also, the good refactoring IDEs provide a lot of extras like generation of getters/setters (dotNet: properties) (also referred to as encapsulation), extracting interfaces and/or superclasses, replace inheritance with delegation, replace constructor with factory method, make method static, etc., etc., etc.
Note that most of the above refactorings not only change the class in question, but also all accessing classes and methods. This sometimes means you can make a significant change to a heavily used method or class and do NO WORK to the rest of you classes.
If you are interested in the power of IDE refactoring, check out the IDEA refactoring page. Here is a screenshot of the refactoring menu.
In short, refactoring is REALLY powerful and very, very useful. If you are saying otherwise, you probably haven't used it. Also, it should be noted that several companies are making refactoring plug-ins for Visual Studio. Obviously SOME people don't think that Visual Studio's features render refactoring "unnecessary" or a "waste of time." Myself included. (I'm a Java junky programming in a dotNet environment.)
Taft
>> However, C# has a lot of other advantages over Java. C# can make use of pointers. Java has no option on parameter passing - Objects are passed by reference, value types are passed by value. While C# has the same limit on objects, you are able to use pointers and it also supports boxing. C# supports operator overloading as well
You mention three advantages there:
- pointer support
- boxing
- operator overloading
I'm sorry, but in the average commercial environment, churning out business logic to meet changing business requirements under tight deadlines, two of those three are very very bad.
Boxing is good. That's probably why it's in Java 1.5. I'd have liked to see it in 1.1, but that's another discussion.
Pointer handling: I've written code doing direct memory access via pointers. I've also written code in Java (and thus not had access to pointers). The Java code has been at least as easy to write, had far fewer bugs (invalid pointers? memory leaks? not in my code), and (most importantly) been immeasurably easier to maintain. You might have been programming for 20 years and never have a problem with pointers; most developers have been programming for 2-3 years, don't have a sodding clue about pointers, and will and do screw it up. Quite frankly, pointers are evil and unnecessary and if I do use C# in the future (as is likely) I'll be insisting on coding guidelines that preclude their use.
As for operator overloading: It's one of those things that makes C++ code so bloody impossible to maintain. Bit of code read x += y. Except it's doing a binary concatenation, or advancing the pointer reference, or updating Z instead. Because some idiot has overridden +=.
I appreciate that there are situations where operator overloading is useful, even some where it's sensible. Unfortunately, going back to the average developer: They don't know when to use these things, and even if they do, they often don't know how.
I love Java not because I'm a crap programmer (although I wont deny that) but because it makes my life much much easier. I can write code quicker, more efficiently, and more robustly. I can maintain code extremely easily, as the 'gotchas' that exist in many languages just aren't there in Java. And my boss loves the fact that he's getting new functionality so much quicker, because the whole team isn't spending their lives debugging a complex overloaded operator that's invalidated a pointer.
I'm not saying C# is a bad language. I am saying that operator overloading and direct memory access (through pointers) is unnecessary and evil in the average corporate development environment. And that's the target environment for
~Cederic
Hmmm... a few pages above there's a post consisting of the two phrases "You are an idiot" and "There is no IDE that comes even close to Visual Studio.NET" that's now Insightful.
And now here I'm obliged to repeat someone's useful response (that wasn't modded up) to an ignorant assertion (that was).
The practice of refactoring is well-established and reflects changes to the naming or structuring of the code that have occurred since it was created, so your comments about the initial organization of code are irrelevant. Apparently your beloved VS.Net is likely to offer some refactoring capability in a future release, which acknowleges the importance of this feature but puts it approximately 2.5 years behind Eclipse and IDEA.
A workflow system consists of process definitions with process steps that involve conventional programming, therefore if I'm developing a workflow system, I'm also doing conventional programming. An IDE allows me to deal with these aspects in one environment (hence "Integrated"), just as VS.NET allows me to develop GUI layouts and conventional programming in one environment. (Or are you suggesting that the GUI designer in VS should be a separate system?)
I fail to see the relevance of standalone diagramming tools in this context since their purpose is to produce diagrams (for people) rather than code (for computers) - something you are free to do regardless of your IDE. However, since you bring up the subject, I should point out that in Workshop the workflow diagrams ARE integrated and correspond exactly (via 2-way update) with the visible program code. Again, such features are light-years ahead of anything in VS.
I'm confused. You first deride my comment, and then you appear to agree with it.
My point is that by only looking at a language's version-1.0-time-to-market qualities, tradeoffs must be made. In the case of VB, the tradeoff is that VB is a closely guarded language by a single vendor, rather than the classical academically defined languages like C, C++, Fortran, etc. If Visual C++ goes away, there are other vendors who produce C++ compilers. If Microsoft stops producing VB compilers, there is no one to turn to. Since VB.Net is the next version of VB, and it requires a practical rewrite for large applications, then the previous language known as VB is dead, for all practical purposes. Few to no new applications will be written with the old language.
I don't care how bad your applications are written, odds are your mananagement would not rewrite the applications unless they were forced to by outside forces, because, as you said, the paying customers don't care about languages, they just want feature Y in product Z and they want it now. In this case, the outside force is the vendor who has essentially stopped advancing the compiler for the langauge your apps are written with, and you don't have another VB vendor to turn to.
And as far as developers enjoying the rewrite; beware of what you wish for. We are going through the same thing, and it has been almost two years of pain, beauracracy, and political wrangling. The Second System effect can easily take hold, since people are so afraid of making the mistakes of the old system that they overthink and over-engineer the new system until it collapses under its own weight.
Well, I suggest you actually read the licenses you agree to when you download Java and the Java specification from Sun. Both the language and its implementations are tightly controled, in a way that practically no other language or platform is.
In that you can't create an implementation and call it "Java" without Sun giving you the okay. BFD. I can understand why Sun would do this... look what happened with Microsoft and their "implementation" of Java. That doesn't stop anyone from creating their own, compatible language, VM, etc, and calling it Espresso or something. Again, gcj, GNU classpath, etc, proves this to be the case.
People can't. Read the licenses.
Tell that to the FSF... not to mention IBM.
You are damned right it's hard. But it's not technically hard, it's "hard" in the same sense that a Windows clone like Wine is hard: Java is a platform controled by a consortium, driven in such a way that people can't successfully create third party implementations.
No, WINE is hard because the APIs are a moving target and most of them are undocumented. Moreover, WINE is hard because the Win32 APIs are NOT controlled by a consortium! They're controlled by a single entity, and hence are subject to change, revision, addition, etc, without anyone knowing about it, making it even harder to write a compatible version.
Java, OTOH, is highly stable and moves slowly (as has been noted by many others in the comments for this article) which in fact makes it *easier* to create competing versions, since you don't have a rapidly changing platform to remain compatible with.
What planet are you from? Maybe there is some form of "JVM" on their machines, but it's completely unpredictable what version it is (1.1? Microsoft? 1.3? 1.4?). I used to be able to use Java applets on my site (for SSH and other services), but that's become pretty much pointless these days.
Okay, let me revise my statement a little. Most people who use free/OSS platforms have a reasonably modern JDK installed. OTOH, you're absolutely right, if you're attempting to target Windows (although you can blame Microsoft for that). If you can name another language that approaches Java's install base (particularly amongst OSS folks) but meets the same needs, I might conceed the point.
I'd select Java for cross-platform development as well. But most of my development is not cross-platform.
So then who cares about Java and it's platform support? That was, after all, one of your objections regarding Java (and, no, I highly doubt Sun would drop support for either Linux or Windows).
The KDE developers were headed for a legal disaster: they had created a desktop whose license was incompatible with the toolkit they were using. If Troll Tech hadn't changed their license to dual-license, KDE would have been dead, in particular because it's not clear they could have legally created an open-source version of Qt. The KDE project was oblivious and ignorant of the license problems they were getting themselves into. And so are many open source Java developers.
Heh, please... those licensing issues were purely philosophical. It certainly didn't stop MANY people from using the platform... after all, those issues were well known right from the beginning. As a result, I *highly* doubt the project would have died. Hell, they could have just changed to a BSD license and been done with it. *shrug*
However, that's completely irrelevant. Why? Because there are no "licensing problems" with Java. This is just something you seem to have invented! I can create all the Java apps I like... Sun's license on the JDK and their control of it plays no part in the license I choose for my software. Basically, it's a *completely* different issue. In this case, my project can be as "free" as I want... it's simply the platform which (arguably) isn't.
Now, to make the comparison more apt, let's say TrollTech's license was compatible, but