Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Java Turns 10: The Developer Retrospective : Page 3

Java passed the 10-year milestone this May. DevX asked developers to reflect on the language's first decade, assess where it stands today, and speculate where it's going. The diversity of responses—including industry notables from within Sun, IBM, BEA, and Borland—indicates that Java is as vital as ever.


advertisement

6. Which have been responsible for more Java innovations: Java Community Process specifications or open-source implementations?

"Open source, by far. The JCP generally believes in standardizing before accumulating practical experience. EJB, logging, and persistence have all been disasters within the JCP. The JCP is really abandoning Java's base. Very hard problems are getting marginally easier to solve, but easy problems are getting much harder."—Bruce Tate

"Open source implementations are leading the development process, and the JCP is only defining norms."—Laurent Ploix

"If speaking of purely innovations, I would say open source. Open source is quick to respond when there is a hole that needs to be filled. The JCP is way too slow right now to keep up with the industry."—Michael Pilone"



"Most innovations have come through the JCP model. Over the past couple of years, however, we've been seeing signs of increased activity in the open source model."—Rod Smith (IBM)

"The JCP specifications deserve immense credit for getting the ball rolling. It provides a certain 'center-of-mass' to the Java ecosystem. Many 'non-JCP-standard' open source projects have explored various and sundry ideas—some awful and some wonderful. It's a great innovation engine."—Ed Cobb (BEA)

"The JCP itself only codifies specifications that are backed by an existing implementation. As programmers, we do not want to write to an implementation of Java, we want to write to a specification, which implementations fulfill. Useful programming often starts as a fragment of code, and often evolves 'code first, specification later.'"—Rob Gingell

"I have found open-source initiatives, especially from Apache, to the most innovative and useful."—Eric Bruno

7. Should Sun open-source Java?

You knew this would be on the questionnaire.

"It doesn't really matter at this point. Java is established enough to make its own path."—Bruce Tate

"When Sun is doing such a good job, why disturb it?"—Raghu Donepudi

"No. If it would be open source then we [could] see many flavors of Java, which ultimately leads to problems like we are currently facing with application servers."—Rahul Kumar Gupta

"Yes. The only reason that Sun is refusing to do so is because they think of Java as their own completely and they are using it to prop their company up."—Jack Herrington

"On one hand the idea of open source is appealing because it may lead to more bugs getting fixed in a shorter amount of time. On the other hand it may result in forks, branches, and incompatible JVMs."—Michael Pilone

"No. I do not believe a crowd of mediocre geniuses can replace the scientific minds of those who take care of the sanity of the basic concepts—of which most of the people are not even aware."—Vlad Patryshev

"The involvement of the open source community would accelerate innovation and increase the platform's competitiveness."—Rod Smith (IBM)

"The main reason we need an open source Java is to ensure the vitality of the platform. Open sourcing Java is our insurance plan if something should ever happen to Sun."—Ed Cobb (BEA)

"I think it should. 'Open-source' Java does not require Sun to do anything, it merely requires others to do something. Having an 'open-source' Java is inevitable. I would suggest that Sun embrace that inevitability and work to its benefit."—Rob Gingell

"I really don't care."—Kyle Gabhart

8. If you could change one thing about Java, what would it be?

"At a lower level, Java needs code blocks, continuations, a more dynamic typing model, and a whole lot of features that make applications programming easier. You can't enable everything with libraries."—Bruce Tate

"Introspection [a class to examine the properties of a JavaBean] is too difficult and too heavy to use."—Laurent Ploix

"The license."—Greg Magnusson, founder of Cyborg Spiders Web Development

"A provision for memory management by the developers."—Raghu Donepudi

"Add back in operator overloading."—Jack Herrington

"Jar versioning is extremely necessary in Java right now. I can't count the number of times I have had XML parsing library conflicts or logging library conflicts."—Michael Pilone

"Class Object. For 10 years it has not changed. There's plenty to add."—Vlad Patryshev

"The Java platforms have become too complex. We believe the Java community needs to do a better job of addressing departmental and small-to-medium business needs in order to continue to grow, prosper, and succeed."—Rod Smith (IBM)

"Java desperately needs a more robust module system. Currently, all we have is .jar files; the result is '.jar file hell.' It's too hard to describe a system of inter-connected modules today."—Ed Cobb

"Things I wished had not been done with, or to, or around [Java] in the past: The several false starts on dates and time; the introduction of the politically correct but thoroughly unnecessary RMI/IIOP; autoboxing from the start."—Rob Gingell

"The tie between classloading and the Java runtime type of an object is a mistake that we continue to pay for. You can't really determine if your program is type safe at compile time. Further, if you are doing anything reasonably dynamic, you often have to guess at the right classloader for a given class."—Jim Waldo

"Garbage collection is evil. [It] made it possible for poorly trained, sloppy coders to enter the industry.

"Other things Java needs: operator overloading, precompiler directives (#define, etc), the ability to separate declaration from definition (header files and source files), unique, non-native, machine identifiers (for licensing purposes)."—Michael Smialek

"Code-behind pages!!! The reuse and flexibility that ASP.NET and code-behind pages offer is tremendous. I would love to see JSP 3.0 go this direction."—Kyle Gabhart

"I would prefer to use Java objects to access [an] OS than using JNI. Most of Win32/Linux API could be wrapped in Java."—Alexi Jordanov, project leader for the OSGi technology company ProSyst Bulgaria



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap