Java vs .NET 686
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."
Java's not exactly pining for the fields just now (Score:5, Insightful)
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.
Isn't that pining for the fjords? Anyway... (Score:5, Funny)
Re:Isn't that pining for the fjords? Anyway... (Score:5, Interesting)
VB is not as much a programming language that became a GUI, but a prototyping tool that became a programming language. The move to VB.NET has taken away all the language simplicity making it a fully fledged language, but made it difficult enough to negate its benefits over other products that fall within its same niche. I do my quick and dirty GUI's in Jbuilder now. If I have to use a fully fledged language, I would rather use a portable one.
Re:Java's not exactly pining for the fields just n (Score:3, Funny)
Not up to the developers... (Score:5, Insightful)
It's not up to developers. Regardless of developer preferences or platform capabilities, when the right sales people talk to the right managers, the
Re:Not up to the developers... (Score:5, Interesting)
Re:Java's not exactly pining for the fields just n (Score:3, Informative)
Re:Java's not exactly pining for the fields just n (Score:3, Insightful)
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
Re:Java's not exactly pining for the fields just n (Score:5, Insightful)
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...
Re:Java's not exactly pining for the fields just n (Score:4, Interesting)
http://kylecordes.com/story-260-java-net-talk.h
One thing with the SD Times identified as a source of trouble (the size of the included libraries), I identified as a strength:
This is particularly exacerbated in some development shops where extensive format decision and permission processes are needed to make any third party tool purchase (or free software adoption).
Re:Java's not exactly pining for the fields just n (Score:3, Interesting)
Check out Eclipse [eclipse.org] for Java development. The workspace/perspective paradigm will take a day or two to get used to (plus the different key bindings), but this is a really nice IDE. I'll wager that MSFT will be copying the "lightbulb" feature of Eclipse that shows
no embeddable J2EE either (Score:3, Insightful)
The comparison must be between .Net and J2EE, while J2ME and even J2SE are seriously lacking in component architecture and other features comparing to both .Net and J2EE.
So, once we make a comparison correctly (J2EE vs .Net) we can state: there is no such thing as embeddable J2EE just yet, while there is somet
Re:Java's not exactly pining for the fields just n (Score:4, Insightful)
Re:Java's not exactly pining for the fields just n (Score:3, Insightful)
Re:Shoehorn (Score:3, Interesting)
I am currently developing in
I can't remember the last time I had to develop a client (not web) application that had to run on 2 or more platforms.
In all my years, no one has ever said to me "build me such and such and make sure it runs on unix and windows without recompilation".
However, I have been on many teams where
Re:Shoehorn (Score:4, Insightful)
While the rest of us aren't willing to make that restriction on ourselves.
Re:Shoehorn (Score:5, Insightful)
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.
Re:Shoehorn (Score:5, Interesting)
Re:Shoehorn (Score:3, Insightful)
Sure, generally you know your target platform. But sometimes you don't. Also, since the toolset between unix and windows is very different, it is sometimes far easier to develop on one than the other.
With Java, you develop on whichever platform makes it easy. You test and depl
Re:Shoehorn (Score:4, Interesting)
Re:Shoehorn (Score:3, Funny)
Well then, I support
Re:Java's not exactly pining for the fields just n (Score:5, Informative)
I think you might be mistaken here.
Before the language was called 'Java', it was called 'Oak'. It was a language for building embedded applications on smart consumer electronics. However, Oak was way ahead of its time in terms of product targeting.
Re:VS sucks (Score:4, Interesting)
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. From designing interfaces, to writing code, to generating code, to debugging code, to remote debugging, it's just awesome and completely customizable.
Maybe you just picked it up, said "Oh Microsoft, must be junk." You were wrong to do so; it's way better than VS 6. Maybe you saw the animated docking and said "Too pretty, must be junk." You're wrong again...that's the first thing I take out, but by and large it's not a whistles and bells IDE. Maybe you saw all the icons and thought, "Too visual, must be junk." You'd be wrong...everything you want to do in Studio.Net can be done without ever touching the designer, and in fact I don't have a single icon bar turned on in my IDE.
Compared to Sun's IDE, the awesome in its own right open source Netbeans, VS is much faster for compilation, has more accurate and immediate response from controls and object generation is more reliable. The tools are for the most part simpler while at the same time being more complete. They are easier to use and you can mess with the generated code without destroying the associated resources (for the most part). VS.NET doesn't have as robust a feature set as some Java IDEs, but it's got plenty and it all works.
Re:VS sucks (Score:4, Insightful)
If you do any Java development try IntelliJ Idea [intellij.com].
Then come back and try saying that again.
Re:VS sucks (Score:5, Insightful)
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 [eclipse.org] IDE, or the modestly priced IDEA [intellij.com]?
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 [bea.com]?
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.
Re:VS sucks (Score:3, Insightful)
You're complaining that VS.NET isn't as good an IDE because it doesn't offer a way to rewrite your code for you?
There's a lot of really nice ways to organize your
Secondly, if one were desinging a complete workflow system, one might think one would want to work in a system for designing such things, and not in ones' IDE. I mean, I d
Re:VS sucks (Score:5, Insightful)
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 [intellij.com]. Here is a screenshot [intellij.com] 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
Re:VS sucks (Score:4, Informative)
If I could mod you up, I would. Just today, I attempted to rename the project namespace for a .NET application. It took me about two hours to get everything fixed, the namespace is tied to the directory, and therefore references get hidden in various non-class files. The hidden references may not be necessary to straight programming, notepad/editplus style, but when they are wrong, they break the debugger in VS.NET.
If VS.NET had a good way to rename classes and namespaces, it would be a Godsend. Sometimes, you just realize that you were stupid in naming a class what you did, and that it would be so much more clear if it had a different name. I've worked with Eclipse refactoring, and I remember the first time... my jaw dropped, and I was like "This is fucking awesome!"
Refactoring is an excellent tool that should not be ignored, and is definitely not replaced by code outlining/regions. Those, OTOH, are really good for getting an overview of your code, and instant grokking after not touching for 5 months.
Re:VS sucks (Score:5, 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.
Re:VS sucks (Score:3, Insightful)
That's the problem here. VS might be better than most Java IDE's at most things, but that doesn't mean it's better than all Java IDE's at all things. If I want to develop servlets, I might want to use a different IDE than if I design applets.
Also, how much does VS cost? Netbeans: zero. Eclipse: zero. And if I want to pay some money there are java IDE's out there, and because they have to compete for my money they have greater incentive to p
Re:VS sucks (Score:3, Informative)
Re:VS sucks (Score:4, Insightful)
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.
Re:VS sucks (Score:4, Insightful)
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.
Re:VS sucks (Score:3, Insightful)
Hmmm... which is why many companies are having to essentially rewrite all their VB apps because their single-vendor locked-in language has no future. But hey, they were able to cut cost-to-market with VB5, so they saved a bundle, right?
Re:VS sucks (Score:4, Insightful)
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.
Re:VS sucks (Score:5, Insightful)
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.
Re:VS sucks (Score:4, Informative)
Also, it seems that your development strategy here was flawed. You write a whole compatibility layer before testing it at all? Why didn't you go through and write some test code and just make sure some things worked before doing the whole thing and finding you had a problem?
What Java brings you is the immense potential for agility. You don't have to plan for agility, it just comes with it. When you decide that you want to change platforms, make a few tweaks, do some intensive testing, and blammo, new platform. With
As for people being locked into wintel, as long as there are web browsers, there's no such thing as lock in. When your clients eventually decide that they are sick of viruses, and licensing extortion, they'll be thankful that your system provides the flexibility to get them out of that mess.
Openess is never a setback for writing good software. Precisely the opposite in fact. Openess allows you to be flexible and adjust for changing market conditions, software bugs, etc.
For example I wrote a system using a 3rd party data abstraction layer. Now, what you are professing suggests that I just write to that layer. Instead I wrote wrappers that could work with any abstraction layer. It turned out that this abstraction layer was buggy as hell. After another week of work, I had implemented an entirely different layer that worked much better. If I had not written an abstraction to maintain that openess, I'd still be rewriting code.
Re:VS sucks (Score:3, Insightful)
In that case, I am also a Maxwell House coffee fanboy, a Sanford pencils fanboy, a Novell Border Manager fanboy, and a Road Runner Business Class fanboy.
Re:VS sucks (Score:3, Insightful)
We do have a solution for single machines that uses Microsoft SQL Desktop Engine. That's up to 5 machines for no cash at all. T
Re:VS sucks (Score:5, Informative)
The
On this same machine, NetBeans takes over 70 meg of space, 180 meg of memory for only 10 classes, pegs the cpu if you stare at it hard enough, and it just slow as hell. Starting it can take close to a minute.
Please don't compare Studio 6, a piece of crap, and VB3, which is so old that it shits doilies, with a modern on-demand IDE liek Studio.NET. When I did Java, I used to use textpad for the bredth of my typing and editing because the IDE was so slow. Now I do it all in Studio. It's just better.
Java vs. .Net (Score:5, Insightful)
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?
Re:Java vs. .Net (Score:5, Interesting)
Think of this another way: What if .Net was designed by a single person in their garage, would it get the attention it does? Of course not. Dot Net is a real threat to Java simply because it comes from Microsoft (a mega-corp with plenty of access).
You may not like it (I know I don't), but that is the nature of things.
Re:Java vs. .Net (Score:3, Funny)
Give him "Neo's Response":
"How about I give you the finger [display "the finger"] and you give me my phone call?"
Re:Java vs. .Net (Score:3, Interesting)
I'm certainly a Java proponent, but I know full well
Between the friendliness and name-value that Visual Studio has, and the fact that when a manager is making a choice about a product platorm for project, they don't always facto
Re:Java vs. .Net (Score:3, Informative)
Somewhat incorrect. The MS.NET runtime is Microsoft's implementation of the CLR/CLI specification which is owned by ECMA. The Mono project is an example of a development effort to put together another implementation of the CLR specifically targeted at *nix OS's.
Now that doesn't mean that ANYONE at all (other than MS) is going to actually build and deploy an implementation of the spec.
The "Dotnet standard" bait-and-switch (Score:5, Informative)
The Dotnet runtime consists of approximately 1200 classes, including Windows Forms, ASP.NET etc.
The CLR/CLI standard only covers core language-related classes - approx 120 in all.
Dotnet is therefore mostly proprietary and there is no spec. to implement. Mono is having to reverse-engineer, with dubious consequences.
Re:Java vs. .Net (Score:5, Interesting)
Technically .NET wasn't released until a year ago last spring. It's only been out about 18 months. Last fall it was clear that people using .NET were very early adopters, but uptake seems very strong.
To be honest, Java on embedded devices doesn't seem like that big a win to me at the moment, no matter how many cellphones they're trying to ship with it. Most Java in use is on the server side. And that is a big differentiator between Java and .NET: Java runs on pretty much any hardware you care to throw at it, which means you can scale your server from that itty-bitty Pentium box up to the biggest stuff Sun sells. With Windows you've got midrange Intel boxes and ... midrange Intel boxes. Little per-box scalability, and that means that large systems are going to be a pain to manage - particularly given how hard it is to manage Windows servers in bulk.
I can see .NET being useful for small servers that need to be put together quickly and cheaply; VS.NET is great for that. But it's not really there yet for big systems, both in terms of framework maturity and OS scalability and stability.
Mostly I think we'll see .NET be used in building GUI applications in the near term. Let there be no mistake, it is phenomenal at that.
Re:Java vs. .Net (Score:3, Interesting)
If you ignore that little bit of marketing idiocy then .NET comes down to being Microsoft's take on Java. In fact, it's derived from Microsoft's version of Java. When Sun sued Microsoft over compatibility issues Microsoft didn't just throw that work away, they changed it into .NET.
What they did, and this is clear from the VM language and APIs, is take the JVM pretty much intact and renamed the class library pac
Mono? (Score:3, Insightful)
Mono [go-mono.com]
As for a claim that
with finalization on install, there is absolutely no performance loss between straight-C and C#. in fact, depending on your straight-C compiler, the C# code can run
Re:Mono? (Score:5, Insightful)
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.
Re:Java vs. .Net (Score:5, Insightful)
The thing that really helps us is that we can develop code using WSAD (WebSphere Studio) on our Windows 2000 boxes on our desktop. We then deploy to a development sandbox made up of several Linux boxes (Same code, no recompile). Once we test it there we port it to our Development Test box which runs on IBM's AIX operating system (as do the test, stress test, and production servers).
Could we pass our code around to multiple machines with 3 different operating systems using .NET? No way. Could we toss a WebSphere server on a cheap Linux box and have a test bed up and running in an afternoon? Absolutly, Could we do the same thing with a Windows 2000 server? Not if we want to expect the same level of performance (both speed and stability) out of the same hardware. And that doesn't begin to worry about the licensing cost of building that quick and dirty test bed with Linux and Java as opposed to Windows 2000 and .NET
Nope, it's a bit too early to start reporting that Java is dead and .NET is the murderer. I think that in 5 more years I'll still be writing Java code and .NET will be sitting in a cardboard box of formerly used software in the closet along side COM, DCOM, and Active X.
random thought of the day (Score:4, Funny)
Hrm, reminds me of when two fat ugly chicks in my high school started a cat fight in the hallway.
Lies, statistics, and analysts (Score:5, Insightful)
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
Re:Lies, statistics, and analysts (Score:5, Insightful)
I have noticed Slashdot seems to be posting a lot of these clueless journalist articles lately. I don't seek advice about my car from English majors, so why should I listen to them about computers? Let's have more articles from sources qualified to speak on their subjects.
Re:Lies, statistics, and analysts (Score:3, Informative)
SWT [eclipse.org]
Fast, easy to understand if you already understand AWT or Swing. Not perfect, but what is?
Re:Lies, statistics, and analysts (Score:5, Insightful)
If you feel this represents the same kind of vendor lock-in as Dotnet then your commercial antennae are in need of adjustment.
Re:Lies, statistics, and analysts (Score:4, Insightful)
AWT.
It's obvious (Score:3, Funny)
Re:It's obvious (Score:5, Interesting)
Red Queen race (Score:5, Interesting)
Why would we not want a language to be stagnant? I wonder how much time is wasted just trying to keep up with changes to languages and development environments?
Re:Red Queen race (Score:3, Insightful)
People that argue that Java is stagnant mean that there are things the language needs, but it is taking too long to get them.
Dotnet == Java (Score:5, Funny)
An important thing to point out: (Score:5, Insightful)
Re:An important thing to point out: (Score:3, Insightful)
But there are no great ways to write them without using J2EE. At least not unless you absolutely love client-side code.
Servlets are part of J2EE. Among the most useful parts, IMNSHO.
I don't think it's such a problem to remember that Java!=J2EE.
The problem is most people don't remember J2EE!=EJB, that an enterprise application doesn't always NEED EJBs, and that a lot of of the perceived complexity of J2EE disappear
The prophet sayeth (Score:5, Funny)
Come on ... (Score:5, Insightful)
Are you serious ? Then:
Where is the appserver that runs
Can you cluster that appserver like J2EE-appservers ?
Stagnant? How about stable and secure. (Score:5, Insightful)
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.
Industry Newspeak (Score:5, Insightful)
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".
Re:Industry Newspeak (Score:5, Interesting)
Sure they do, there's been a lot of innovation going into hammers lately. They release new versions of hammers constantly, and other woodworking tools - to many oldtimers dismay, who will swear up and down the hand plane they used in 1952 was an order of magnitude better than todays.
Stanleys Anti-vibe series of hammers, for instance, they have whats basically a tuning fork built into the handle. The fork vibrates and takes the energy away from your hand. Spend a day ramming nails in with a wooden handled hammer, then a day with one of the newer models, and you definately feel the difference.
They're also constantly adjusting the weights and balances, tweaking the shape and makeup of the heads/claws.
Go look at the tool section at home depot and get an idea about hammers.
Is $TECHNOLOGY dead? (Score:5, Insightful)
Direction for Java (Score:3, Insightful)
Re:Direction for Java (Score:5, Informative)
Java, success, failure (Score:3, Insightful)
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).
Java is dying, news at 11 (Score:5, Interesting)
Where I work (for a DoD agency) we are developing J2EE solutions with open source tools in part to get away from vendor lock in, something that MS is particularly bad with. Once MS ratchets up the lock in with the introduction of DRM in Office file formats, I think MS solutions as a whole are going to become less attractive, and this will be a strong disincentive to adopt
Answer (Score:5, Funny)
Of course it is... and this late in the day it's time to switch over to beer anyway.
What about Java on other platforms..... (Score:5, Interesting)
I think Sun has done a great job promoting Java on a variety of platforms, so I think McNealy isn't concerned about
Microsoft Smartphones (Score:3, Informative)
Make up your mind. (Score:3, Insightful)
and later,
Huh? So first this article complains that Java is too complicated and needs to be simpler. Then it complains that Sun makes it hard to add new features (i.e. complexity) to the platform.
I'll say it again...Huh?!?
I think the JCP moves at just the right speed. If you change a language too quickly, make it harder for everyone to keep up. If you move to slowly, the language/platform won't be able to keep up with current technology. It should be hard to add things to the Java platform. A lot of people have a lot of different ideas about what Java should be. Sun tries to make sure only the best of the best gets integrated into the core platform. Anything else can be left as a 3rd party library (like AspectJ for example).
A great man once said, "The Law should be stable but never stand still". Programming languages and platforms are the same way. Turning the JCP into a rubber stamp for new, unproven ideas isn't going to do anyone any good.
Java is finished for most open source work (Score:4, Interesting)
Another way of looking at it is that Java is too encumbered by intellectual property--copyrights, patents, and licenses--held in part by Sun and in part by an industry consortium (JCP). Anybody that builds applications on top of Java becomes as dependent on Sun as people who write Windows software become dependent on Microsoft. While there are plenty of open source projects for both Java and Windows, ultimately, that is not a good state of affairs for open source developers.
WORA made sense for Java's original purpose in life, that of a thin, universal client platform. WORA makes no sense for Linux developers trying to develop high-quality Linux applications. (And, frankly, I think Windows programmers are saying the same about Java on Windows, which is why
Java held a lot of promise for open source development at one point, but I think that's over now. The Java platform will continue to be used widely in many commercial (and some free) server-side applications. Subsets of Java will be used in teaching and research. And you will see more and more partial clones of Java appearaing. Open source will probably continue with a mix of languages. gcj+SWT, which implements the Java language but not the Sun APIs, may achieve modest popularity. Mono+Gtk# may become fairly popular (but the
Re:Java is finished for most open source work (Score:4, Insightful)
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).
Re:Java is finished for most open source work (Score:4, Insightful)
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
.net is great if your already an MS shop (Score:3, Insightful)
With that out of the way I looked up the Sun's pet shop program example in Java and then the MS version in C#.
Look at the lines of code in the MS version? The gui portition has an 8th of the code that the java version has. Also version 2 of Microsoft's
You can do alot of things with
I heard the libraries cover more areas then Java but they are thinner then the ones Java already covers. Also C# supports enumators, pointers ( yes they are evil), and cross language support and integration. Java 1.5 is playing catchup.
Re:.net is great if your already an MS shop (Score:3, Interesting)
To take such an illustrative example, rearchitect it, then make any claims about efficiency, is/was ludicrous. Like taking sample code out of a book on Java, and then showing how an expert
Do some more research and you'll find that the Petshop project has been completely discredited as a comparison of Java
Simpler? (Score:4, Insightful)
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,
Interview with Anders Hejlsberg (Score:5, Interesting)
C# is one programming language I've stayed away from--and for no particular reason. I had picked up the C# specification [ftp.ecma.ch] [PDF] in 2000, but never really got down to the canonical "hello world" program. Today in 2003, as I look back, I guess I haven't missed much.
Let's go back to August 2000 and revisit Hejlsberg's famous O'Reilly interview [oreilly.com] by Josh Osborn [oreilly.com].
Web Applications Suck (Score:5, Insightful)
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?"
Slow cumbersome process (Score:4, Informative)
Java versus .NET is becoming a ubiquitous topic. It's been the subject of debate since .NET beta 1. Microsoft and Sun both have "independent" studies conducted to prove that their platform (J2EE/.NET) is better and both have convincing arguments. There is no perfect language or platform to solve every programming problem - sometimes it's C++, sometimes it's Python, sometimes it's something else - it really depends on the problem.
It's no secret that one reason Microsoft created C# is to compete directly with Java. It's pure ignorance to say that C# is proprietary and that you're locked-in to Windows. C# and the CLI (.NET) is an approved ECMA standard [ecma-international.org]. This is something SUN was unwilling to do with Java. For this reason, in a sense, Java remains far more proprietary than C#. It's too early in C#'s life to say that it won't be ported to other platforms - look at Mono [go-mono.com]. There is a lot of FUD being disseminated about "Microsof is going to sue Ximian, et al. for Mono" blah,blah,blah. That's not going to happen. Microsoft has already released the source code to the CLI [microsoft.com] with one intention of "People developing their own CLI implementations will find the Shared Source CLI an indispensable guide and adjunct to the ECMA standards.". So, for the argument that C# and the CLI are proprietary and one is bound to Windows is just plain ridiculous.
Syntactically, C# and Java are extremely similar. They both derive from C++. Structurally, they are very similar as well. They are both OO languages, everything is a class, etc. Side-by-side they look very similar. There are numerous small details which make C# "friendlier" than Java, ie. C# has no requirement that the file be named after the class. 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. On the merits of the languages alone, C# is stronger than Java. It should be expected since it was developed from scratch nearly 7 years after Java arrived.
As far as performance, Java leaves a lot to be desired. I won't belabor this issue. If you'd like a demonstration of the difference between the run-time execution of .NET vs Java, pick your favorite VM and run Forte, then run Visual Studio .NET (it's written in C#) and decide for yourself. Java run-time performance alone is enough to dissuade some developers.
Java does come as close to a RAD language as can be. Java applications can be developed quickly with far fewer bugs and errors as a comparable C/C++ application with the benefit of garbage collection as well. For this Java gets an "A". It greatly simplifies the process of rapidly developing database and other applications.
Is Java going away? Hardly. But like it or not, C# and the CLI are here to stay as well. It's only a matter of time before the CLI is ported to other platforms and environments just like the JVM.
Re:Slow cumbersome process (Score:4, Interesting)
> between the run-time execution of
> pick your favorite VM and run Forte, then run
> Visual Studio
That is a lie. VS.NET is not written in C#.
> There is a lot of FUD being disseminated about
> "Microsof is going to sue Ximian, et al. for
> Mono" blah,blah,blah. That's not going to
> happen.
Your omniscience is impressive.
Microsoft has gotten EMCA's stamp on C#, the CLR, and the basic Framework, but they still control them with an iron grip. When
Even if you're willing to go beyond ECMA and port the Microsoft proprietary APIs to other platforms, the fact is that System.Windows.Forms is absolutely NOT a cross-platform GUI toolkit. The Mono guys are implementing it by sucking in WINE! There is simply no Microsoft-blessed cross platform GUI toolkit for
Re:Slow cumbersome process (Score:5, Insightful)
>> 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
Java vs. .NET (Score:5, Informative)
My favorite tool for the integration is JuggerNET [codemesh.com], which transparently starts up a JVM in the CLR process and the developer simply codes against generated .NET classes. I am affiliated with Codemesh, so I'm somewhat biased (take a look at Stu Halloway's great website [develop.com] for alternatives) but working with both platforms for a living, I just can't get excited about controversial this or that is dying statements. Both platforms have their strong and their weak points.
I love the platform portability of Java, but I think Java is too closed in terns of language integration. Doing JNI by hand is an abomination, and most people at Sun admit it.
I love the language portability of .NET (it's not perfect, but then, neither is Java's platform portability) but I hate the exception model.
So, there you have it. Neither will kill each other, they will just coexist uncomfortably until they both get replaced with something new.
Just more Micrososft propoganda (Score:3, Informative)
The Other Variable: Linux (Score:4, Informative)
I feel that the technical debate between
Just one problem, most businesses wish to make $$$, and if you haven't noticed the tech sector barely able to keep it's head above water right now. Thus, all things equal I'd bet most businesses will probably opt for a Java (or J2EE)/Linux solution as the overall price can't be beat, and you don't have to waste you development time creating valueless libraries that others must have had to create already. Not to say
Anyhow, my 2 cents.
J2EE (Score:5, Funny)
Re:J2EE (Score:4, Funny)
Re:J2EE (Score:5, Funny)
Re:Portable? (Score:3, Insightful)
Re:Portable? (Score:3, Interesting)
I teach advanced object oriented design and security. It keeps food on the table.
Re:Is Java finished? (Score:5, Informative)
Please follow along carefully:
1) Go to http://java.sun.com.
2) Click the button labelled "J2SE - Core Java Software". It's the big blue button in the middle.
3) On the next page, click "Source Licensing". It's in the links on the left-hand side of the page.
4) On the Source Licensing page, click "Download".
5) Follow the directions to download the entire J2SDK source code.
Now, what was that about the source code not being available?
Re:Java, my abusive friend (Score:3, Interesting)
Most newer IDEs provide far more functionality than anyone needs while learning tha language or working on simple applications. That contributes to the long startup times and some of the complexity.
.NET user interface is also quite slow unless you throw some serious hardware at it. 2GHz+ CPU, 1GB+ RAM to make it a bearable experience.
The MS Visual Studio
Re:hmm lets look at jobs on monster (Score:3, Interesting)