JavaOne: Day One

re: JavaOne: Day One

Quaid — Tue, 29 Jun 2004 15:58:00 GMT

Java version numbering - WTFrick!?

I thought 1.5 was 'Java 2.0' (this being crazy in itself), but now the next version is 'Java 5.0'.

!??!?

re: JavaOne: Day One

Nicholas Allen — Tue, 29 Jun 2004 16:01:00 GMT

This is a great summary. There were a few things that caught my eye.

In the new features section, it sounds like that talk really missed the audience.

> Improvements in starting time

I talked a little about that with Junfeng Zhang in the past. Somewhat similar but not quite the same as ngen.

http://blogs.msdn.com/junfeng/archive/2004/04/12/111310.aspx

> New look and feel support

Java has always had pluggable look and feels but there's very few 3rd party ones available. Mostly it was considered too hard to be worth it. In addition to updating the old Metal style, this is supposed to make 3rd party L&F creation easy.

> one of the important design points for the Java version was that it run on all existing JVMs (ie its 1.4 compatible)

This isn't true. If you use 1.5 language features, you're forced to use a 1.5 VM. What they probably said was that code compiled for 1.4 had to work correctly when used with code compiled for 1.5 (and using generics). They support old code on new platforms (backward compat). They do not support new code on old platforms (forward compat).

Eric Gunnerson at JavaOne

David's hubris-o-rama — Tue, 29 Jun 2004 19:11:00 GMT

re: JavaOne: Day One

Nikolay Botev — Tue, 29 Jun 2004 16:57:00 GMT

The following caught my attention and I really could not resist testing it out:

>There are some issues on this that have to do >with object identity. Consider the following:
>
>
>Map m = new Map<Integer, String>();
>m.add(3, foo);
>string s = m.at(3);
>
>What does the third line do? Well, it turns >out that the two 3 values arent the same >because they are autoboxed to different >reference types. That behavior is a bit >surprising.
>
>To improve the situation, theyve come up with >an interesting modification, which I believe >this is not part of the standard, but part of >javac.
>
>They get around this and Im not making this >up by playing tricks for small integer >values, but not for large integer values. >They did not give an exact description for >how this behavior is controlled.

I don't know, maybe I'm doing something wrong, but this example (when all the errors are corrected) seems to work fine for me with large integers (maybe I'm not using a "real" large value?). I did uncover another problem though, but the point is - there doesn't seem to be any "playing tricks with small integers". I wonder what the "magic" number is that Sun chose to separate the space of small ints from large ints :-D. I'm also interested to find out what the source of that information is.

The code that I compiled and ran under the latest snapshot release of Java 5 is below.

The problem I uncovered was when the key is of type Long and an int is used to retrieve the value. The value is not found and this only makes sense, however, this makes space for obscure bugs and should ideally either trigger a compile-time error or automatically autobox to Long instead of Integer.

import java.util.Map;
import java.util.HashMap;

class testnum
{
public static void main(String args[])
{
Map<Integer, String> m = new HashMap<Integer, String>();

m.put(3, "foo");
String s = m.get(3);
System.out.printf("First item: %s\n", s);

m.put(300400600, "boo");
s = m.get(300400600);
System.out.printf("Big item: %s\n", s);

m.put(2100400600, "woohaaa");
s = m.get(2100400600);
System.out.printf("Very big item: %s\n", s);

Map<Long, String> m2 = new HashMap<Long, String>();

m2.put(9L, "smallee");
s = m2.get(9L);
System.out.printf("Long 1st item: %s\n", s);
s = m2.get(9); // auto-boxed to Integer?
System.out.printf("Long 1st item problem!: %s\n", s);

m2.put(9223372036854775807L, "now this is crazy!");
s = m2.get(9223372036854775807L);
System.out.printf("It really doesn't get any bigger than this: %s\n", s);
}
}

re: JavaOne: Day One

thomas woelfer — Tue, 29 Jun 2004 18:00:00 GMT

Eric,

thanks for the summary. almost as good as beeing there in person... :)

WM_THX
thomas woelfer

re: JavaOne: Day One

Robert O'Callahan — Tue, 29 Jun 2004 18:34:00 GMT

> Map m = new Map<Integer, String>();
>
> m.add(3, foo);
>
> String s = m.at(3);

This will work fine. The boxed versions of 3 may or may not be the same object, but they will be equal according to equals() and hashCode(). I think Mr Gunnerson is confused.

re: JavaOne: Day One

Nicholas Allen — Tue, 29 Jun 2004 19:40:00 GMT

Where it'll break is IdentityHashMap or other code which uses == for identity instead of equals for identity. But we've lived through that long enough with strings and survived.

re: JavaOne: Day One

Luke Hutteman — Tue, 29 Jun 2004 22:46:00 GMT

Your C# foreach code can be done in 5.0 using the new for-construct "for (int i: a)" - not quite as easy to read/understand as c#'s foreach notation, but it essentially does the same thing and I can understand a reluctance to introduce new keywords.

as others have noted, the Map example only breaks down when you use an IdentityHashMap, which is a fairly little used Map implementation that uses object equality instead of hashcode() and equals(). For more information on IdentityHashMap and some usage examples, check out the JavaDocs at http://java.sun.com/j2se/1.4.2/docs/api/java/util/IdentityHashMap.html

re: JavaOne: Day One

Chad Myers — Tue, 29 Jun 2004 23:20:00 GMT

As a former Java developer, it's kinda sad to see Sun flailing around like this (implementing some new features, but only half-way or healt-heartedly) and trying to strike back at C# or something.

Java started out so pure and straight-forward and I was proud to develop on it.

But now whenever I have to go back and try to use it, I'm confounded by it's lack of progress. It's not very different now (1.4 or 5 ) than it was in the 1.3 days. Very little XML support (or chumpy support at that)... very little of anything. If you want to do anything useful with Java, you have to end up downloading 35 different 3rd-party libraries (most usually from Apache-Jakarta) and then enter into "Classpath Hell".

It just leaves me scratching my head.

On that note, excellent work on C# 1.x and 2.0 Eric and Team. I'm rarely left scratching my head on anything (well, unsafe stuff still confuses me, but you know what I mean).

re: JavaOne: Day One

Jocelyn Coulmance — Wed, 30 Jun 2004 08:48:00 GMT

> One of the disadvantages in some generic approaches (C# included) is that theres no way to express List<anything>. Well, actually, there is you can write:

> List<object> c;

List<?> should not be read as "List of anything" (which is what List<object> conveys) but "any list of something".
And yes, this is a feature I'd like to have in C#.

Notes from JavaOne

Rubber Chicken — Wed, 30 Jun 2004 18:35:00 GMT

Some interesting notes from a Microsoft attendee at JavaOne....

re: JavaOne: Day One

John Harby — Thu, 01 Jul 2004 20:34:00 GMT

Thanks for your insights, this is very interesting.

JavaOne 2004: Final Thoughts

Eric Gunnerson's C# Compendium — Thu, 08 Jul 2004 18:20:00 GMT

Java vs Whidbey Generics

Girish Bharadwaj — Fri, 09 Jul 2004 05:13:00 GMT

test

protected virtual void jayBlog { — Fri, 09 Jul 2004 06:07:00 GMT

re: JavaOne: Day One

Joe Cheng — Sat, 10 Jul 2004 06:26:00 GMT

If I understand correctly, the "wildcards in generics" feature is better known elsewhere as covariance/contravariance.

Identity of boxed integers

Stephen Leach — Tue, 13 Jul 2004 20:45:00 GMT

I agree that the Java dev have made a crucial design decision here. Experimentation with Java 1.5/5.0 shows that very small integers box identically and large ones don't. I also agree it is a mistake - it is a rerun of the String.intern() mistake.

re: JavaOne: Day One

Bernhard Messerer — Tue, 13 Jul 2004 22:43:00 GMT

Indeed, the spec says that this "small int trick" is done with byte-values: All byte values MUST be cached and thus will be boxed to the same ("==") integer (thus it even works with IdentityHashMap).
For larger ints, behavior is unspecified, they may or may not be cached, in Sun's implementation (JDK 1.5 Beta2) it will use Integer.valueOf(int), which caches "frequently used" values, so it should even work with larger numbers... no guarantee though...
Note that it worked differently with Beta1, this one didn't cache any values...
Overally I agree, its a stupid decision as it draws a virtual limit within the language. Practically, it shouldn't lead to many bugs, as objects should never be compared with "==".

Messi

P.S.: I think they should have left the whole autoboxing "feature" out...

re: JavaOne: Day One

Bernhard Messerer — Tue, 13 Jul 2004 22:46:00 GMT

P.P.S.: What's wrong with String.intern()?
_Always_ compare objects with equals(), "==" checks for identity... Strings offer the ability to "cache" Strings at the JVM level via intern(), very good for often used strings... however, you're not forced to use it...

Messi

Re: Java vs. .NET

Channel 9 — Wed, 04 Jun 2008 02:03:36 GMT

If by metadata u mean Attributes then the answer is not yet.