Slashdot Mirror
The "Return" of Java Discussed
An anonymous reader writes "Following on from the marvelous recent James Gosling interview highlighted in Slashdot last week, it would seem that a renewed momentum is building up for his cross-platform creation, if this editorial is anything to go by. It's called 'Java is Back!' But did it ever go anywhere?"
Java is a nice choice for embedded platforms. It runs several times faster than on PCs (it's native for the hardware, not "emulated" through JRE), the hardware is inexpensive and can perform really sophisticated jobs. I think it may be one of major reasons for Java to take up so much.
Java powered cryptographic iButton - a chip the size of your hand watch battery (stainless steel, shock-resistant, water-resistant and several other-resistant "iButton" package) with Java support.
Anagram("United States of America") == "Dine out, taste a Mac, fries"
Java now has an astounding array of libraries to use these days. Look at for some good ones.
[% slash_sig_val.text %]
``Java is slow, obeist, and heavy.''
And anybody who doesn't believe this might want to take a look at why kast wasn't written in Java. People have been telling me that I am the only one experiencing these issues, that I simply don't have enough experience, or that I should take a look at modern JVMs - well, here's one example of people who tried Java and were disappointed. The same happened to many LimeWire users. The list goes on.
Please correct me if I got my facts wrong.
Java is "slow" because Sun has give us a brain dead GUI components. If you are looking at server side running things like EJBs, JSPs and servlets it is just as competitive as .NET framework.
There are a lot of pending improvement on Java GUI front, like Eclipse Rich Client Framework using SWT and hopefully it will not be "slow" anymore
Java is a great language that people avoid because it's a pain in the ass.
Java 1.5 goes a long way to help that, what with iterators, autoboxing and such.
I don't do Java, but from what I've seen, it doesn't change much, and where it does, it adds to what was there before. That is IMO a good thing, that developers aren't sitting around poring over documentation, but are productive instead.
(One reason for not doing Java is the small number of companies doing Tomcat hosting).
Sure, the same thing written in C or C++ probably would be faster - but when you literally can't tell the difference, who cares? A modern PC spends almost all its time waiting on user input or IO bound anyway.
For a long running enterprise application, it would probably be SLOWER in c/c++. No matter how good you are at programming c/c++ you can't anticipate every little bottleneck and write it in perfect assembler... but the hotspot compiler can do that rathar well.
"Your superior intellect is no match for our puny weapons!"
I'd win hands down. .NET
.COM
(386 000 000 results)
versus
(1940 000 000 results)
Anagram("United States of America") == "Dine out, taste a Mac, fries"
No it won't. Server-side programming (i.e. "enterprise") means backwards compatability is very important. MSFT cannot afford to break it in .NET either.
.NET is years behind and plans to bring similar features only in 2007 (generics). It remains to be seen if they can do it without breaking backwards compatability. They already have a very hard time to convince their current developers to switch to .NET, they cannot afford to make their developers have to migrate once more in the next 10 years. .NET being so poorly designed I truely wonder if they can improve it without disturbing compatability. I cannot see it being a threat.
.NET would only be considered for fat client GUI's which used to be done in MFC. So even if .NET becomes a success, it will only replace parts that were already done in MSFT technology before, it has zero chance on the server side.
SUN has done an amazing job in extending Java even to include generics without breaking backwards compatability. Yes it did not lead to the solution that is technically and internally the most efficient (it would have required changes to the JVM), but the developer is not affected. Internally it is solved by typecasts, but who cares? The compiler, it cares and verifies and tat is what matters.
I work in a large company, and all new development is done 100% in Java (except the mainframe parts, in PL/1 but that is declining rapidly).
"And thats the real big difference to mono. Java may run on any Computer since 92' till 2050, without need to take care of what Microsoft will change in 2 years."
Let me correct you slightly. There is always the need to make changes to adapt to what MS does. Its just that with Java that responsibility falls to the JVM writers and not the application writers.
A windows JVM is just another windows c/c++ program. Many people keep forgetting that.
I wont complain too much regarding the j2ee (or even j2se), but j2me..... I am telling you, I have 2 phones, and I can tell U it's not easy to find working java application for them. It's not like, "down load this if you have a java phone", it's more like "if you have this phone, download this, if you have that phone, download that, this application doesn't work with those phones bla bla bla. I have to spend to much time trying to find the right download for my phones. How the developers feels... I found an informative blog which sums it up.
> but the hotspot compiler can do that rathar well.
Unless it shows some bugs on "obsure" platforms like AIX. A sequence of a.foo(); a.bar(); a.baz(); executed foo() and baz() but not bar(). It turned out to be a serious defect of the hotspot optimizer, which simply optimized away the call to bar(). Another bug was that sometimes, threads simply disappeared into nowhere. So, we decided that, instead of letting Java drop threads, we would drop Java on AIX.
A monkey is doing the real work for me.
I never thought of Java as something worth following, because it was my personal experiece that: - it is slow - files are biiiiiig I mean, running some Java app makes the fan of my Powerbook spinning. Face it, only Photoshop and Imovie do that to me ...
... Sun (or Nokia, or whoever) has done a great job there.
But in Europe Java is really strong in the mobile phone environment. I have this SE 900 and it always draws lots of attention and things that strike me most are remarks of non-technical people, like the 16 (or something) year old girl at some fast food joint: "Does it have Java?" Even my sister (30, knows shit about computers) has it on her wishlist: a Java enabled mobile phone...
The fact alone that it is seen as some 'special' thing
In addition to nets as trapping implements, consider the common "sentence"
Your statement is as correct as saying that Java is slow.
Java is not slow, but it's slower than a good C++ code; consider these words from Stroustrup:
When you get to percents, 10%, 50%, and such, you start arguing whether efficiency matters, whether next year's machine will be the right solution rather than optimization. But in terms of dynamic versus static, we're talking factors: times 3, times 5, times 10, times 50. I think a fair bit about real-time problems that have to be done on big computers, where a factor of 10 or even a factor of 2 times is the difference between success and failure. (http://www.artima.com/intv/abstreffi2.html)
So yes, the average C++ programmer will write not the most efficient code (as Stroustrup compares differences in a factor of 50 between bad and good codes), and the Java's Hot Spot will then easily be faster than the average code. But remember that the Hot Spot can only guess what you are trying to accomplish; a C++ compiler can actually see what you are trying to accomplish. C++ compilers are not dumb, they can do really good optimizations (when you write good code, of course).
PS: using "C/C++" in a sentence comparing them to Java will make you look like you can't differentiate C from C++. Don't be so incautious unless you wanna be flamed by the "C++ is not the same as C" crowd.
There is this concept called MVC (or model view controller) That is regarded as the way to develop OO based GUI apps. However, pure MVC is the biggest stumbling block to performance.
The idea is, you have a VIEW (The actual GUI Code), that reads it's data from the MODEL, ( a data structure modelling the data that is viewed, and a CONTROLLER, that the view notifies when something happens, and then the controller updates the Model.
This, though well suited for a Web application, does not work well in a windows type environment. Consider for example an order entry screen consisting of 10 dropdown combo boxes, Buttons to add an order line, Tabs to show different areas of the order, (delivery address, customer credits, etc). Now the data model for this screen will be massive - each combo box's entire list of values will be stored within the single Model. On start-up, first the view will be rendered, then the data contained within the model copied into it. This process takes time, and makes the guy unresponsive and sluggish. In a Web application, this is not a problem , as the data has to get to the browsers some way or another.
With Java Swing, there is an alternative - Encapsulate the individual components with the data it requires to display, and only store within the external Data Model, the actual value that the component is set to. Eg, if you want a combo box with a 100 or so currencies to be selected, store the list of currency information, together with the combo box..... Call it a currencySelector or something. The 'Data Model' is still there to contain the actual chosen currency, just not everything else!
This way, you can cache up these components, so when added to the screen, no time is wasted moving all this data from the data model into the component. The data model becomes much smaller, and the components become fully re-useable.
The Swing applications I have written use this technique, and are easily as responsive as a native Windows Application....
Untill industry realises that MVC is not all its cracked up to be, we will be stuck with slow gui's.
As a Side note, Mac OSX uses MVC throughout , maybe this is why Aqua is view to be so slow.
Well, Java may be back for the time being, but I'm concerned that the language may still crash despite its new found momentum. The Java toolkits are fragmenting, Sun's market position is questionable, and alternative technologies are gaining in both strength and promise.
Sun's marketing materials always mentions Java's strength in enterprise development. But what, precisely, is Enterprise Java? Is it J2EE? Quite possibly, as a theoretical specification. But in real life, the platform is fragmented. On app servers, is Java WebSphere, WebLogic, JBoss, or Tomcat? For persistance: EJB 2, Hibernate, JDO or Cayenne? For Web apps: JSP, Struts, JSF, Tapestry? And just for fun, lets throw in XDoclet, Velocity, Cocoon, AspectJ, and about another thousand or so projects.
The diversity of new Java technologies is both great and terrible: great in the sense that new ideas are being explored that Sun may find to radical to consider putting in their specs, but terrible in the sense that few, if any, Java programmers will have knowledge of the various different projects. This is a real problem, folks. Someone who knows .Net can reasonably be expected to understand most of the C# related APIs. Its unreasonable to expect even a seasoned Java developer to understand how to program the full spread of Java APIs. Someone with Sun certification, an EJB whiz, may be damn well baffled by Hibernate (I've seen this), and may not comprehend why you'd use Tapestry instead of good old JSP.
I think the Java development platform is fragmenting. Sun's work, impressive as it is, often seems to be more concerned with being architecturally perfect at the expense of real world application speed and developer productivity (code astronauts). The Open Source projects seem to be trying to be as cool as possible, at the expense of API consistency and, just like Sun, developer productivity.
The general chaos in the Java world has, thankfully, allowed my development team to finally look at entirely different languages: Ruby, Python, even back to Smalltalk and Lisp. We've chosen this route out of frustration with both the limitations of the Java language and the increasing fragmentation of the toolsets.
As an aside, its fun to watch how hard various Open Source projects are working to emulate a ten year old toolkit: WebObjects. Yeah, WebObjects rules. Object Relational Mapping that works (and Hibernate folks, doesn't require learning yet another XML dialect to get things working). OO web page design, true components (Tapestry is essentially a copy of Web Objects Framework, made more obtuse). I wish Sun had started it's development efforts copying NeXT instead of Microsoft. We'd have a better development world today.
/* Dang, I can't type that well. */
I have to disagree here. There are certainly cases where Java is faster, but they're relatively few. Lets just go through that infamous benchmark again:
1 205&cid=9436176
1 205&pid=9438782#9439949
Java faster than C++ benchmark
Point 1 - "I was sick of hearing people say Java was slow, when I know it's pretty fast".
Baaaad start to any analysis - always keep an open mind about the results.
Point 2 - He used G++. So this is only valid for G++, not necessarily any other C++ compiler. Which is fair, I just feel this is worth emphasising.
Point 3 - It's rapidly determined that G++ takes much longer to execute a method call, than Java does. Given this, it shouldn't be a significant suprise that benchmarks relying heavily on recursion will be slow in C++.
For example, rewriting the Fibonnaci benchmark to use a for loop instead of recursion give a 600-times speed increase:
http://developers.slashdot.org/comments.pl?sid=11
Rewriting it into constant-space gave an almost 10 times increase over that:
http://developers.slashdot.org/comments.pl?sid=11
Moral of the story? Java is great for method calls , but I'm not so convinced about everything else...
When I was unemployed, I had monster.com and dice.com send me a daily email with every new job posting that contained "Perl" or "Java". For those ten months, I saw virtually no Perl jobs, and almost every Java-related job required J2EE experience.
So I took a basic class in J2EE, and said to myself, "No wonder there are so many openings for J2EE programmers: it takes a team of five J2EE programmers a month to put together what a good Perl hacker can make in a week." The hoops you have to jump through to get things to work in J2EE--most of which seem to involve working around Java's static typing and its object model--are absurd.
I've been re-employed for almost a year, thank God, and the group I work with is writing a J2EE-based ERP application. I have seen nothing so far to refute my original impression of J2EE.
But it still beats being unemployed.
send all spam to theotherwhitemeat@ropine.com
"And you JAVA peopel should get it into your head that applications need to fit in with the environment they are runnign on. Why the hell should that oen application look out of place?"
I agree completely with this statement. This has become a much bigger frustration for me since I moved to OS X. I used to use NetBeans for developement. Netbeans looks fine on X11 and Linux, and OK on Windows, but looks horrible on OS X. So I switched to Eclipse, and it looks great. The Eclipse folks have shown that a little effort can make a Java GUI look good, and be integrated well into the native environment.
When did the Java garbage collector ever fail to deal with circular references? Real GCs don't work by reference counts.
In my world (Enterprise Application Integration) it's all Java. Has been for years, and it won't change anytime soon.
"Were I a CIO facing these issues [the technical effort needed to port an app off one app server to another], I'd stay focused on the one thing definitively under my control - keeping the cost of substitution, of at least application portability, as close to zero as possible. How? You guessed it, I'd write to Java." - Jonathan Schwartz Sun COO
Ummm - what about python or perl? Both of these are just as portable - requiring zero modification of the code to port to any OS.
And don't pull out the 'java is more efficient' bull scatology. I have a java application right now that my team is rewriting in perl because it runs too slow (and also has a memory leak - code is vendor proprietary, so they won't let us see/modify the source to fix it). There is nothing I can do with java that I can't do with perl or python - as much as David Berlind would say otherwise (his statement in the article suggests perl and python are good for 'scripting', but not robust enough for large applications). As a supposedly impartial journalist/editor for ZDnet - I have to question his motives for jumping on this bandwagon. Also, his primary focus on writing, rather than building apps, hardly makes him qualified to make such an accessment, imo.
Given that I would have to disagree with this editorial in JDJ.
The words of the COO of SUN, who has a vested interest in the success of java, and the words of a journalist, who from all appearances doesn't have the technical background to be taken seriously concerning application development issues, in an editorial on a website dedicated to java development, hardly seems like 'news' more than a marketing ploy.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Java isn't going anywhere. Java has at least reached the status of 'the next cobol', to quote Stu Halloway. This isn't a comment on Java's speed, quality, and such, it simply means that even if all Java development stopped today (which it won't), there has been enough investment in Java'based intfrastructure that the maintenance alone will be quite a large job market for years to come.
Java is NOT dead/dying. New, important projects start with it every day. I am the president of the Northern Virginia Java Users Group, and we have a steadily growing membership (now over 1100 members). I am also a speaker for the No Fluff Just Stuff Software Symposiums, and the discussions about Java tools, techniques, etc dominate that conference. Why? Because it sells. .NET has been gaining some momentum, and c# is undoubtedly the 'next big thing', but Java is here to stay. If you are a software engineer, Java is a 'safe place' to be for new and interesting work for the next 4+ years, at least. (That doesn't mean software engineers don't need to have diverse talent - but that is a topic for another rant).
wxWidgets is a really nice toolkit. The problem is that it isn't truely cross platform where it counts.
Like it or not, the 2nd platform most business app developers want to target is the Macintosh. I tried porting a Win32 app to wxWidgets a while back, and it looked like I could get it to work on Windows (and probably Linux), but the Mac port was just not there. Widgets didn't draw, size or behave right, and I had problems getting sockets to work right.
It appears like there's a push on currently to get the mac support up to par (at least their website is soliciting contributions). It's a shame that Apple wouldn't fund this themselves, but I guess they're still pushing native Mac toolkits (though why, at this point in the game, I can't imagine).
Posted from my Android phone. Oh, I can change this? There, that's better...
Actually I prefer Java, because it's more simple. Most of the time, syntactic sugar just annoys me.
Of course I hate writing getters and setters. All the major IDEs do that for you. I haven't written a getter or setter in ages.