Java Forum / General / July 2006
Why not written in Java?
Joshua Jung - 11 Jul 2006 20:22 GMT Hello all you wonderful experts :D
I am currently doing some research for a startup company and am looking at what language we should use to program our client/server GUI application. Our target audience is all home PC and Mac users and small businesses.
My current programming knowledge includes a decent amount of C++ (Borland and Visual Studio IDE) and some Visual Basic and recently I picked up Java. I also have experience in several web-based languages.
After doing extensive research and even spending several weeks learning Java for research and building a client/server app in it (which was quite easy and fun btw!) here is the question that has been in the back of my mind for quite some time: why is Java not used more?
Here is a list of the programs that I use regularly that are not built in Java (AFAIK) and are cross-platform compatible:
iTunes (Mac or Windows) Skype (Mac, Windows, Linux) OpenOffice (Just about anything AFAIK) Firefox (same) Thunderbird (same) Blender 3D Modeler Gaim (I think its cross-platform compatible)
AFAIK, I could be wrong, these are all built in C++. Why? If these companies were strongly for cross-platform compatibility and many of them are all about open source, why are they not using Java? From what I know right now, I would have built them in Java (or tried to), why didn't they? What do they know that I don't?
Could someone who was involved in any of these projects please let me know the reasoning that a software development team gives for NOT using Java even when they intend for their project to be cross-platform compatible? It seems to me that if Java was so adaptable and capable all of these programs would have been built in it!
Thanks in advance for your advice...
Josh <><
Alan Meyer - 11 Jul 2006 20:43 GMT > ... > AFAIK, I could be wrong, these are all built in C++. Why? If [quoted text clipped - 3 lines] > they? What do they know that I don't? > ... C++ offers many advantages over Java, including:
Much smaller memory footprint. Faster program startup time. Faster execution speed for many kinds of operation (though Java is also fast for some things) No required JRE runtime package installation (if statically compiled, C++ will not require libraries on the target computer - though very often C++ programmers do require them.) Finer grained control over memory and thread management. Native user interfaces (e.g., Windows, not Swing) More access to the environment. Multiple inheritance. Programmer supplied destructors.
The cost for this is: Much more difficult to write cross platform applications. More complicated programming - slower development. More challeng programming environment. The programmer must manage memory himself.
For applications in a controlled environment, e.g., running on a server, I would normally prefer Java. For applications running on many different computers that I don't control, and with enough users to justify the extra cost of C++ development, I might prefer C++.
Alan
Joshua Jung - 11 Jul 2006 22:23 GMT > For applications in a controlled environment, e.g., > running on a server, I would normally prefer Java. [quoted text clipped - 3 lines] > > Alan Thanks for your help! That makes quite a lot of sense... which is why I am now looking into wxWidgets. Appears to be a fairly solid platform and if necessary we could modify source as well.
Thanks again,
Josh <><
Mark Space - 12 Jul 2006 07:52 GMT >> For applications in a controlled environment, e.g., >> running on a server, I would normally prefer Java. [quoted text clipped - 11 lines] > > Josh <>< Personally, I would prototype in Java. Maybe even release version 1.0 in Java. Then when you have some real world profiling and user feedback, re-write the critical sections in C/C++.
Andy Dingley <dingbat@codesmiths.com> - 12 Jul 2006 14:03 GMT > C++ offers many advantages over Java, including: IMHO, the most significant ones are that:
C++ offers many advantages over Java for _desktop_GUI_apps_, including:
1) A vast horde of experienced desktop GUI app coders, already used to working in C++ (In contrast, the majority of Java experience is in back-ends)
2) Java has historically had ugly and unpopular GUI toolkits
Thomas Hawtin - 12 Jul 2006 16:13 GMT > 1) A vast horde of experienced desktop GUI app coders, already used to > working in C++ > (In contrast, the majority of Java experience is in back-ends) Apparently, Swing is the dominant GUI toolkit in North America.
http://weblogs.java.net/blog/hansmuller/archive/2005/10/official_swing.html
Tom Hawtin
 Signature Unemployed English Java programmer http://jroller.com/page/tackline/
bowman - 16 Jul 2006 05:48 GMT > Apparently, Swing is the dominant GUI toolkit in North America. I find that extremely hard to believe unless there is some sort of qualifier in that survey.
Thomas Hawtin - 16 Jul 2006 09:50 GMT >> Apparently, Swing is the dominant GUI toolkit in North America. > > I find that extremely hard to believe unless there is some sort of qualifier > in that survey. It seems at least plausible to me. Delphi, for instance, has been very popular, but that doesn't mean Microsoft Word (or Firefox, etc.) is written in Delphi.
Tom Hawtin
 Signature Unemployed English Java programmer http://jroller.com/page/tackline/
bowman - 16 Jul 2006 15:58 GMT > It seems at least plausible to me. Delphi, for instance, has been very > popular, but that doesn't mean Microsoft Word (or Firefox, etc.) is > written in Delphi. Perhaps Java is more prevalent in segments of the industry that I am not familiar with. I just don't run into many Java applications, which leads me to question the dominance of Swing. When I see the surveys and papers that report that Java/Swing is the most popular language, I realize there is a whole world I don't know anything about.
Alan Meyer - 18 Jul 2006 00:16 GMT >> Apparently, Swing is the dominant GUI toolkit in North America. > > I find that extremely hard to believe unless there is some sort of qualifier > in that survey. I also find it very hard to believe.
If we regard "dominate GUI toolkit" as meaning the one that the most number of end users see for the most number of hours, I'd say that the Windows API and the many layers over it like Microsoft Foundation Classes and Visual Basic are vastly more dominant than Swing, probably by two, three or four orders of magnitude. Think for example about MS Office, Internet Explorer, Firefox, Outlook Express, and a few other applications that occupy 99% of most users time.
As for the number of programmers using Swing vs. those using one of the MS Windows toolkits - that may depend on how you count the Windows toolkits. Are Visual Basic and MFC two different toolkits? They are, but they represent the same underlying tools.
Most Java programmers I know aren't writing Swing applications, they're writing applications that face the user via a web browser.
I'm hard pressed to think of a single, popular and well known program running under Swing, but that may just be my lack of knowledge of what's out there.
Alan
Raghar - 15 Jul 2006 14:25 GMT >> ... >> AFAIK, I could be wrong, these are all built in C++. Why? If [quoted text clipped - 8 lines] > Much smaller memory footprint. > Faster program startup time. 0.5 for Java programs 0.5 average for C++ programs 0.2 for ASM programs If Java standard had splash screen sooner, Java programs would be at par with perceived startup time of the above mentioned applications.
> Faster execution speed for many kinds of operation > (though Java is also fast for some things) ??? If you are talking about unverified array access, I like programs without ability of memory access violation.
> No required JRE runtime package installation > (if statically compiled, C++ will not require > libraries on the target computer - though > very often C++ programmers do require them.) Tell that to my Linux. Also tell that to all programs I'd like to run in 64 bit mode. Of course you can also use Excelsior JET. (or kick GCJ programmers into creating more cappable, and less abusing version.)
> Finer grained control over memory and thread > management. People who were forced into REALLY exactly control memory, hated it.
Does someone need more than correctly working >2 ms preemptive multithreading? Why? Thread management should be work of the OS sheduler, NOT programmer.
> Native user interfaces (e.g., Windows, not Swing) This is not advantage at all. For example I like when my applications don't have look and feel of OS. So they could look really OS independed.
In fact I often use OpenGL for GUI.
People that needs at all cost it's GUI to look exactly as rest of OS programs, might use SWT. BTW it looks like there is some limit on amount of native widgets on windoze XP pro service pack 2.
> More access to the environment. This is about the only valid point. Neccessity of creating special add on libraries, and check them against viruses...
> Multiple inheritance. Have you worked in any project that needed to be reliable? It doesn't save enough time to be worthy in long run.
> Programmer supplied destructors. Scary.
> The cost for this is: > Much more difficult to write cross platform applications. [quoted text clipped - 9 lines] > > Alan Thomas Hawtin - 15 Jul 2006 15:08 GMT > If Java standard had splash screen sooner, Java programs would be at par > with perceived startup time of the above mentioned applications. You mean like Java SE 6?
http://download.java.net/jdk6/docs/api/java/awt/SplashScreen.html
Tom Hawtin
 Signature Unemployed English Java programmer http://jroller.com/page/tackline/
Alan Meyer - 18 Jul 2006 00:36 GMT Raghar,
I think that a lot of your points are well taken, but they're about ease of programming, not program efficiency.
For most of what most programmers do, ease of programming is more important than efficiency. But it's not true of all programs. I have worked on numerous projects where efficiency and/or control is critical.
For example, I've been on publishing projects where a program must parse and process a million or more XML documents. Using the C++ parsers and XSLT processors rather than the Java based ones might take hours or days off the program run time.
Or consider what happens in a web browser like Firefox or IE, where a user may have 10, 20, or 40 web pages open at once. Or a word processor where a user might be editing a 10 MB technical manual and do a search for some words, or format a document for printing. Or an image editor like Photoshop or GIMP where a user might have a 10 megapixel image open, with five or six editing layers and multiple levels of undo.
Or consider command line tools like grep or wc or uniq. I can process a file with one of those tools faster than I can load and initialize the Java virtual machine, never mind load a Java program and run it.
I understand why detailed memory management, programmer supplied destructors, and multiple inheritance seem scary to you. They do put more demands on the programmer and make it harder to produce a bug free program. But they are still justified for some projects.
Some people would say, Why use Java? Why not do everything in Excel, or a declarative language like SQL, or RPG (that's "Report Program Generator", not "Rocket Propelled Grenade" :)) But you can't solve every problem with simple tools. Sometimes you need a more complex tool like Java.
And sometimes you need a still more complex tool like C++, or a simpler but trickier one like C.
I would venture to say that, until computers become many times faster than they are now, with many times more memory (which will eventually happen) there will not be a popular word processor or web browser or photo editor written in Java. And it will be many years more before we see system software written in Java.
Alan
Oliver Wong - 11 Jul 2006 21:01 GMT > why is Java not used more? > > Here is a list of the programs that I use regularly that are not built in > Java (AFAIK) and are cross-platform compatible: For every program you list, I'll try to think of a reason why a similar program could not be written in Java. You'll notice that for the many of them, I can't come up with a reason, and sometimes I'll even link to a program written in Java which does something similar. Obviously, I can't say why that specific program wasn't written in Java. You'd have to ask the developers that question. Perhaps they simply don't know/like Java very much?
> iTunes (Mac or Windows) JMF, the Java Media Framework, is something of a mess (IMHO). Poorly documented and poor support means processing media files is a bit of a pain. That said, check out http://jajuk.sourceforge.net/
> Skype (Mac, Windows, Linux) Can't think of any reason why not.
> OpenOffice (Just about anything AFAIK) Apparently, politics was a factor in limiting the amount of Java in OO. See http://en.wikipedia.org/wiki/OpenOffice.org#Java_controversy That said, some portions of OO are indeed written in Java.
> Firefox (same) Can't think of any reason why not. Perhapse the fast start-up time was a key requirement.
> Thunderbird (same) Can't think of any reason why not.
> Blender 3D Modeler Can't think of any reason why not. See http://aoi.sourceforge.net/index
> Gaim (I think its cross-platform compatible) Can't think of any reason why not. See http://jclaim.sourceforge.net/
- Oliver
Thomas Hawtin - 11 Jul 2006 23:15 GMT >> why is Java not used more? >> [quoted text clipped - 3 lines] > documented and poor support means processing media files is a bit of a > pain. That said, check out http://jajuk.sourceforge.net/ There is an iTunes clone written in Java.
http://sourceforge.net/projects/jtunes4/
Apple hasn't been great in its support for Java.
>> OpenOffice (Just about anything AFAIK) > > Apparently, politics was a factor in limiting the amount of Java in > OO. See http://en.wikipedia.org/wiki/OpenOffice.org#Java_controversy > That said, some portions of OO are indeed written in Java. It's based StarOffice which predates Java.
>> Firefox (same) > > Can't think of any reason why not. Perhapse the fast start-up time > was a key requirement. It's derived from Mosaic, which predates Java.
>> Thunderbird (same) > > Can't think of any reason why not. It's derived from the same source as Firefox, which predates Java.
Tom Hawtin
 Signature Unemployed English Java programmer http://jroller.com/page/tackline/
Hendrik Maryns - 12 Jul 2006 13:52 GMT Thomas Hawtin schreef:
>>> why is Java not used more? >>> [quoted text clipped - 24 lines] > > It's derived from Mosaic, which predates Java.
>>> Thunderbird (same) >> >> Can't think of any reason why not. > > It's derived from the same source as Firefox, which predates Java. And now there is Grendel: http://wiki.mozilla.org/Grendel
- -- Hendrik Maryns
================== http://aouw.org Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html
Scott Ellsworth - 11 Jul 2006 23:21 GMT > > why is Java not used more? > > > > Here is a list of the programs that I use regularly that are not built in > > Java (AFAIK) and are cross-platform compatible: [...]
> > Firefox (same) > > Can't think of any reason why not. Perhapse the fast start-up time was a > key requirement. Firefox derived from the Mozilla sources and team, and had strong roots in Linux. Development, for those in the Linux world, often requires a GPLed language that is installed for free on virtually all systems that you want the end product to work on.
Java has its own licensing, and it is not GPLed. Thus, many in the Linux world do not find it acceptable for any purpose. (I happen to disagree with this stance, but I can see their point.) Therefore, if you are developing for Linux, you risk alienating some fervent platform advocates if you require Java.
This is primarily a political, not a technical, problem. A great many projects run in Java that are hosted on Linux - I have worked on several myself. Without a GPLed Java distribution for Linux, though, it is awfully hard to convince Linux developers that Java is a good language for something intended for the typical Linux user. After all, a typical user should be able to use the tool without agreeing to non-GPL agreements.
I keep hearing rumors that Sun will open source Java, at least for the Linux world, which would make a difference.
Scott
 Signature Scott Ellsworth scott@alodar.nospam.com Java and database consulting for the life sciences
Alan Meyer - 12 Jul 2006 02:27 GMT > .... Development, for those in the Linux world, often requires a > GPLed language that is installed for free on virtually all systems that [quoted text clipped - 3 lines] > Linux world do not find it acceptable for any purpose. > ... You make some important points here.
A related point is that C and C++ are ANSI standard languages while Java is not. Sun can make changes to Java and replace all the JREs on user computers. Some developers may feel that this exposes them to extra risks with Java.
Still, on technical merits alone, I think there are solid reasons for choosing C or C++ for difficult, high performance, applications where the developer may need to control things down to the "bare metal" as we used to say, and where the user base is large enough to justify the extra cost development as compared to the simpler programming model in Java.
Alan
Luc The Perverse - 12 Jul 2006 02:46 GMT >> .... Development, for those in the Linux world, often requires a >> GPLed language that is installed for free on virtually all systems that [quoted text clipped - 17 lines] > large enough to justify the extra cost development as compared > to the simpler programming model in Java. Yes - in general Java is made for designing high end user applications. It is not really the best choice for hardware based designs.
 Signature LTP
for( Base i : allYourBase) i.AreBelongToUs();
Daniel Dyer - 11 Jul 2006 23:03 GMT > Hello all you wonderful experts :D > [quoted text clipped - 11 lines] > (which was quite easy and fun btw!) here is the question that has been in > the back of my mind for quite some time: why is Java not used more? Java is used more, just not where you can see it. It's very widely used for server applications (e-commerce sites, trading applications, etc.). I'd guess that the vast majority of the professional Java developers who frequent this group are developing software that is mostly server-side. And quite a few of the others are probably working with mobile devices.
> Here is a list of the programs that I use regularly that are not built in > Java (AFAIK) and are cross-platform compatible: [quoted text clipped - 13 lines] > know right now, I would have built them in Java (or tried to), why didn't > they? What do they know that I don't? iTunes is a special case in that, as far as I am aware, it was originally intended to be cross-platform. It is only comparitively recently that Apple decided to release a Windows port. On the Mac it's part of the iLife suite, which is very much a Mac-only thing, intended to woo Windows users to switch to the Mac experience. The integration with the OS and its UI is obviously much closer with a native application.
Skype could probably have been written in Java and still been just as successful (just like Limewire is). Maybe one reason they decided against it is that Skype uses proprietary protocols and algorithms and Java is typically easier to reverse engineer than native code.
Likewise, Gaim could be done in Java with no problems, but probably isn't due to its Gnome/Linux roots.
The developers of the other applications on your list would probably, rightly or wrongly, cite performance considerations (Blender in particular).
OpenOffice has it's roots in Star Office, which although now owned by Sun, was originally developed by the German company Star Division. Corel tried to sell a Java office suite in the 90s, but it flopped quite badly. It would be a more feasible endeavour now given the progress in both Java and PC technology. OpenOffice performs abysmally any way, even though it wasn't developed in Java. And the experience is pretty poor on the Mac, where there isn't a proper native version.
> Could someone who was involved in any of these projects please let me > know [quoted text clipped - 4 lines] > > Thanks in advance for your advice... Some reasons not to use Java on the desktop:
1). If you need access to native APIs such as Win32 and DirectX, or to interface with hardware devices.
2). In the past Java applications didn't look quite right. Swing has improved considerably in this respect in recent versions, and there is now SWT as an alternative.
3). Footprint. Java applications tend to use lots of memory. But then so does iTunes.
Cross-platform desktop applications that are written in Java:
Limewire, Oracle admin tools, Sybase admin tools, several online poker rooms and casinos, most Java development tools, many non-Java development tools.
See Swing Sightings (http://java.sun.com/products/jfc/tsc/sightings/) for many more.
Dan.
 Signature Daniel Dyer http://www.dandyer.co.uk
Daniel Dyer - 11 Jul 2006 23:05 GMT > iTunes is a special case in that, as far as I am aware, it was > originally intended to be cross-platform. That should read "...not originally intended..."
Dan.
 Signature Daniel Dyer http://www.dandyer.co.uk
Timo Stamm - 11 Jul 2006 23:33 GMT Daniel Dyer schrieb:
> iTunes is a special case in that, as far as I am aware, it was > originally intended to be cross-platform. iTunes didn't really originate at Apple. It started off as SoundJam, a Mac-only MP3 player, and was published by Mac-only distributor Casady & Green (who went bancrupt in 2003) until it was acquired by Apple. It was never intended to be cross-platform.
Another very popular mp3 player at this time was Audion by Panic. Cabel Sasser, co-founder of Panic, wrote a very interesting article about the whole story (you might feel different about iTunes after reading it):
http://panic.com/extras/audionstory/
Timo
Daniel Dyer - 12 Jul 2006 00:22 GMT > Daniel Dyer schrieb: >> iTunes is a special case in that, as far as I am aware, it was [quoted text clipped - 4 lines] > Green (who went bancrupt in 2003) until it was acquired by Apple. It was > never intended to be cross-platform. That's what I meant to say, that it *wasn't* intended to be cross-platform. I think that's one reason why it's so memory hungry on Windows.
> Another very popular mp3 player at this time was Audion by Panic. Cabel > Sasser, co-founder of Panic, wrote a very interesting article about the > whole story (you might feel different about iTunes after reading it): > > http://panic.com/extras/audionstory/ Thanks for that, I'm not so familiar with Mac history pre-OS X.
Dan.
 Signature Daniel Dyer http://www.dandyer.co.uk
Brandon McCombs - 12 Jul 2006 06:25 GMT > Limewire, Oracle admin tools, Sybase admin tools, several online poker > rooms and casinos, most Java development tools, many non-Java > development tools. Don't even get me started on the quality (look n' feel, performance, etc.) of Oracle admin tools. They don't seem to know the Java language that well and/or do a piss-poor job of making their own widgets which affects the quality of the tools they provide. That wouldn't be too much of a problem except just about all their admin tools are java now and the tools suck because of it.
Daniel Dyer - 12 Jul 2006 09:22 GMT >> Limewire, Oracle admin tools, Sybase admin tools, several online poker >> rooms and casinos, most Java development tools, many non-Java [quoted text clipped - 6 lines] > of a problem except just about all their admin tools are java now and > the tools suck because of it. I know. I was just giving an example of something that was written in Java (pre-1.2 I think). The Sybase tools are at least as bad.
Dan.
 Signature Daniel Dyer http://www.dandyer.co.uk
Robert J. Hansen - 12 Jul 2006 04:37 GMT Warning: nobody's ever accused me of being a Java zealot, but people have in the past accused me of being a C++ zealot. They're wrong, but the accusation has been made, and so I should bring it up. :)
> (which was quite easy and fun btw!) here is the question that has been in > the back of my mind for quite some time: why is Java not used more? Honestly? Usually it's a combination of history, politics and prejudice. Sometimes it's because the application depends on a C++-only library.
History: it's only recently (as of Java 1.4 and later) that Java has really been able to compete with native code for heavy lifting. For software projects that started prior to Java 1.4, they probably used a different language out of sheer necessity.
Politics: a lot of the projects you've made mention of are open source. The majority of open source users and developers are sane, calm, rational and friendly. Some of them, though, need to be reminded that Thorazine is available in seven different delicious fruit flavors. Any open-source project is going to reflect the beliefs of its developers and will be heavily influenced by feedback from users... and the Thorazine-needing crowd tends to be very, very vocal.
Prejudice: "Java is slow and bloated." C++ got unfairly painted with this brush for years. Now Java is the new favorite "slow and bloated" whipping boy. Generally speaking, there's little to no truth to the prejudice--but the prejudice exists.
> iTunes (Mac or Windows) No idea: I haven't seen the source.
> Skype (Mac, Windows, Linux) AFAIK, Skype is C++ because they wanted to use Qt, a C++ UI library, to allow them to write once and get native-looking code everywhere.
> OpenOffice (Just about anything AFAIK) Substantially predates Java. OpenOffice is based on the old StarOffice codebase, which is about as old as the hills.
> Firefox (same) Based on Mozilla, which began in 1998 during the (thinks...) Java 1.1 days. Java 1.1 was unequivocally not up to the task then.
> Thunderbird (same) Based on the Mozilla email client code. Likewise.
> Blender 3D Modeler No idea.
> Gaim (I think its cross-platform compatible) Open source issues. When Gaim was first being written, there was no open-source Java environment.
Ed Jensen - 12 Jul 2006 20:45 GMT > Prejudice: "Java is slow and bloated." C++ got unfairly painted with > this brush for years. Now Java is the new favorite "slow and bloated" > whipping boy. Generally speaking, there's little to no truth to the > prejudice--but the prejudice exists. I like Java. Even so, I'm realistic enough to know that the "Java is bloated" argument is unfortunately true.
Tim Smith - 13 Jul 2006 12:20 GMT > Could someone who was involved in any of these projects please let me know > the reasoning that a software development team gives for NOT using Java > even when they intend for their project to be cross-platform compatible? > It seems to me that if Java was so adaptable and capable all of these > programs would have been built in it! The key is that while a developer may intend to provide their software on multiple platforms, their users, as individuals, usually do not give a damn about that. A user is going to buy the program for Windows, and *only* for Windows, or is going to buy it for Mac, and *only* for Mac, and so on.
Combine this with the fact that the distribution of users on platforms is highly skewed toward Windows, and you have most of the answer.
Suppose developer D1 makes his program in Java, not using native code anywhere, so that his application runs out of the box on pretty much every platform that has Java. Developer D2, on the other hand, whose application competes with D1's application, develops it as a native Windows application. Assume both D1 and D2 are good, comptetent, developers.
Here's what happens. D1 beats D2 on Mac, Linux, etc., because D2 doesn't run there. But on Windows, D2 trounces D1, because D2's application takes full advantage of Windows, fits in better with other Windows programs, etc. The net result is that D2 sells a lot more.
Meanwhile, over on the Mac, guess what? You'll have D3, a Mac developer, who is also doing an appliction in this space. D3 is a die-hard gung-ho Mac developer, writing cool Cocoa applications, using every cool thing Apple has, etc. Now D1 gets trounced on the Mac by D3 (trounced even worse than it was on Windows by D2, because Mac users are less tolerant of applications that deviate from the platform's GUI standards).
At some point in here, D2 might even port their application to Mac, and D3 might port to Windows, both making it even worse for D1 there.
You can see where this is going, I'm sure. On a given platform, a native application beats a completely platform-independent application, and so what a developer saves by not having to write more than once they lose in lost sales on all the platforms. It ends up being better to write native applications keeping in mind that you will want to port them later to the other platforms.
The above is for GUI applications for end users. For other types of applications, the dynamics are different.
 Signature --Tim Smith
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|