Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Expo on Google News
SYS-CON.TV
Cloud Expo & Virtualization 2009 East
PLATINUM SPONSORS:
IBM
Smarter Business Solutions Through Dynamic Infrastructure
IBM
Smarter Insights: How the CIO Becomes a Hero Again
Microsoft
Windows Azure
GOLD SPONSORS:
Appsense
Why VDI?
CA
Maximizing the Business Value of Virtualization in Enterprise and Cloud Computing Environments
ExactTarget
Messaging in the Cloud - Email, SMS and Voice
Freedom OSS
Stairway to the Cloud
Sun
Sun's Incubation Platform: Helping Startups Serve the Enterprise
POWER PANELS:
Cloud Computing & Enterprise IT: Cost & Operational Benefits
How and Why is a Flexible IT Infrastructure the Key To the Future?
Click For 2008 West
Event Webcasts
J2SE 1.5: Growing the Language - Finally
J2SE 1.5: Growing the Language - Finally

A major event is about to happen - the final release of version 1.5 of the core Java platform.

The changes in 1.5 are some of the most important to the Java language. This is a big step for Java and it's not an easy one. People with an existing investment in the platform tend to be very conservative about the language and core platform, usually for good reasons: nobody likes to have their investment rely on something that has been deprecated, made obsolete, and possibly becoming unsupported. Dramatic changes to the Java language upset a lot of people, not just anyone but some of the long-time Java users who have played a part in making Java successful. Language growth is both painful and necessary.

In Guy Steele's famous speech and article "Growing a Language" from 1998, he discusses the growth of programming languages. He explains how Lisp's ability to grow in a seamless way made it large and has kept it alive for an amazingly long time, while behemoths like PL/1, which was designed to solve everything out of the box, never succeeded.

Java is looking more and more like the language for solving everything. It was never a language that supported growth in the way Steele meant. It doesn't have constructs, like macros, that enable developers to extend the language syntax. This means that the growth has had to come through official channels, which is why the 1.5 release is so important to Java. In the early days of Java, every new and major upgrade was a revolution. The differences between the alpha API and 1.0 were huge, and the changes in 1.1 and 1.2 were substantial. With 1.2, Java became big, successful, and "real"; people started depending on it for large projects. The constant revolutions had to be replaced by slower evolution.

However, if Java does not evolve fast enough, something without a history to care about will soon turn Java into a legacy technology. This is a pretty normal cycle in the computing world. One technology gets wide acceptance, but eventually grows large and can't evolve as fast, then something new comes along and replaces it. The Java language has felt some of this. Competing languages, such as C#, Ruby, and Groovy, are not tied to previous decisions and existing architectures. They use this to try to leapfrog Java.

For a long time it seemed as if Sun had decided to accept a slower pace of development so it wouldn't upset existing Java stakeholders. Soon people who were not tied to Java for legacy reasons started looking at these competing languages. The only way to stop this is to have the courage to make the necessary changes, even if they hurt. With J2SE 1.5 I think Sun is finally showing that they have this courage. This is also true for the EJB 3.0 specification, which relies on features from 1.5 to drastically change how EJBs are developed.

It did take a long time for Sun to make these dramatic language changes and this has helped Java's competitors a lot. Considering that, for example, generics have been in the pipeline since at least 1998 and a JSR since 1999, it's amazing that they haven't become a reality until now. I'm not saying that generics should have been added to 1.4 - they weren't ready then - but it doesn't seem as if Sun has made this a high priority until now. You could speculate that the economic crisis at Sun has played a role in this. When everything was going great for Java and Sun, they might have been afraid to make big changes since that could risk what they had. Now that Sun is in a much tougher position, they might be willing to risk a little in order to gain much more.

Does 1.5 provide what Steele wanted? Steele's point was that the language must facilitate language growth; it must supply patterns for extending the language. Steele suggested a few examples, most notably generics and operator overloading. Java 1.5 does contain generics but not operator overloading. However, it does provide one feature that defines a pattern for language growth: annotations. I would love a complete macro facility for Java, but I know that many wouldn't and annotations do give me some of the power that macros would. This is a great thing that moves Java to a position that will allow it to get older and still evolve. Seeing how annotations will be used to revolutionize EJB development, this is truly about growing the language.

Of course, I don't like all the changes in 1.5. For example, static imports are taking Java one step closer to write-only code. If you want to save keystrokes when using common statics, you should tell the IDE that when you type abs(), the IDE should expand it to Math.abs(). The language should not sacrifice readability for the sake of writability; the language needs to work well for both writing and reading, and enable the developer to be efficient by providing help to the IDEs. Static imports should be an IDE feature, not a language feature.

J2SE 1.5 will obviously be one of the main talking points at JavaOne and there are plenty of sessions available. If you want to learn about the new features, I recommend attending TS-1952, "Fast Track to the Java 2 Platform, Standard Edition (J2SE) v1.5," which will be presented by my co-editor, Calvin Austin, as well as Mark Reinhold.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

Coldfusion MX is a lot simpler and much easier to create complex web sites with compared to JAVA, after all this web site was written in CF, and it run great without all the complexity. What java needs is a good front end tool

Jason, simplicity is one of the design goals for the language, as stated by Sun. While it''s syntax was, as you point out, borrowed from C/C++, this was mere window dressing, designed not to put off the C/C++ programmers Java appealed to. Yes, the syntax is arguably messy, but by eliminating things like pointers, multiple inheritance, etc., the language became simpler. One wag called Java "Smalltalk in C clothing"; as an old Smalltalker, I think he got it about right.

I agree with your points about autoboxing. There''s an example where NOT adhering to simplicity (by having primitives and object representations of those primitives) causes problems. So an autoboxing kludge is better than not having it.

But if history is any guide, the language tinkering won''t stop here. That''s my concern -- are the Java architects losing their taste for simplicity? If a little is good, is more necessarily better? Einstein addressed this issue: "Any intelligent fool can make things bigger, more complex. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."

Java doesn''t have macros because the Sun developers had an opinion about how they wanted software development projects to be organized. There are several examples of non-language dependent "standards" that are just plain silly (file names needing to be the same as module names).

The idea of Java being simple is ludicrous. Look at the "simple" C-style for loop. What do you have to say about the simplicity of storing primitives in Collections. This new release alleviates some of those pains, but it can''t get over the behomoth-style syntax burdens of Java that came from its older siblings. If you really want simple, go to Smalltalk or even Ruby if you are more inclined to "newer" technologies.

Growth and simplicity are not mutually exclusive. There is the idea and possibility of growing more simple. The new for-loop, auto-boxing/unboxing, etc. are prime examples of that. I don''t like everything that''s coming in this new release, but some of it does bode quite well for the readability of Java!

You say, "The language was designed to be a simple one, relying on [objects] to provide all but the most basic functionality." Why not rely on *objects* to do everything? That would be much simpler!

You say, "But with version 1.5, are we being swayed to embrace complexity within the language?" What are you being swayed to embrace? If you feel it''s more complex don''t use it, no one''s holding a gun to your head.

I assume you are talking of things like generics and static imports. I have never been a fan of generics, it''s readability is akin to C++ templates (besides that I think its dynamic-typing envy, and envy usually doesn''t produce the best results ;). I don''t like the idea of static imports because it blurs the line of encapsulation. I don''t like these "improvements" and so I won''t use them. However, there are advances toward simplicity that I will use (the afore mentioned for-loop and autoboxing).

The idea that Java needs to "grow" is profoundly wrong-headed. Some of the most successful technologies catch on because they are simple. Their adoption is easy. They allow teams to collaborate on a standard without requiring weeks of training. And then comes the real trouble: success.

As the technology is more widely adopted, people begin to clamor for new features. Developers who have long since learned the language clamor the something new to get excited about. And so the technology becomes bigger, harder to learn, more difficult for teams to implement until it falls of its own weight.

One of Java''s chief benefits is its simplicity. The language was designed to be a simple one, relying on classes to provide all but the most basic functionality. But with version 1.5, are we being swayed to embrace complexity within the language? In the face of seemingly compelling arguments for this or that new feature, we might do well to remember this quote from Jim Gosling:

Complexity makes things harder to understand, harder to build, harder to debug, harder to evolve, harder to just about everything. And yet complexity is often much easier than simplicity.


Your Feedback
Robert Wilson wrote: Coldfusion MX is a lot simpler and much easier to create complex web sites with compared to JAVA, after all this web site was written in CF, and it run great without all the complexity. What java needs is a good front end tool
Hal Helms wrote: Jason, simplicity is one of the design goals for the language, as stated by Sun. While it''s syntax was, as you point out, borrowed from C/C++, this was mere window dressing, designed not to put off the C/C++ programmers Java appealed to. Yes, the syntax is arguably messy, but by eliminating things like pointers, multiple inheritance, etc., the language became simpler. One wag called Java "Smalltalk in C clothing"; as an old Smalltalker, I think he got it about right. I agree with your points about autoboxing. There''s an example where NOT adhering to simplicity (by having primitives and object representations of those primitives) causes problems. So an autoboxing kludge is better than not having it. But if history is any guide, the language tinkering won''t stop here. That''s my concern -- are the Java architects losing their taste for simplicity? If a little is good, is more nec...
william george wrote: Java doesn''t have macros because the Sun developers had an opinion about how they wanted software development projects to be organized. There are several examples of non-language dependent "standards" that are just plain silly (file names needing to be the same as module names).
Jason Rogers wrote: The idea of Java being simple is ludicrous. Look at the "simple" C-style for loop. What do you have to say about the simplicity of storing primitives in Collections. This new release alleviates some of those pains, but it can''t get over the behomoth-style syntax burdens of Java that came from its older siblings. If you really want simple, go to Smalltalk or even Ruby if you are more inclined to "newer" technologies. Growth and simplicity are not mutually exclusive. There is the idea and possibility of growing more simple. The new for-loop, auto-boxing/unboxing, etc. are prime examples of that. I don''t like everything that''s coming in this new release, but some of it does bode quite well for the readability of Java! You say, "The language was designed to be a simple one, relying on [objects] to provide all but the most basic functionality." Why not rely on *objects* to do...
Hal Helms wrote: The idea that Java needs to "grow" is profoundly wrong-headed. Some of the most successful technologies catch on because they are simple. Their adoption is easy. They allow teams to collaborate on a standard without requiring weeks of training. And then comes the real trouble: success. As the technology is more widely adopted, people begin to clamor for new features. Developers who have long since learned the language clamor the something new to get excited about. And so the technology becomes bigger, harder to learn, more difficult for teams to implement until it falls of its own weight. One of Java''s chief benefits is its simplicity. The language was designed to be a simple one, relying on classes to provide all but the most basic functionality. But with version 1.5, are we being swayed to embrace complexity within the language? In the face of seemingly compelling arguments for...
Latest Cloud Developer Stories
Concerns about security, downtime and latency, budgets, and general unfamiliarity with cloud technologies continue to create hesitation for many organizations that truly need to be developing a cloud strategy. Hybrid cloud solutions are helping to elevate those concerns by enabli...
Nutanix has been named "Platinum Sponsor" of CloudEXPO | DevOpsSUMMIT | DXWorldEXPO New York, which will take place November 12-13, 2018 in New York City. Nutanix makes infrastructure invisible, elevating IT to focus on the applications and services that power their business. The...
Digital transformation is about embracing digital technologies into a company's culture to better connect with its customers, automate processes, create better tools, enter new markets, etc. Such a transformation requires continuous orchestration across teams and an environment b...
The complexity of managing and delivering the high level of reliability expected of web-based, cloud hosted systems today, and the expectation of Continuous Delivery of new features has led to the evolution of a totally new field of Service Reliability Engineering catered for suc...
Inzata is a powerful, revolutionary data analytics platform for integrating, exploring, and analyzing data of any kind, from any source, at massive scale. Powerful AI-assisted Modeling and a patented analytics engine help users quickly load, blend and model raw and unstructured d...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021



SYS-CON Featured Whitepapers
Most Read This Week
ADS BY GOOGLE