Slashdot Mirror
Beyond An Open Source Java
Karma Sucks writes "LinuxToday is featuring a intriguing article on why Sun should open source Java, as a stronger followup to the recent ESR saga that was reported here. The writer notes: 'Sun needs to do some radical things to improve its chances of survival, and all of them involve Open Source in some form or the other.' One thing the article fails to mention is the threat of Mono, which should be of special interest to Sun, with its vested interest in GNOME."
So what exactly is closed-source right now? The language is obviously out in the open. Is that copyrighted? Is it the compiling into binary code itself that is copyrighted?
Incompatibility would run rampant. My java apps barely work for my phone as it is.
Give Away the Recipe, Open a Restaurant
Consensus is good, but informed dictatorship is better
It fails to note that these are the *most expensive* full-suites of these products that have lot of non-J2EE frills (you can get into Weblogic's base J2EE support for $10k). Other commercial J2EE application servers are well under the $10k mark (e.g. $1500 for Orion Server)
This article also fails to note that there are more than a couple very robust OpenSource implementations of J2EE application servers, that are of course free.
It's obvious that if they pointed these facts out that their argument would be weaker...
in previous discussion, those opposed OpenSource Java suggested that with MS's domination today, MS can easily 'improvised' OSJava to become a run-on-windows-only-OS-Java (WOOSJAVA).
it doesn't matter if anyone else is going to benefit from/use/modify this WOOSJAVA, most likely it will just be preinstalled in all Windows shipped.
and regardless of what others may like to think, most consumers of MS will think that this WOOSJAVA is now the standard.
so in the end, maybe even Sun needs to write things to accomodate this WOOSJAVA in order to survive, that'll be ironic.
Given the state of Mono, it's not in a position to give anyone pause.
There's no motivation to "Open Source" Java. It's supported on a myriad of platforms and you can even get access to the source if you want to take on the implementation on a new platform.
I think open sourcing it is ok, but they should do all the work on it internally and not let any 3rd party distribute their own Java.
When you have a cross platform interpreter, you need to make sure there is consistency. For example, Microsoft JVM ruined it for alot of people since developers will forget to debug it on Suns JVM, causing huge incompatibility issues that they blamed on Sun.
This article is talking about J2EE (server side) applications. Which often benchmark faster than natively implemented code.
P.S.> Java desktop applications are fairly speedy if you use UI libraries such as SWT - which work directly on GTK for example.
Mono does ahead-of-time compilation on x86 into native code.
You can also compile Java applications to native code using GCJ, assuming that you're not using anything beyond JRE 1.0 (or something like that).
If you think Java is in the enterprise because it is portable, you are greatly mistaken. There are some stuff in Java that makes it a great tool for the job, and portability is only one of them: Portability, Reflection, RMI, Proxies, J2EE, ... And I did forget a lot in the process.
Qt and GTK are not even languages, what the hell are you talking about? You are comparing an enterprise level language with a GUI library! Java is not Swing!
Write boring code, not shiny code!
I'm not certain this is a move that should be made. All we need are 18 different 'forks' in the java tree like certain other open source projects. I can just see it now "No no, you need BobJavaVM-1.43.2.43 - it won't run with FastJava V 2"
...is that Sun allows Java to wallow in limbo until its development becomes unsustainable and people start using other languages and development environments like .NET, and then make it open source because it became a black hole for them.
.NET as a universal development language. You can bet diamonds to dollars that Microsoft will never open source their version though.
I mean, Sun could still have a vested interest in an open source Java and still derive revenue from custom design services and support while displacing the Beast. It isn't even like the implementation is a trade secret. Heck, the Beast has developed Java bytecode interpreters in the past. But the Beast would love to displace Java with
Hence, Sun has a great opportunity here. Will they see it?
...but the code should still run without an interpreter/virtual machine/emulator.
I'll be impressed if they can make it run without a computer.
What?
Sun has enough fingers in enough pies that will keep it going strong regardless of where it's open source strategy goes. The recent deal with the Chinese standard software company shows that it can leverage open source products without having to open source anything so big as Java to establish their commitment.
Java is cool for uber-OO projects. . .
Nah. Java is cool for run of the mill OO projects where everyone else is using Java too, because everyone else is using Java.
If you want to look at something interesting check out Apple's Squeak, an implimentation of Smalltalk-80 where even the VM is written in open source Smalltalk.
Squeak
KFG
There are some interesting points, but others are nonsense. "needs to position its own (Open Source) NetBeans and rival IBM's Eclipse as mere IDEs that support the Ant way of building applications.". Is publicy know by anyone interested that almost every major IDE supports Ant.
" Sun can lend credibility to Mozilla and XUL.". As much as I like Mozilla (I'm using it right now) I don't know if anyone could do that.
This is just an order of magnitud above ESR lowly comment but it still missing the target.
"I think this line is mostly filler"
Microsoft effectively broke Java by extending it to allow the implimention of native windows widgets that wouldn't run cross platform and since Sun owns Java they were able to sue, and win. I think if Java were open source MS would be free to break it again. It's an old argument and one that we have heard over and over again but it has staying power, I believe, because it is true.
To borrow a phrase from John Stossel: Give me a break!
.Net for that matter. It's a simple matter of resources.
While Mono is cool project and, like many developers, one I've been following since it's inception, I don't see it ever overtaking Java, or
> > Which often benchmark faster than natively implemented code.
>
>You do realize that this is impossible, right?
What makes you say that? In fact, the original poster is quite correct. The JVM *can* generate faster code. You know how? By doing runtime optimizations. Compilers have to optimize for what *might* be the best performance profile at runtime. Also, they can only compile for the lowest common processor. (e.g. A pentium II) The Hotspot Java VM can optimize based on how the code is currently being used, undo an optimization if it starts slowing things down, and use processor specific instructions! Natively compiled code just can't beat that.
Javascript + Nintendo DSi = DSiCade
"Perl and Python are hardly competitors to Java, so warning Sun about Java's impending loss of market share to these two scripting languages is laughable."
How so?
The term "scripting language" doesn't have the name meaning it used to; especially where Perl and Python are concerned. They both get compiled to an intermediate form and executed...just like Java. The only difference (other than the internals of the runtime) is that the Java's development "model" is closely related to it's static typing; i.e., you manually compile your code into a binary before executing. Trying to discount Perl and Python by calling them scripting languages is silly. The real issue is what works as an enterprise development platform, not the "taxonomy" of the language. As far as platforms go, Python has got a pretty good thing in Zope/Plone etc. And both Perl and Python have libraries for damn near everything you'd want to do. J2EE may be more prevalent at the moment, but in terms of bang for buck Python and Perl present some interesting alternatives in the long term.
As soon as Sun GPL'd Java, it would start to diverge from Sun's commercial Java. Sun would not be able to incorporate changes made under the GPL into their corporate version. Sure, they could maintain their own "official" GPL version, but the dual license argument is complete rubbish. Java wouldn't die, but Sun would lose most or all control over it.
[J2EE] has replaced CORBA as the way to go for
.NET is satisfactory in this environment.
large, distributed enterprise apps
Has J2EE replaced CORBA in those scenarios where either the client or server is NOT written in Java?
One of the facts of life in the enterprise is that it is heterogeneous in terms of platforms, operating systems and (maybe) network technologies. Neither J2EE nor
You do realize that this is impossible, right?
No, this is not impossible. Read up on just-in-time (JIT) compliers and you'll see why. In a nutshell, the Java Virtual Machine profiles the code that is being executed, then uses sophisticated algorythms to anylize this information, then compile (while the system is running) native code from the java byte code, that is optimized for the environment, and more importantly for the ways in which the code is being invoked. Subsequent calls are executed by this newly compiled native code.
Thus the JIT compiler is able to (often) do a better job at creating optimized native code than a C++ compiler can do, because the C++ compiler doesn't have run-time analysis to use in its decisions of how to optimize the code. The JVM can continuously re-optimize the same code over and over during the life of the application. JVMs of today (and the last few years) do this as standard practice.
The article does mention that the only visible part of the J2EE iceberg (visible to the decision-makers, not the geeks) is webservers such as Websphere and Weblogic. It doesn't say anything else. It does mention open-source implementations.
What the author is talking about is a lack of the right communication from Sun on this matter. If Sun continue to advertise only WebSphere and WebLogic, they set the visible price very high.
Write boring code, not shiny code!
> Also, they can only compile for the lowest common processor. (e.g. A pentium II)
That may be true for traditional proprietary software, but NOT for F/OS Software. Witness Gentoo; I compile everything for my computer's specific processor. And surely you don't believe that the Hotspot Java VM does its optimizations 'for free'! Every runtime optimization check introduces a performance hit.
The most compelling argument he makes is the complaint about the complexity EJBs:
An Enterprise JavaBean (EJB), which is a component containing business logic, typically requires 5 to 7 supporting files to deploy.
This is the real issue that Sun needs to address. Java is widely used in enterprise apps because it is easier and faster (therefore cheaper) to develop apps. However, EJBs have some fundamental flaws that add unnecessary complexity and network overhead. I have developed apps for some of the busiest sites in the world and the requirements to strip the code down to the essentials are not compatible with EJBs. More times than not, EJBs are ditched in favor of a servlet-based front-end and a proprietary persistence solution.
It's simple: I demand prosecution for torture.
I fail to see how many of the article's points relate to Java being open source or not. While we could agree that Sun hasn't been marketing Java the best it could, what's wrong with Ant/XDoclet/JUnit not being developed/sponsored by Sun? Do we really want a single provider like we have with MS? Do we need opensourcing Java if we get many of the benefits as it is, and no bickering/forks/whatnot?
As for Mono... I will not state my opinion about Mono per se, it's not the point, but let me just say that Mono is trying to catch up on a Microsoft implementation. I fail to see how that compares with opensourcing Java, or even how it is a threat.
Just my two cents...
The revolution will not be televised.
That said, the fact that sucessfull open-source companies are rare (red hat anyone?) means that open-sourcing java is not gaurenteed to save the company. Simply put, your argument is incomplete at best.
Sorry, I am a bit picky about proper logic.
Laws are horrible moral guides, moral guides make even worse laws.
Qt may not be a language, but it does provide some language extensions via the Meta Object Compiler, which brings some nice things to C++. Also, Qt is not just a GUI library, but actually a whole Java-like foundation for C++. It's good stuff.
I'm not necessarily disagreeing with you, I'm just elaborating on what Qt is. It's closer to Java in nature than you might think, and with the upcoming Qt4 I can imagine it becoming quite a competitor.
Hmmm - didn't ESR inspire Netscape to following a similar path to "salvation" back in '98? (Netscape)
Hopefully (for Sun!) history won't fall into its old habit of repeating itself.
IBM is the first example that comes to mind of a company that successfully built a business model around opensource. I'm specifically referring to hardware and how IBM freely licensed the IBM architecture so that any company could manufacture and sell their own, competing, IBM Clone PCs. Perhaps you will remember the early '80's when Apple had all the market share, followed closely by Commodore and the IBM PC was a fledgling no company was worried about. What happened? They 'opensourced' their hardware architecture which Apple and Commodore refused to do. Within a matter of years Apple and Commodore were suddenly competing not just against IBM, but against scores of rival computer manufacturers. What was the end result? IBM-compatible PCs (clones) were far less expensive, parts were plentiful and easy to find, and all the software developers migrated towards DOS because that's where the market was... once that happened, most of the available software was also IBM PC-compatible which just further encouraged people to buy IBM Clones. Had Apple and Commodore been less stingy with their proprietary hardware technology, things could have played out very differently and today everyone might have an Apple and Microsoft might not even be around. But you might ask, "how is the free licensing that IBM implemented, open source?" It was open source because manufacturers were and still are free to propose and develop hardware standards designed to further improve the IBM Clone architecture and they don't need IBM's permission to do it, they need only to get approval from the various standards bodies. If this is not a clear example of how open-source has worked as a successful business model, then I don't know what is. Rather than fight over the market-share that Apple and Commodore owned, IBM just created an entirely new market -- far larger than the one it replaced. So what if IBM had to compete against their own technology they gave away to other Clone manufacturers? Which would you prefer: 10% of 50 million units, or 100% of 1 million units?
-- I'd give my right arm to be ambidextrous
They shouldn't use the GPL, they should use a new license which says its basically open source, so as long as you follow the standards for it set out by them. We don't want variants not fully functional and implementing things in different ways, so I need to have 15 Java VMs on my machine, and we don't want it to turn out like browsers where half of them don't support most of the standards making design a PIA.
I'm only replying lest the parent might be modded up.
As a professional Java developer who works primarily in Eclipse, Java is not your problem here.
Are you using a legacy app based around AWT? Then your GUI will most likely be annoyingly limited (with a couple of exceptions on MacOS X).
Are you using a GUI app using the Swing toolkit? Okay, yes, that's going to be slow -- I'll give you that. But that's similar to saying "Linux is ugly! Just look at (GTK|Qt|Tk|whatever)!"
Seriously, I'm tired of reading this drech on Slashdot. A properly-implemented Swing is reasonably fast (see MacOS X for an example), but unfortunately the Windows implementation isn't one. Before slamming the language, however, try changing toolkits -- I recommend SWT, as used in Eclipse.
> It is still to damn slow
My god, what sort of equipment are you running Java on, an abacus?
No, Java probably will not be used in the next uber-doom type progam, but for everyday usage type programs on fairly recent computers (built within the last couple of years) it's perfectly fine.
I'm getting the impression that there are a lot of really POOR programmers out who have no idea how to make a program run fast and use C or C++ as a crutch.
I also get the feeling that there are a lot of people out there who really haven't even tried a real Java application and just continually regurgitate the MS line.
Can someone please give me a refresher in how dual-licensing with the GPL works?
I know that MySQL charges only when the user redistributes its code for a profit, while internal use is free.
But the MySQL code is still under GPL, right? Doesn't the GPL require that the code be redistributed for free?
This guy must be a MS partner.........Most of the .NET development is taking place primarilly in Windows only shops. Also the great majority of .NET development is VB .NET.
After seeing how Microsft corrupted the JVM and developed J++ it's hard to see how moving Java to pure open source will help.
As for the desktop .NET is only strong because because it has the propietary features to lock people in.
While Java stays Sun's closed-source product, Sun retains control over it. Releasing it open-source would mean relinquishing that control forever. Imagine, if you will, the overthrow of an essentially benevolent dictator followed by a less desirable character seizing power.
The questions Sun needs to ask itself are (1) whether or not Java is ready for that -- or is it more likely that differing implementations would lead to fragmentation, and thus nullify the whole point of Java?; and (2) if Java is ready to go open-source {and I personally believe it is}, what would be the best licence to ensure against fragmentation whilst not putting off purists?
All these things being said, Java is only a programming language -- a means to an end. Programming languages come and go. There is no reason why another contender should not arise to solve the same problems for which Java was invented, and eventually displace Java. Mono may be that, of course. It is just as likely that something totally new could arrive on the scene and change the whole picture.
Je fume. Tu fumes. Nous fûmes!
Until a couple of years ago, it mattered to me that Java was closed source and that the Java specification itself was closed. (Yes, the Java specification is not open--you can't just implement it without violating Sun's intellectual property.)
Now, I just don't care anymore. Java has fulfilled its function: it has made garbage collection and runtime safety acceptable among commercial programmers. The Java language and libraries themselves are nothing to write home about and never were. Java could have become a good, general-purpose language and a good, general-purpose platform, but it never really fulfilled its promise. It's become a mediocre specialty language mostly for some kinds of server-side hacking. Open sourcing it or opening the spec would only prolong the agony.
People should move forward and widen their intellectual horizons again. Look at languages other than Java and get over this illusion that we will ever have a single language in which everything will be done on every platform.
My roommate just got mono and trust me, you want to avoid it at all costs. You're sick and tired and it lasts for weeks.
What were they thinking implementing SWT in Carbon. Even that is not an excuse for the slowness though. About the only full blown java IDE that is slower than Eclipse on OSX is Netbeans :(
seSales, Point of Sale software for OS X.
Please explain how this would be faster than writing the app in native code using an assembler and then I'll believe you.
Ok. My assembly is a little rusty, so bear with me. Let's say we have equivalent Java and C programs. They both have to run on a 386 or higher. (Bear with me. I haven't kept up with the MMX/SSE/SSE2 instructions, so I'll have to fake this a little.) Now, your C compiler will see that you want to store a 32 bit value, but has to generate code for a 386. So, it generates the code:
pop AX
STOSW 0x0005
pop AX
STOSW 0x0005
Even though the code may be running on a Pentium Pro (which is optmized for 32 bit code), it's still going to execute those 4 statements.
Now, the Java Hotspot compiler will start and notice the fact that you're running on a Pentium Pro. So when it converts the bytecode to machine code, it creates the following instructions:
pop EAX
STOD 0x0005
That's twice as fast as the C code!
Real code would tend to be running on modern processors, so this example is a little contrived. However, the JVM can (and will) use SSE instructions to do multiple calculations in one instruction, while the C code will be forced to generate non-SSE instructions to support the old Pentium Is out there.
Hotspot is also capable of analyzing the running code and regenerating even better assembly that would perform poorly in other circumstances. For example, let's say Hotspot notices that the bounds can't be exceeded on an array. Well, Hotspot will then recompile to remove the bounds checking.
Does that explain it better?
Javascript + Nintendo DSi = DSiCade
I don't understand why Sun is, on the one hand, so active in and dedicated to the GNOME desktop, whereas on the other hand, they're not doing a single thing about Mono becoming an important part of the desktop, pushing Java back even further.
Face it: Sun, one of the head developers of GNOME, is losing the fight of Java versus C#, which is the official language from GNOME (Linux)'s biggest enemy Microsoft. Where's the logic? I mean, if Java loses even *this* battle, then how are they ever going to keep any significant marketshare?
So yes, Sun should do something.
This Dutch company produces some interesting stats for those interested in the popularity trends of languages TIOBE Programming Community Index February 2004
You read that right, they went from PA-RISC to PA-RISC. Picked up a big boost in speed. It claims on some benchmarks it taking code compiled with -O, had performance like -O4 was used while compiling (they dont' cite a specific percentage in the abstract). Below is the link.
http://portal.acm.org/citation.cfm?id=349303&dl=AC M&coll=portal
Here's an old slashdot.org article about it:
http://slashdot.org/articles/00/03/23/106257.shtml
The link in there is the one that references the 20% speed up. I believe a lot of this type of technology has been silicon on the P4 (it believe some of the instruction cache/micro op trace cache stuff does) does runtime optimization.
This is essentially the same technology that is used by Valgrind (very cool debugging tool). Valgrind, doesn't do optimization, it does memory reference checks (ensures you never access memory for a read, until you have written there), and has a version that will compute the cache hits rate by each instruction. Now it slows down tremendously the code, but that's because it's not an optimizer, it's just a useful concept based on JIT translation.
So clearly JIT can create situations where it can out-optimize the best optimized code a compiler can construct. That isn't saying that a Java JIT can whoop up on a good C++ compiler, but it does demonstrate that what they are saying is feasible.
It's my understanding that the primary place where a JIT translation can just crush regular code, is that it can optimize across function calls, and it can optimize across system calls (system calls are function calls, but I know that the Intel compiler can optimize across some function calls, but nobody can optimize across system calls sanely).
A JIT, can do all the peephole optimization across translaction units, that a C++ compiler can't legally do. The other thing it can do, is write the version of the code that runs after if there are no aliases (I'm unaware of a compiler that does this, and it's my understanding that's a major problem for C/C++ compilers).
Kirby
However, if you put your ear to the ground, you will discover that Microsoft's .NET framework is finding its way even into such organisations as a "tactical solution" for smaller, departmental level projects. It is dangerous for Sun to ignore this trend. In the early nineties, Sun's workstations were far more capable (and far pricier) than the humble PC powered by a lowly Microsoft OS called DOS. Today, Sun has lost the workstation market to an evolved PC, running an evolved Microsoft OS, in spite of its initial advantages in power and openness.
Java never had a strong presence on the client side. I know of several financial software companies that are going with a java middle/backend and .NET front end. There are several reasons for this: the first one is webservices and the second is proven scalability of java application servers. I won't name the companies, but those in the OMS (Order Management Systems) industry will know this is one trend. Just google for it and you'll see several of the top companies are moving towards J2EE for the serverside. In fact the companies winning in the financial software world is changing as a result of OpenSource software and J2EE.
Rather than see Sun simply OpenSource Java, I would rather Sun do two things. the first is make it a real standard and resubmit it to a standard body. the second is provide a BSD style license of Java. When I say Java, I mean just the JVM/JRE. I work with .NET on my day job. MS has made great strides with .NET, but scalability for large systems still sucks big time. Websites that used to use ASP + MTS will see great improvements in reliability and performance. What they won't see is a great improvement in scalability. That basically means transactional systems that were hard to maintain and difficult to develop previously on windows will be easier to build and maintain.
A professional developer, who is open minded will already know this. The real problem with using .NET is if your business needs to grow to support large scale deployments, it's a dead end. Eventually, the system will have to be replaced with a proven J2EE solution. what do I mean by large? Large might be a transactional system that is message oriented and needs to handle 300-500 transactional messages a second, or requires distributed transactions. Doing these things in .NET still very difficult, but like these types of applications were ever easy. The fact is, .NET makes easy stuff easier to build, but for hard stuff, it basically can't do it well. That's where java shines. Java is harder to learn for simple stuff, but ultimately allows you to scale to massive levels, like handling 2K transactional messages a second.
Most companies don't need that kind of power and probably never will. Microsoft is strongest in small and medium/small firms. Ignoring all the PR BS, that world has remained basically the same.
Here
You'll need OpenOffice or (ewww) MSOffice to read it. Alternatively, there's a Google cache, but it isn't very interesting without the images.
Javascript + Nintendo DSi = DSiCade
No way. I can believe that - given certain conditions - a good compiler can optimise code better than an assembler (I believe it, but i've never seen it; I'm told that this is the case), but I cannot believe that an interpreter can. Maybe I'm living in the past. Please correct me.
Wrong on many counts. First off, Hotspot is a native compiler. It just compiles at runtime. Secondly, a good compiler can outperform a human optimizer because it can juggle such concepts as superscaler packets, out of order execution, and predictive branching. These are things that take a human a long time to calculate and figure out effectively.
BTW, it's been this way for 10+ years. It's just taken Intel processors a long time to catch up. And the *#$@ things STILL don't do SuperScaler right. Nor do they have enough registers. Or proper task switching. In fact, I think Intel still recommends not using the built-in task switch instructions. Blech.
Javascript + Nintendo DSi = DSiCade
Hopefully you (and those reading this) realize that Java has had Just In Time compilers for a long time now. Java code actually gets faster (if properly written of course) as it runs. I am sure Mono does this also but it is definitely not something that is exclusive to the Mono project.
seSales, Point of Sale software for OS X.
No, it doesn't. The second piece of code will not run on a 386 like you said it must.
Of course it won't! That's the point. The Hotspot compiler will generate the second piece of code because it notices you're using a Pentium Pro. If the JVM was running on a 386, it would generate the first bit of code, just like the C compiler.
Also, GNU GCC compiles code for processors like i686 that still executes on i386 by not using the i686-only instructions.
As much as I wish they did, not all OSes use ELF binaries. Besides, generating binaries for multiple processors creates a great deal of bloat in the binaries. Not to mention that the JVM will be able to optimize for future processers (when they come out) while the GCC binaries will only be optimized through the current processor.
Javascript + Nintendo DSi = DSiCade
I completely agree (with everything except SWT/Eclipse).
Everyone was talking about how Java is slow, and how it looks ugly, and we should do our app in VB.
My boss let me write it in Java anyways (with comments that if it did NOT perform well and look good, we might have to redo it in something else).
I passed it off to the guy doing the C++ remote server, and he was completely impressed with the looks and speed (yes, it was even Swing on Windows). I came into work the next morning to everyone congratulating me on a great UI, because evidentally it was shown off to everyone at the Pub the previous night.
The point is, there are a few problems of bad performance/look in Java UI... These are:
1) User is using an old version of Java, usually one that is end-of-lifed.
2) The coder wrote it in AWT
3) The coder wrote it in Swing, but without reading ANY of the documentation on Swing+Threads
4) The UI was patched & patched over and over, without designing it correctly first
5) The coder didn't utilize any look-n-feels
6) Bad threading design (ie: synchronizing when there is no need to, etc)
Is there anything that could be done better? Of course, otherwise there would be no one coding with the JCP. But, can you HONESTLY say any other language is completely perfect as-is?
I don't agree with your point about Eclipse/SWT though. I have a serious problem with needing to install any 3rd-party platform-specific java libraries... just goes against the whole concept of pure-Java, but then again, I am a purist. I also don't like the overall look of the SWT apps (some of the things like the disappearing Xs on the tabs annoy the hell out of me), and don't like the complexity that Eclipse adds to simple projects. I remember feeling the same way about JBuilder years ago, but to a lesser degree. Today, I write all my Java code in JCreator (or pico if I am logged into my BSD box), and use ANT to build with.
I am also tired of all the "Java-should-be-Open-Source" by people who have never bothered to spend 10 minutes looking into the JCP and how Java IS currently Open Source and how Java is NOT run exclusively by Sun anymore. Every couple days/weeks, I log onto Slashdot and someone else is making these presumptious claims without looking into the facts.
Just my 2 cents
http://www.google.com/profiles/malachid
Why is Mono a "threat"? Is it not possible for both to exist? Perl and bsh both exist on my machine and it doesn't explode even though they overlap in functionality.
According to popular legend, once all of Issaquah high school came down with mono.
I've never had mono, but it sounds like a shitty way to spend a month.
Yeah, probably three out of the total five programming jobs are Java. *sizzle*
Karma: It's all a bunch of tree-huggin' hippy crap!
This is the real issue that Sun needs to address. Java is widely used in enterprise apps because it is easier and faster (therefore cheaper) to develop apps. However, EJBs have some fundamental flaws that add unnecessary complexity and network overhead. I have developed apps for some of the busiest sites in the world and the requirements to strip the code down to the essentials are not compatible with EJBs. More times than not, EJBs are ditched in favor of a servlet-based front-end and a proprietary persistence solution.
I don't mean this negatively, but if your problem is simple enough to solve with servlets then use servlets by all means. And yes, Entity Beans suck and should be avoided at all costs. And much of the time EJBs are overkill.
But if you need clusterable objects with failover and seemless transaction support nothing is easier than EJBs. Go try and do some CORBA or DCOM programming and see how complicated is can get. More power=more complexity.
Brian Ellenberger
If you want to read quite a bit of diffrent views on the subject there are several threads on http://www.javalobby.org I think they cover this topic in painful detail. My favorite quote is by Guillaume http://www.javalobby.org/thread.jspa?messageID=917 90106&threadID=11559&forumID=61
That is kinda cool actually. Now let's write a JVM in Java!
Done.
google for RVM, research java virtual machine. An IBM project.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
One interesting thing the article brings up is XUL. Since it seems to do so well provided a pretty platform is written to run it, maybe it would be a good idea to, as they suggest, get it standardised at the W3C.
Actually in general, I feel it would be a good idea for Sun to start pushing towards an architecture which allows for server-side (in the X sense, where the server is the terminal) widgets, whether they use something like SWT (which will never happen due to wars with IBM) or even an improved AWT.
Server-side widgets would make the client even thinner, and if it were all in script you could just use the same code on all platforms and the rendering mechanism would determine how it looks. Maybe if Y-Windows ever takes off you could even have an implementation for that, and things would be lightning fast. :-)
Karma: It's all a bunch of tree-huggin' hippy crap!
Well, you're right, but there tools that do profiling for C/C++. This thread should rather be named "(JIT) Bytecode vs native code"
.NET, but from what I heard, multiple frontends for arbitrary languages are possible.
Java".
The front-end languages C++ or java don't really do much about the perfomance (except that you can manually optimize things you can't do in java because of missing pointers etc.) (*)
IMHO, java bytecode suffers from the following things (and so do the users of java programs) - [they are the reasons,I think, why all java programs I've seen so far (and all the not-for-java-crafted benchmarks) are running considerably slower than C/C++]:
Technical:
- Java bytecode is low level enough to lose certain optimizations (JITs have to apply decompilation techniques) which you can do in C/C++. You can of course compile Java natively (e.g. with gcj), yes. But then, you lose portability.
- Java bytecode is not low-level enough that you can take advantage of the features of the particular hardware. Java's ints are 32 bit. What if you run your numerical java code on 64 bit machines?
Political:
- The java bytecode format is so specific that it is impossible or rather hard (there was once a java backend for egcs, admitted) to get other languages like C/C++ to run on it. Why does one have to chose the platform java with the language java? I don't know
I'd like to have a VM for C++ *and* Java. That would surely rock and end some of the flamewars.
(*)- The often stated security argument (java has no pointers and is therefore inherently more secure than C++) would fall with C++ on a VM.
I read the f***ing article.
.... probably the article has some insights but the start is way off.
... 3? Probably 3. Not sure.
... 10? 15?
... why should SUN "Open Source Java"? What bullshit idea. Probably there are indeed reasons to do so. However, the article completely fails to show them. Heck! Why should Mono be a competition to Java? Why should Mono, Open Source, cool ... Microsoft .Net, not Open Source ... cool either, why should that be a reason to Open Source Java?
... Closed Source, commercial ... discussion just sucks. Mono or .Net are no competition to SUN/Java.
.NET is a platform also, Java is a platform as well, also. But, the heck, where is the relation to Open Source in that regard?
... as Deutsche Bank buys not JAVA, they buy consulting.
After the 5th paragraph I stopped reading. After the 5th paragraph the new headline "Rephrasing Eric Raymond" I stopped reading.
Sorry folks
If I count commercial, non open source, Java implementations I count
If I count open source java implementatinos I count
Why
Man, this Open Source
Why should PERL be a competition to C++? This "are programming languages"!!!!! Sure,
Do you think any german customer, using Java takes a shit if it is Open Source? I would bet that 90% of the german projects done in Java, just download the JDK and code it, and thats it. No SUN, no IBM, no Open Source, no idiology involved.
Why the heck should anyone care if it is Open Source or closed? Especially if tehre are 5 times the Open Source implementations existing than closed ones? Especialy if none of the open ones are used in commercial projects?
Do you really think "Deutsche Bank" would "take" an Open Source java implementation for their next Enterprise Portal?
No, they take the CPL SUN implementation, or the semi open AIBM implementation, or the Apple colsed source implementation or the HP closed source implementation or the BEA JRocket, closed source JVM or any other closed source JVM.
SUN has absolutely no benfit in a contract with Deutsche Bank about a offering an Open Source Java
Using any JDK and Deploying any JDK based application is FREE as in BEER regadless which JDK you use, SUNs, IBMs, HPs, Apples.
The real world does not care if it is free as in SPEECH as long as they dont have to PAY FOR IT.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Its full of contradictions and silly mistakes.
.Net be a threat when Microsoft is struggling (making a loss!) on the server side? Unless the Mono folks unwisely give Microsoft an escape route, the eventual rise of Linux on the desktop will squash .Net flat. This rise is starting: I develop websites for international use. If I deploy anything that requires Microsoft on the client (as do .Net apps), I soon get enough complaints to convince me otherwise!
J2EE is small and easy, not large and expensive. Anyone can build JSP pages or use Servlets on a free but high-quality App server like Tomcat - this may not involve Enterprise Java Beans (the least used aspect of J2EE), but its still J2EE and it costs nothing.
How can
Why does Java need to be Open Source to ride the Linux revolution? High-quality Java VMs are ready for Linux.
Java is the most widely requested language for development, and its use is still rapidly expanding. Sun has nothing to fear.
It's more important to get binary packages qualified (FreeBSD...). But other than that, come on, Java can be used pretty much unencumbered. What's the problem for end user apps?
Heck look at the wave of new cellphones, they all have Java and Real as far as I'm aware. This is also where the DRM fight is going to be, not on your PC (otherwise I don't use the little plastic critters at all -- don't ask me).
"The GPL is also the only Open Source license that can keep Microsoft from "polluting" Java."
If Java is Open Source. MS can change it all they want from the Sun standard. The only stipulation is that they then must release their source code. MS would love this as it puts them in a far better position than they're in now, where they're not allowed to ship non-compliant versions of Java as ordered by the courts.
Vote for Pedro
Don't believe me? Don't take my word for it.
so you're saying the jvm can do just-in-time optimizations ... ok, I'll grant you that. It CAN be a benefit. but let's take things with a grain of salt here.
(*)optimizations are expensive. compilers do multipass optimizations routinely.
(*)jit optimizations have to come in parallel with the running code and this sucks resources in the beginnig.
So it boils down to something like a long-running java app might eventually end up as fast as, or faster, than a C/C++ counterpart. That is open to debate. The thing that is more certain is that you usually get better maintainability for java when changing platforms/instruction sets. This is tautological, as it comes from the very idea behind java.
The reason why I believe your argument is open to debate is that there are only so many optimizations the language will allow. It's not just a question of generating the machine code (although that comes in too - and it is expensive) Look at the long-standing issue of the language of choice for HPC - Fortran. C++ is so much better, but the compilers are not allowed to do optimizations as aggressively for c++ as for fortran. Hence, C++ code tends to be slower than Fortran code. Plus, there's always language overhead.
Bottom line is, there are always the 2 extreme cases and the 'in-between' ones. Java can be fast, provided you have the right combination of code (including coder) and jit compiler. But the same goes for native compilers as well, and in the real world this 'match made in heaven' rarely occurs.
Very observant. My original reply was to the poster who said it was impossible for the JVM to run faster than native. However, I realize that real world code is likely to be impacted by the time it takes the Hotspot compiler to do optimizations. (That's actually one of the reasons that Java has been such a good fit for servers.)
.5% increase in performance is not going to make a lick of difference when your code is only running for 300 milliseconds at a time. And in that 300 millisconds, a few hundred million instructions get processed.
Now here's the catch-22. All this stuff about making code perform better on the processor is BS. Unless you happen to have a platform designed for HPC (such as a Cray), your processor is otherwise spending that time doing nothing. (Memory wait states, cache misses, and other annoyances.) The thing to pay attention to is that the lost cycles don't matter. A
Unless programmers have a justification for a few thousand extra instructions a second (e.g. crypto cracking), their time would be better spent writing portable and maintainable code. The time they save from that maintainability can then be put into adding new features, and making their applications that much better. Especially since Java excels in the area of libraries. Dream up the most complex program you want, and I'll guarantee that 60-90% of the hard work has already been done for you.
Compare that to DLLs and staticly linked libs. Using C and C++ libraries back in the day, was more an exercise in frustration. Eventually you just said, "screw it!" and rewrote it yourself. Today, there are some very good libs for Unix, but there is still nowhere near the wealth of libs as Java has.
Javascript + Nintendo DSi = DSiCade
Something that often crops up in the C/C++ versus Fortran discussions is pointer-aliasing. The inability of C/C++ compilers to really optimize around the problem of pointer-aliasing is a non-trivial problem and impedes the performance of those codes.
Now, I don't program in Java, but I understand that Java pointers are "smarter" than C/C++ pointers and that the JVM may be smarter at determining aliasing and be more aggressive about optimizing. If (again, I don't know, but I'd be interested in knowing) this is true, then it could be relatively easy to imagine situations in which a JVM (with appropriately aggressive optimizations) can execute code much faster than C/C++ compiled code.
I always get the shakes before a drop.
I say this after watching some very simple, no-GUI programs translated straight from C++ to Java code. No extras added, bare minimum amount of work.
I wont dig for the Slashdot article but a OSS article covered a benchmark showing Java running as fast (and sometimes faster) than C++. One thing poorly done though in Java was trig functions.
Java does come with some baggage you wont find in C++. Mainly thats the garbage collector. But then again, you cant get a memory leak in Java which is very simple to do in C++.
But once it reaches a certain level of complexity, I'd rather save the CPU cycles and go with something better.
I mix the two. Theres two ways of doing this: JNI or CNI. The Java Native Interface is okay for accessing C code from Java. The Cygnus Native Interface (see gcj) treats every java object as a c++ object which makes using the two languages together very easy. Oh, and GCJ allows you to compile to native executable rather than byte code if speeds and issue.
Now, I dont see java becoming a mainstream staple for game development or heavy multimedia. But I could be wrong in the next couple of years.
I have to say you are atleast honest and explained your views. Many Slashdotters give the "its slower than dirt" and generally have no idea what they are talking about. I myself play all sides and just know the strengths and weaknesses of the different languages and dont play favorites. Its the best way to be IMHO.
Kind of like how Linus Torvalds completely lost control of Linux? </sarcasm>
Sun would retain copyright and the right to relicense or dual-license. The scenario could be parallel to Mozilla or Qt, but with Sun Java's existing huge userbase.
If the JVM (at least) was Qt style relicensed GPL, we might perhaps see some performance enhancements on Linux, as well as integration of Sun's JVM into GNU/Linux distros like Debian and Fedora Core. Sun would surely like that.
This makes a lot more sense than relicensing under BSD, as that would enable MS (say) to quickly release broken/incompatible JVMs in their future OSs without breaching their legal obligations and without giving the source away.
To sum up, My answer to your query (2) is 'GPL'.
A long time ago there was the MS Java JIT. It loaded up and ran Java applets and played nicely with others. The web was browseable and never caused the evil BSOD to appear. However, the father who never liked this child wanted to push their own JIT upon the people. It was known as the Sun JRE. It didn't like Windows, and often crashed it out of hatred. A great many web pages were blockaded by the JRE. It brought the terrible BSOD any time it could.
To be continued....
-]Phreak Out[-
We just scaled a single server asp.net solution to a 5 server farm without a single code change or recompile.
:p
I did have to change one line in the web.config file though. I guess that 10 minutes of my time isn't a great improvement in scalability?
This was just published an hour ago:
IBM on Wednesday sent an open letter to Sun Microsystems urging Sun to make Java technology open source, CNET News.com has learned.
In a letter sent by Rod Smith, IBM's vice president of emerging technology, IBM offered to work with Sun to create a project that would shepherd development of Java through an open-source development model. If implemented, portions of Sun's most valuable software asset--Java--would be freely available, and contributors ranging from volunteer programmers to large corporations would submit changes to the Java software.
http://news.com.com/2100-1007_3-5165427.html
I call bullshit on this. If Sun released a GPL'ed version of Java, as they own the copyright to it, they can include whatever changes they made in their GPL'ed version into their own commercial version. On top of that, as they own the copyright to the name "Java", they could set the standards (as they already do) where if implementations did not conform to their standard, then the implementations could not be called "Java".
The real danger, which until now fortunately has been avoided, is when developers are presented with the choice of either having to open their source code when using the GPL Java, or paying Sun a fee for using the commercial Java. How can this be considered more "free" than the current situation where you can do what you please with your own software? If you want to GPL your software, go ahead. If you want to keep it closed, you are free to do so.
Currently as far as I understand you can implement Java any way you wish, as long as it conforms to Sun's standards. Isnt this what the OSS community has been calling for? Open standards? This appears to present us with both the advantages of OSS and commercial software. A central controlling body for the standard, with the openness to implement how anyone sees fit.
I am Monkey, the Great Sage, equal of heaven!
First, I do know WFT[sic] I'm talking about. I've used quite a few Java apps, from Ant to Netbeans to a little JSP/Servelets. I've also written a lot of C++ and C. It's ridiculous to say that Java is always as fast of faster than C and C++. In certain heavily optimized situations, it can be. But simply due to the extra overhead from GC and the VM, there's a significant slowdown compared to any language that compiles to native machine code. I'm excluding Java code that's natively compiled, because that gives up much of what makes Java good.
You're completely avoiding the real issue here. You can say "Java is as fast as C++" as much as you'd like, but that doesn't change the fact that most Java apps ARE slower to the end user. This may be because the libraries aren't loaded or the UI isn't as responsive, but the bottom line is that Java isn't keeping up.
You refer to "cheating-ass windows programs". I assume you're referring to programs like Office or Mozilla who have a quickstart option that loads the program into memory on boot. That's a whole different issue. Most native code programs start fast because there isn't much to start up, not because they cheat. There's a lot more to it than that, but my post is getting long already, so I'll explain the rest if you really want to hear it.
In short, just because a lot of people claiming Java is slow are idiots doesn't mean that you can just dismiss their complaints. There are a lot of smart people who want a faster Java too.
Karma: Contrapositive
Take a look at .NET
.NET with all it's propietary extensions to the standard. The standard itself is gonne mean nothing.
IT has open ECMA specification - and Microsoft made a great P on that.
But the real programs will be made upon MS
Projects like www.DotGNU.org understands it well, so they are running behind (and trying to chase) the very MS libraries, not only the standards.
And Microsoft said that it is their strategy - add new technologies so fast, that competitors have no time to invent their own one.
Why? Well remember JVM and how Microsoft corrupted the compatiablity? Java's goal is to be cross platform and to do so means there needs to be a centralized development effort. If suddenly there are 50 versions of J2EE on the market, each with its unquie traits, which do I run? How do I know that the app I program will work on the others? If it doesn't run on everything, hasn't the point of Java been defeated?
I once worked for a company that was looking to port some of its Solaris & AIX Applications to Linux, but 3 months into the project, the question became what distros to support. They tried porting their application with some modifications. Got it to run fine on RedHat 5.x (it was a while ago), but then it took some playing around to work with SuSE and we never did get it to compile on Slackware. When they said they planned to support RedHat default only, meaning if system admins were using a tweaked box or kernal, we would not offer support. Needless to say, potential clients scoffed at the idea and after 6 months they decided that the Linux Market wasn't worth the hassle until some standards had emerged. This is why a lot of developers won't port to linux, especially desktop applications: too many variations.
I see the same potential of Java, to become slpit into so many forks, that it defeats the purpose in the first place.
I like opensource applications, but I don't think that Opensource is always the answer. Another good example is a good friend that is developing a support ticket application for the company he works for. I asked him, "Isn't there several GPL'd apps outhere that could installed within a couple hours?" He responded of course, but he put it this way: "I like to use my own code and not other peoples. Its a lot less messy that way." and I see his point.
IF it wasn't for opensource, I would have never learned how to program in PHP, PERL, and various SQL databases, it was a great learning tool, but like every tool, there is the correct tool for the job. I say this as I switched from Linux to Macintosh almost two years ago now and I am willing to pay for the luxury of having everything work. Just like we now pay for managed instead of self-managed servers for our business. There is only 3 of us and we now have enough business that its costing us more to run our own servers than to pay a little extra for managed services where the keep up with the updates and such.
All I am saying is that projects have goals. Sometimes Opensource meets those goals, but its not a cure all. The beauty is that we have the choice of using Opensource or to use a propritary solution.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
While Java stays Sun's closed-source product, Sun retains control over it. Releasing it open-source would mean relinquishing that control forever. Imagine, if you will, the overthrow of an essentially benevolent dictator followed by a less desirable character seizing power. I'm getting sick of everyone saying this - Sun has actually given up a lot of their control with the introduction of the Java Community Process. Please research you facts! Will.
I seem to have missed the facts part... too.
.NET system that is getting scaled right NOW to zillions (approx.) of users.
Orkut is another example of a
Granted they are hitting some bumps, but I've seen java based shopping sites with bigger problems and fewer active users. They ended up taking the site down for weeks. Not to mention the site was unusable while up.
Just goes to show that it's not the language... it's how you use it.
Interactive Visual Medical Dictionary
the GNU Compiler for Java (GCJ) posted a very nice and
much more pragmatic request to Sun. Reproduced below:
rmathew.com
First of all, I'd dispute that Flash has "taken over for most web apps and games". Much is done using Flash, but Flash script is scarcely an industrial strength general-purpose development language. Many of the major web-apps and games are in Java, see "Yahoo Games" and many others. Many "web-apps" are server-side, in which Java thoroughly dominates.
Whatever advantages Flash has are simply largely related to being endorsed by Mr. Monopoly - Microsoft. Web developers, being able to count on Flash being there bundled with IEEEEEEE (pronounced Aieeeeeee!;) simply went with that rather than risk user disgust with a JRE download and slow Java startup times (due to no pre-load with the browser)s.
Sad, but true.
Sun's recent bundling deals with major PC OEMs, as well as more general broadband availability may help, but Java now has an uphill climb as far as applets go. Fortunately, full-blown Java apps (including those using Java Web Start) are more interesting anyhow... :-)
jFlash is interesting as well...
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
I think it basically comes down to design intentions. The Oak project was intended to provide WORA with a sandbox model to reassure people that it was safe to run applets. The CLR, OTOH, was designed to allow people who already knew any VS language to write for .NET. I don't know quite what that means in terms of sandboxing, but I haven't noticed MS release an applet-style plugin.
As far as getting C/C++ to run on a JVM is concerned, I think someone with enough dedication and compiler skills could probably write a compiler which got most of it to run. Most pointer idioms can be rewritten, autogenerated mixins can simulate MI. Variant fields in structs could be tricky, although I think they could be hacked up. The question, though, is why people would want to run C++ on a JVM. Surely the reason for using C++ is obsession with speed or a desire to do really low-level stuff? If you're obsessed with speed, you should take to heart the mantra "Don't optimise. (For experts) Don't optimise yet", and if you want low-level stuff then you don't want a VM in your way.
As a .NET developer I'll be up front and say over the long haul I sincerely hope that Sun don't Open Source Java. More specificallymy hope is that Sun keeps Java closed for at least another 3 years.... I fugure it's going to take another 3 years for .NET to mature as a cross-platform prospect.
.NET developer you can't begin to imagine the childish glee I get from saying to Java developers... "my platform's more open than yours."... to which I'm quickly told "but there's 5 Java jobs for every .NET one", and I have to shut up.
.NET... I can't believe the OS community will stand and defend Sun when it's setting them up for such humiliation.
.NET is more open than Java.... the Mono CLR on Linux is more open than the Sun JVM on Linux. You can't dodge that.
IF... and it's an if, it might never happen... Mono matures over the next 3 years it is going to be absolutely excrutiating for the Open Source community to justify a closed Java.
As a MS
And yes it's incredibly childish, but at least half the motivation behind any platform comparison is childish spite that exposes the facet of a developer that has more in common with a cheer-leader than anything else.
More seriosuly Java has 3 years to go open or the Open Source and Free Software community will have it's nose rubbed in
We could argue the detail, we could justify, but
What the Open Software community should be doing is screaming blue murder at Sun, not sticking their fingers in their ears and saying "nah nah nah nah, it's not happening, it's not happening".
Sun has lost control of the Java development space. It does not provide leadership anymore or set the agenda. Open Source does.
There is a wellspring of innovation in Open Source that beats the productivity of Microsoft's friendly tools.
It mentions the JCP but ignores the power of that organisation over the OSS world. Open Source certainly does NOT provide the leadership in the Application Server space, BEA, IBM and SAP do. Open Source does not provide leadership in the IDE space, BEA, Borland, Compuware and IBM do. Open Source does not provide leadership in the J2ME space, Sun, Nokia and Ericsson do.
What annoys me about this article is its assumption that XDoclet and Ant can be compared with a J2EE application server. And that _standards_ are not important. The JCP is the key to all of this. In the same way as Ethernet won because it was a standard the JCP lays down standards for the Java space. ANYONE can take part, it doesn't even cost you money. And you can have a say in the direction of the platform, in a much more direct way that you could have with Linux for instance.
The point this misses is that Java has not succeeded as well as it has by being fragmented, it has succeeded because it is standardised. The JCP enables all of the partners to determine what goes into the platform. Sun propose JSRs, but so do IBM and BEA... and Oracle.... and SAP... etc etc etc.
Open Source could learn much by looking at the JCP.
Consider Wi-Fi, why is 802.11x successful ? Because its all open source ? Or because a regulated standard works well in a commodity marketplace.
Sun with have commoditised the Application Server and Mobile platform spaces. The JCP has for several years been the key to that success.
The trouble with Open Source advocates is sometimes they see everything as a nail.
An Eye for an Eye will make the whole world blind - Gandhi
I don't know about the libraries, but Sun should definitely open source the JVM. I mean that's something where Sun would really benefit, and would still maintain control. Much like the way Apple benefits from developers working on Darwin, without losing control of OS X.
Then it's conceivable that GNU, IBM, Sun, and Apple could all work on a unified JVM.
Are you saying that the problem is that they can not download it and put it on the Debian CD for redistribution?
Yes. Other more subtle problems of a similar nature lurk here as well.
If that is the entire problem, why can't they do it like the BSD port system, where the makefile downloads the most recent one and installs it?
That isn't the entire problem, but even so a BSD like port system is not a good solution for everyone. For example it doesn't work well for people who have low bandwidth or inconsistent connections. Obviously you're right to point out that Java is somewhat accessible to Debian and FreeBSD users, but that is not what Open Source means. I use the Sun JDK on Fedora for everything GCJ doesn't currently do. Still, significant problems would be solved if Java were more open.
I am not clear why you prefer AWT.
I am more pleased with the concept of AWT than with the actual implementation. As you say, it is dreadful. However, as I understand it -- do correct me if I'm mistaken -- Swing is built on top of AWT, which means that while it doesn't have to be slow, it can't plausibly be much faster. Also, AWT is certainly as cross-platform as anything else in Java.
Do you mean that the look and feel varies by platform? I consider that a good feature in principle since I prefer applications to be consistent across a desktop. Clearly that's a matter of taste though, and there's no accounting for it. Naturally the lack of GTK+ and Qt based AWT implementations makes things much uglier than they need to be in practice.
I usually find myself implementing lighweight components in AWT, but then I generally use HTML and forms backed by Python for everything they can support and wheel out Java only for custom widgets. I suspect that if I were writing entire applications with Java I would grudgingly prefer Swing in spite of the look and feel issue.
Since the Java chips are 32-bit with only 8-bit operands, they are able to grab 4 instructions and use 1 every clock cycle, [...]
This is not an advantage that is unique to Java. Donald Knuth's MMIX architecture has the same property and there is a GCC back-end so C, C++, Fortran, Java and other languages can be used with it easily. Unlike the alleged .NET language neutrality no changes to syntax are required. Even standard libraries only need to be changed enough to make low level system calls work.
What do you mean by ["the advantages of Java are application focused"]? Do you mean that it is no good for server software (which it is even better for than GUIs), or do you mean that it is not good for things like device drivers?
I mean the latter. (I don't dispute the utility of Java for server software, but I prefer Python for a variety of reasons.) Well, actually, I mean that the advantages of Java are not especially compelling for system software in general. A Write Once Run Anywhere kernel seems a bit nonsensical. Similarly, running system daemons on top of a virtual machine seems unlikley improve anything.
USB device drivers are an interesting counter-example, though I think the notion that software which communicates with a device over a USB bus is a "device driver" is a bit misleading and conceals what makes USB great: it transforms something that was once clearly system software into something more like application code.
Every single time you see any application crash in your OS, that is a runtime exception.
That's an interesting way of looking at things. Are you saying all exceptions ought to be checked exceptions? Does that include NullPointerException and OutOfMemoryError? Plenty of shoddy software that doesn't deal with these gets sent to customers. What makes exceptions useful in the first place is that they allow parts of a program to ignore problems that they couldn't reasonably do anything about. Checked exceptions take that advantage away, often tearing enorm
Not all those who wander are lost.