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."
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.
The problem is the way Java is being developed and maintained as a proprietary programming language base.
There are two major Java implementations currently in use -- one by IBM, one by Sun Microsystems. Both of them may come without charge, but are without the freedom that would make them qualify as Free Software.
Therefore, all software written in Java (even software under a Free Software license) running on such a platform will "put the user's freedom at risk" (a quote from FSF/GNU people). It's like running Free Software on Windows.
If you want more detailed 411 about the status of Free Software versions of Java, hit up the following URL:
http://www.gnu.org/directory/devel/prog/java/
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
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.
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.
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.
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 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'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.
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
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.
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
You can consider it whatever you want. However, there is an official Open Source Definition that most people mean when using the term. Also see the Debian Free Software Guidelines (DFSG). Sun's Java process, though fairly open for a commercial software product, doesn't comply with the letter or the spirit of either of these.
This the first time I've ever seen someone blame a language specification for allowing the use of libraries.
FYI, I can write a Java app that requires MS DLLs as well. It's not the fault of the language.
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.
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.