• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Java 2, v 5.0 Changes Everything!

 
Author
Posts: 253
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To all:

I am delighted by the interest in my new book "Java 2, v5.0 (Tiger) New Features", and by the interest in Java 2, v5 in general. Because many of the questions revolve around the same point, I have decided to make some general comments.

Let me begin by restating a sentence that I have using a lot: Java 2, v 5 changes everything! Although this is, obviously, an overstatement, it does not miss the mark by much. The main new features in Java fundamentally alter the language. The release of 5.0 is a watershed event that divides the past from the future. Programmers unwilling to embrace the future will find themselves marginalized. You simply must get up to speed with the "new Java."

To get a better idea of what I mean, here are the first three paragraphs from the Preface.


Beginning with its original 1.0 release, Java radically altered the way that we program for the Internet. Building on the well-known syntax of C/C++, Java streamlined the object model, simplified memory management, and added built-in support for multithreading. Today, we take these features for granted, but nearly a decade ago, they were fundamental and far reaching advances.

Of course, version 1.0 was just the beginning for Java. Over the intervening years, Java has continued to grow, evolve, and otherwise redefine itself. Unlike many other languages, which are slow to incorporate new features, Java has continually been at the forefront of computer langauge design. One reason for this is the culture of innovation and change that came to surround Java. As a result, Java has gone through several upgrades -- some relatively small, but others quite large.

Of these revisions, Java 2, version 5.0 ranks as the most significant change to Java since its original release. So profound are its additions that they will forever alter the way that Java code is written. For example, generics fundamentally expands and alters Java's syntax, autoboxing simplifies the interplay between primitive types and objects, and metadata adds an entirely new programming dimension. Given the scope of the innovation, it is no surprise that the code name for the Java 2 Platform, Standard Edition, Version 5 (J2SE 5) was "Tiger" during its development.



One of the key points to understand about the many new features in Java is that they are often complementary. For example, generics and autoboxing work hand-in hand. The Formatter and Scanner classes would not be possible without varargs (variable-length arguments). And so on. Thus, learning about Java 2, v 5 is more than just becoming familar with its new features, its seeing how they relate to one another.

If a I sound enthusiastic about Java 2, v5, I can assure that I am! Java has re-invented itself. In doing so, it remains a vibrant force in computing. Don't be left behind in this new "Java Revolution!"
 
blacksmith
Posts: 979
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear author,

How do generics and autoboxing work hand-in hand,
can you give an example, it's all so new!

If possible could you go deeper into how to see
the relations between these new concepts?

Cheers,

Gian Franco Casula
[ August 24, 2004: Message edited by: Gian Franco Casula ]
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Where I work we just recently implemented Java 1.4. How soon do you see the majority of businesses upgrading to Java 5.0?
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear author,

Has Java 5.0 made any changes to the collections?
Also has the handling Regular Expressions improved?


Thanks,


James White
 
Ranch Hand
Posts: 249
Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does anybody know if Sun has announced a specific date for actual release? I've heard in another thread late October, but is there any news more specific?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Herb Schildt:
The Formatter and Scanner classes would not be possible without varargs (variable-length arguments).



Isn't this a little bit overstated, too? The java.text.MessageFormat class, for example, already handles a variable number of arguments by using an Object array. Aren't variable-length arguments "just" syntactic sugar to exactly the same avail?
 
Herb Schildt
Author
Posts: 253
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Gian: Generics and autoboxing work hand-in-hand because the generic feature applies only to references. However, because of autoboxing, you can freely pass a primitive type to a generic method, for example, because autoboxing automatically wraps it into an object.

James: Yes, Java 2, v5 changes collections! They have all been updated for generics. Can you still compile your old collection code? Yes, but you will get warnings. Truthfully, all Java programmers will need to make the move to generics as soon as possible.

Mike: The last date I heard was also October, but who knows? By the way, I believe that Beta 2 (the one I used when writing my book) contains a stable feature-set. A few fringe issues may change, but the main features seem to be locked-in.

Ilja: No, I don't think its overstated. Of course, the functionality of Formatter or Scanner can be achieved without varargs, but not the usability and convenience. It is the "syntactic sugar" that you refer to that makes most modern programming languages fluid and easy-to-use.

To go one layer deeper into the "syntactic sugar" issue, I remember when C++ was invented. As many readers know, C++ added objects to the C langauge. I recall hearing at the time that "objects are just syntactic sugar". I doubt that many programmers think that now.

My point is that all programs ultimately reduce to 1s and 0s. It is the "synactic sugar" that differentiates a good programming language from a great one.
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Herb Schildt:

Can you still compile your old collection code? Yes, but you will get warnings.

How was that decision made?

To be honest, that sounds really stupid to me. I'm in favor of adding new features if they have a sufficiently high benefit/cost ratio, but trying to force people to give up the old way of doing things seems counterproductive when the old way may be better in some cases. Plus, generating a pile of warnings from legacy code that works fine and shouldn't need to be touched makes any other warnings far less useful.
 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
BTW, if anyone wants an example of good coding style, avoid the source for java.util.Formatter. I suppose the fact that everything is stuffed into a single class supports some notion of high performance...

-j-
 
Jeff Langr
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Since I've written on 5.0 (and am working on a book that features it), I'll weigh in and echo Mr. Schildt's sentiments that Java 2 5.0 gives a dramatic change to the look and feel of the language.

For the most part, the language changes come across as efforts to simplify and clarify. After working with the changes for almost a year, I've found that virtually everything contained within 5.0 comes across as natural. I've encountered plenty of legitimate uses for each feature, although I can sense the potential for abuse of certain elements.

I'm disappointed only with the generics implementation. From a client developer standpoint--from the standpoint of someone that will be working with parameterized collections, e.g. ArrayList--the parameterized type support in Java is simple to use and understand. It is effective. From the standpoint of developers building their own parameterized types, the implementation scheme used, something called "erasure," is a kludgy mess that was chosen primarily for backward compatibility reasons.

So I suppose my major complaint is the decision to sacrifice the language to the god of compatibility. Java has become a bit of a mess, with warts in many of its APIs, inconsistencies across the core libraries, deprecated but eternal APIs, and half a dozen ways to skin a cat for any given problem. A half dozen cat killers are normally a good thing, but in this case many of them only bludgeon the feline into submission.

The dramatic changes in 5.0 seemed like an opportunity to establish a cutoff point. I suppose we'll have to wait until Java 3.

Until then, I'm still embracing the new features of 5.0. I've definitely appreciated the simplicity it's imparted to my code.

-Jeff-
[ August 24, 2004: Message edited by: Jeff Langr ]
 
Herb Schildt
Author
Posts: 253
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Warren: I am sure that many other programmers share your point of view. I understand both sides. One one hand, generics help ensure very reslient code at runtime. On the other hand, legacy code that is thoroughly tested shouldn't be touched for good reason.

The main justification for the warning is, essentially, that pre-generic code (which uses what is called raw types) is potentially unsafe and needs to be flagged as such -- given that it is now possible to create "safe" code. Frankly, I think that now that generics are part of Java, Sun wants all programmers to use it.

Fortunately, I simply write about Java. I don't determine what warnings it issues!

BTW: I suppose its possible that the released version of 5 will not generate these warnings, but there is no indication that this will be the case. The warnings seem to be an important part of Sun's generic strategy.
 
Jeff Langr
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
Plus, generating a pile of warnings from legacy code that works fine and shouldn't need to be touched makes any other warnings far less useful.



This is an extremely valid point. Granted, you can turn off warnings, but that's often a bad idea. I strive for warning free code; there's little reason to purposefully write code that generates warnings. Unless, of course, you're stuck in a legacy world.

Once warnings crop up that you can't turn off, people ignore them. And, since warnings are just a list of messages, people end up missing or ignoring other warnings that they perhaps shouldn't. The relevant warnings get lost in the trees.

-j-
 
Jeff Langr
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Herb Schildt:
BTW: I suppose its possible that the released version of 5 will not generate these warnings, but there is no indication that this will be the case. The warnings seem to be an important part of Sun's generic strategy.



I suspect they'll remain, at a switchable level. The problem lies in interacting with legacy APIs, including those from Sun themselves, that you cannot easily change. I've had situations where I was stuck with warnings, unless I wanted to rewrite the core APIs.

-j-
 
Herb Schildt
Author
Posts: 253
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jeff:

Thanks for your thoughts and insights. I am looking forward to your book!

As to erasure, I understand what you are saying. Erause is an unusual way to approach the implementation of generics. It also causes some aspects of generics to be a bit counter-intuitive. That said, for the most part the issues surrounding erasure won't impact most common uses of generics. However, the dedicated "code warrior" will definitely bump up against it from time to time. Because of this, I give the topic of erasure quite a few pages in my book.

For those readers who have not yet looked into generics and don't know what erasure is, here is a brief definition: Erasure is the process by which generic type information is removed. This means replacing the type parameter with its bound type, which is Object by default, and then adding the appropriate casts. Erasure takes place during compilation as a "first pass", just before the translation of source code into bytecode. (Its all done automatically by javac, of course.) This process, while functional, can cause some surprises in some cases. As Jeff says, erause was the used to implement generics because of the need to maintain backward compatibility.

As to the issue of do the new features of 5 help or hurt Java? I come down strongly on the side that they help Java. Without the radical innovation in 5, Java would simply fade slowly away. Verson 5 ensures that Java is here for many more years to come.
 
Ew. You guys are ugly with a capital UG. Here, maybe this tiny ad can help:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic