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.
It's not up to developers. Regardless of developer preferences or platform capabilities, when the right sales people talk to the right managers, the
...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.
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.