 |
Search |
 |
|
|
Mr. BrightsidePosted by editor on September 10, 2008 at 4:32 AM PDT
Wait, now Java does too much? The forum section of the front page gets four items today: one more than usual, but two less than I had been considering. There are a bunch of really good discussions going on. Well, there's also a new spam trick -- spammer posts a "hey, does anyone have bulk e-mailing software" message from one account, and then the SEO-targeted link-tacular followup from another -- but I caught those and deleted the messages (the users will be deleted in a few hours once the U.S. West Coast wakes up). Anyways, back to the legitimate discussions,
Is this a valid criticism? We've heard a lot over recent years about Java "using up its complexity budget", but some of that is aimed at language features like generics (and possibly closures). This complaint has to do with the breadth and depth of the libraries available to the Java developer. On the one hand, there are a lot. A quick word-count of the JDK 6 Javadocs shows that Java SE has over 3700 public classes, and that's before you bring in libraries like Java EE. But on the other hand, does anyone really try to keep up with it all? Java is large enough to have specialization, and it's likely the server-side programmer never looks at anything in Swing, just as the desktop developer neither knows nor cares how servlets work. By this argument, Java's no different than any other large platform: do you suppose there are a lot of MSDN developers who excel both at Direct X graphics and .NET web services?
Also in today's Forums, Over in the Project Wonderland forum, Finally, In Java Today, the ME Framework 1.2.1 release is now available on the project's download page. "This release went through an extensive QA cycle and is ready to be used for test suite development. If you downloaded the ME Framework 1.2.1 development releases, please switch to this final milestone release." The ME Framework is a set of JT harness plugins that supports the Java ME platform. TCK architects use the JT harness and the ME Framework to construct TCK test suites for Java ME technologies. Kirill Grouchnikov has started a new series of blogs in which he talks about the specific tasks involved in taking a UI definition from your designer and turning it into a working application. Step 1 is analyzing the original design or more specifically, identifying the application's decoration areas and functional areas. Step 2 is mapping design to UI toolkit, which means "map[ping] the application functional areas to Swing container hierarchy and the application decoration areas to Substance decoration areas." Sathish K. Palaniappan and Pramod B. Nagaraja's article Efficient data transfer through zero copy explains how you can improve the performance of I/O-intensive Java applications running on Linux and UNIX platforms through a technique called zero copy. "Zero copy lets you avoid redundant data copies between intermediate buffers and reduces the number of context switches between user space and kernel space." In today's Weblogs, Fabrizio Giudici begins with a story about Remote profiling with NetBeans. "Varun Nischal, one of the fresh new members of the NetBeans Dream Team, is hosting some friends on his blog. I've just published a small story about the NetBeans Profiler used in remote mode." In Add resetValue() to EditableValueHolder?, Ed Burns "polls the community about whether to break backwards compatibility in one small interface in JSF 2.0." Finally, Marina Sum promotes a Join OpenSSO and Single Sign-On Presentation in Second Life. "Registration is now open for the September 30 session." Current and upcoming Java Events :
Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site. Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive. Wait, now Java does too much? »
Comments
Comments are listed in date ascending order (oldest first)
Submitted by keithjohnston on Wed, 2008-09-10 14:03.
Java has to keep adding APIs to support new functionality and programming models. I think the complaints about generics are overblown, and I don't think closures will kill the language.
What works to kill a language is simply a new generation of programmers. They see Java and how huge it has become, and then they see python, which seems small, and hey - no compiler needed! So they start learning Python and they grow with it over time so they don't mind the additional complexity.
Ten years from now, Python will have a gazillion APIs and the next generation will say it is too complicated and start learning "Foobar" or whatever the small, simple language is of the day. And this language will have a compiler! No more bugs in my programs because of typos! Cool!
Submitted by sjoyner on Wed, 2008-09-10 14:58.
The ever increasing complexity of Java has convinced me to move away from it. All one needs to do is look at the Java EE tutorial to get a feeling of hopelessness. Do I seriously need 5-6 different roles to deploy a web app to a production environment? I work in one of those roles at a large company, and I can tell you from experience that it causes more problems than it solves.
Java is far too complex. Look at the Portal framework. I need a whole new set of skills to develop a portal application vs. developing in a servlet environment. Why? What's the point? I don't want to have to learn 16 different frameworks and standards just to create a halfway complex portlet. Not only that, why should I have my programming capabilities limited by some ill conceived standard (JSR 168 - you can't access http cookies. Just ran into that yesterday).
The Java community has convinced much of the business world that all these standards and frameworks are necessary to maintain compatibility and interoperability, but in the end, not even the big Java vendors can keep applications compatible between versions of their software.
Thanks for the ride Java. You've taught me an important lesson. Things can get too big and too complex to be useful.
Submitted by darted on Wed, 2008-09-10 18:27.
So, the complaint is that due to Java becoming more capable, it is now too complex?
Well, I can see that as standards have evolved some items have been kept for 'backward compatibility' that quite honestly add bloat and confusion.
However, if you need portal technology and Java didn't offer an API to do it then you would complain. The problem I see is a lack of integration with current API's or total replacement, pick one.
I have news for you. As the needs of the business change you will have to continue to learn new frameworks. Pick you language(s) to do that in. Is Java the correct one for all of them. No. But it is the one for a lot of them and will continue to be for me.
That said, I think Java needs to be cognizant of the fact that it should not try and be all things to all people and consider what should it provide more capability to plug into vs. implement.
Submitted by bharathch on Thu, 2008-09-11 07:50.
alexj33, it doesn't matter what you or I believe as developers. The language experts, theorists supreme and the guardians of Java will tell you what's good for you. They'lI tell you that Java will become obsolete if it doesn't "catch up" with other functional programming languages or doesn't get more "expressive and concise" like morse code by biting a silver bullet called BGGA closures. The gods have spoken. Comply or be left behind, mortal. :-)
|
|
|
||
|
