Hello from JavaOne 2008
-
quantus
- Tenth Dan Procrastinator
- Posts: 4891
- Joined: Fri Jul 18, 2003 3:09 am
- Location: San Jose, CA
Hello from JavaOne 2008
Well, since I've got the free time and it's free to attend for students, I'm at JavaOne. There was a bit of a hiccup during registration since they had students fax in their registration and they lost mine. Still, they were nice and let me in anyway. I'll post more about it later as I actually get to do and see stuff.
-
quantus
- Tenth Dan Procrastinator
- Posts: 4891
- Joined: Fri Jul 18, 2003 3:09 am
- Location: San Jose, CA
Re: Hello from JavaOne 2008
So, JavaOne was actually pretty interesting. They were discussing a fairly wide range of things from the Sparc and Niagra processors to all of the various uses for Java. Their was also a lot of talk about their strategy to be extremely open with their technologies.
I was trying to attend sessions where they would talk about their strategies to deal with the proliferation of multi-core processors and how to better map applications to it. They seem well aware of the issues involved and seem to have solved at least some of the problems that are encountered at the hardware, hypervisor and OS levels, but at the application level they seems stuck just like everyone else. There was a talk in the very last session about where to go with the JVM for multiple processors. They talked about how garbage collection is an evolutionary successor to malloc and how garbage collection will at least scale in the short term to 32 or 64 processors. However, they liken the application programming trouble to the lack of evolution path for locking. There seems to be a clamoring for transactional memory to be implemented in hardware as a possible way to ease the programming trouble. This would need to be paired with changes to the languages, especially OOP languages where the locks have traditionally been buried in the objects, to a more declarative style of saying that a region is atomic. The transactional memory would then help identify collisions and trigger roll-backs of the atomic portions, which would then be retried. However, this won't always work because there are operations just just can't be rolled back, like sending data down a stream. So, it ended like every other talk on programming for multiple cores with a survey of possible application specific solutions (stream programming, etc) or use of languages like Erlang or Scala.
On a different note, there's a definite shift in interest from plain old Java towards interpreted languages that will run on the Java platforms -- Jython, JRuby, Groovy and Grails. Also, the technologies are much more integrated than I thought they were. I must admit, all the project names and figuring out how they all fit together was a bit bewildering especially when most presenters just assumed that you already have a clear picture of what they're talking about. About half the people who show up to many of these talks don't really know the technology (because there's so friggin' many of them), which makes it a poor assumption in my opinion. It also looks like using NetBeans is much nicer than using Eclipse for most of the newer languages. There's even pretty nice javascript support which I haven't really seen in other IDEs because of all the stupid browser differences and the fact that it is loosely typed. jMaki (maki = wrap in Japanese) was interesting since it actually took several of the javascript libraries from Yahoo, Google and several other sources and "wrapped" them to provide consistent interfaces. This makes it incredibly easy to do mashups. Sang Shin of http://www.javapassion.com gave the first talk I saw about jMaki and ran through several of the tutorials on his site. There's a ton of walk-throughs to try there.
There were several other technologies that I got a chance to take a look at like Real-time Java, Sunspots, Live Scribe, JavaFX, etc that I'll talk about in a later post when I have more time. Now, I must read for school.
I was trying to attend sessions where they would talk about their strategies to deal with the proliferation of multi-core processors and how to better map applications to it. They seem well aware of the issues involved and seem to have solved at least some of the problems that are encountered at the hardware, hypervisor and OS levels, but at the application level they seems stuck just like everyone else. There was a talk in the very last session about where to go with the JVM for multiple processors. They talked about how garbage collection is an evolutionary successor to malloc and how garbage collection will at least scale in the short term to 32 or 64 processors. However, they liken the application programming trouble to the lack of evolution path for locking. There seems to be a clamoring for transactional memory to be implemented in hardware as a possible way to ease the programming trouble. This would need to be paired with changes to the languages, especially OOP languages where the locks have traditionally been buried in the objects, to a more declarative style of saying that a region is atomic. The transactional memory would then help identify collisions and trigger roll-backs of the atomic portions, which would then be retried. However, this won't always work because there are operations just just can't be rolled back, like sending data down a stream. So, it ended like every other talk on programming for multiple cores with a survey of possible application specific solutions (stream programming, etc) or use of languages like Erlang or Scala.
On a different note, there's a definite shift in interest from plain old Java towards interpreted languages that will run on the Java platforms -- Jython, JRuby, Groovy and Grails. Also, the technologies are much more integrated than I thought they were. I must admit, all the project names and figuring out how they all fit together was a bit bewildering especially when most presenters just assumed that you already have a clear picture of what they're talking about. About half the people who show up to many of these talks don't really know the technology (because there's so friggin' many of them), which makes it a poor assumption in my opinion. It also looks like using NetBeans is much nicer than using Eclipse for most of the newer languages. There's even pretty nice javascript support which I haven't really seen in other IDEs because of all the stupid browser differences and the fact that it is loosely typed. jMaki (maki = wrap in Japanese) was interesting since it actually took several of the javascript libraries from Yahoo, Google and several other sources and "wrapped" them to provide consistent interfaces. This makes it incredibly easy to do mashups. Sang Shin of http://www.javapassion.com gave the first talk I saw about jMaki and ran through several of the tutorials on his site. There's a ton of walk-throughs to try there.
There were several other technologies that I got a chance to take a look at like Real-time Java, Sunspots, Live Scribe, JavaFX, etc that I'll talk about in a later post when I have more time. Now, I must read for school.