Here are the few highlights from the talks that I attended today:
Most compilers have some (or in some cases many) intrinsic functions. HotSpot has a number of them (see here, search for "intrinsics known to the runtime") as does the CLR JIT. IKVM has had a couple as well (System.arraycopy(), AtomicReferenceFieldUpdater.newUpdater(), String.toCharArray()). These were sort of hacked into the compiler and I finally decided to clean that up a little and add more scalable support ...
In this year's JavaOne pavilion, you can get shirt's printed with your own answer to this year's conference theme posed as a question
Today Bill, Chihiro, Jaya and I talked on Blu-ray. The talk was centered around the open source project @ http://hdcookbook.dev.java.net - a library and a set of tools to build Blu-ray discs. If you haven't checked out code/docs, you may want to checkout and play with the code. All you need is a laptop with blu-ray drive and a BD-RE disc. Optionally, for added fun you ...
invokedynamic instruction in one form or another. The problem has been with picking the one form that simultaneously enables a good range of use cases, addresses several architectural challenges in the JVM, and can be optimized by a variety of commercial JVMs. It has been a restless search for “one bytecode to rule them all”. ...With the magic of Mercurial, you can see changesets, like this one: http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/485d403e94e1. Which Serguei Spitsyn integrated recently.
A while back Sébastien Auvray asked me some questions about the OpenJDK Mercurial conversion. His article was recently published at http://www.infoq.com/articles/dvcs-guide.
In javac land, we're looking at improving the diagnostic messages generated by the compiler ...
Hello, JSR 292 observers and language implementors!
As some of you may know, we've made changes recently to the KSL project that was started last year.
Although it might not be a very good idea to define your management
model based on how it will be displayed by a given GUI, such as that
provided by JConsole or
VisualVM, I believe it is nonetheless
interesting to explore the various ways in which a complex type
such as a
Map<String,Integer> could be modeled and
exposed through an MXBean attribute.
Now that the source code for the OpenJDK Regression Test Harness (jtreg) is available, this provides an overview of how jtreg relates to JT Harness.
I'm pleased to announce the release of our second performance release, JDK 6 Update 5-P. Its available to download at http://java.sun.com/performance. This is our fastest JDK to date, released just in time for JavaOne.
A couple of fixes.
A couple of fixes.
Changes:
Binaries available here: ikvmbin-0.36.0.12.zip
Sources (+ binaries):ikvm-0.36.0.12.zip
[I wrote most of this about a month ago. If I don't post it now, I never will do. I'm sure there were a couple things I meant to add.]
That is, pure java OpenGL, no need of native code, runs everywhere there is an X11 server and does a nice Italian coffee too :)
Huzzah! Through the dedicated efforts of Jon and others, jtreg is now open sourced! The jtreg program is the test harness used to run the regression tests that come with the JDK sources.
The reality for Java is that there are many other programming languages, and many of those have features that Java developers sometimes wish they could access. But its simply impossible to add all those features. Is there a possible alternative if we think 'outside the box'?
Thanks to the hard work and dedication of a big team of people both inside of Sun, and in the Free Java community working on projects as diverse as GNU Classpath, GCJ, and IcedTea, Sun's open source Java initiative has reached a new milestone. Both Ubuntu 8.04LTS (Hardy Heron) and the upcoming Fedora 9 releases have an OpenJDK-based implementation of the JDK in their ...
A collection of links to various JDK Build readme files.
In JavaOne 2008, there are many intesting sessions on "other" JVM languages covering both dynamically typed languages (JavaScript, Groovy, JRuby) and statically typed languages (JavaFX, Scala). As usual, there are many sessions covering application aspects -- like using scripting on Glassfish, Grials (Groovy), Rails (JRuby) and so on. But, my interest is mostly on the programming language aspects and JVM implementation issues. Here is a ...
Just a quick post to outline my plans for JavaOne.
If you want to learn more about Blu-ray disc and what Java has to do with it, you may want to attend the following talks/BOFs @ JavaOne 2008!
There is now 2 RSS feeds (thanks to gengo plugin) :
Moreover, since I am now using Wordpress, my blog allow comments
So, please update your bookmarks because I might remove the old site (probably in one month).
]]>There is a old joke about walking along one night and coming across someone looking down underneath a streetlight for lost keys. Stopping to help look, after a minute or two of searching you remark, "Your keys don't seem to be here. Where did you drop them?" "Well, I dropped them over in that ally, but it's way too dark to look there!"
I've gathered together a few more thoughts on improving the enhanced for-each loops. The basic idea is to take this very popular Java 5 feature and provide the missing parts.
Peter Kriens, the OSGi spec lead and official evangelist, takes a positive view of language-level modularity. His focus on "requirements, not solutions" is especially helpful. Here are some responses to his points:
... while working on uncommitted changes.
Back in JDK 5, JSR 13 added true floating-point arithmetic to BigDecimal, which involved many new methods and constructors along with new supportingclasses in the java.math package. I was actively involved in the JSR 13 expert group and integrated the code into the JDK. These changes had some surprising compatibility impacts which can be classified according to their source, binary, and behavioral effects. ...
Have you ever been fustrated by the new Java 5 for each loop because it didn't operate directly on maps?
Developers are asking where the changesets are, reminds me of that movie Dude, Where's My Car?, "Dude, Where's My Changeset?"
When evolving the JDK, compatibility concerns are taken very seriously. However, different standards are applied to evolving various aspects of the platform. From a certain point of view, it is true that any observable difference could potentially cause some unknown application to break. Indeed, just changing the reported version number is incompatible in this sense because, for example, a JNLP file can refuse to ...
Yeah!
Yesterday Miguel blogged about a nice new feature in Mono. I added the IKVM_VERBOSE_CAST environment variable to IKVM to do something similar a while ago.
Yesterday Miguel blogged about a nice new feature in Mono. I added the IKVM_VERBOSE_CAST environment variable to IKVM to do something similar a while ago.
public class
test {
public static void main(String[]
args) {
System.out.println((String)(Object)args);
}
}
C:\j>\ikvm-0.36.0.11\bin\ikvm test
Exception in thread "main" java.lang.ClassCastException
at test.main(test.java)
C:\j>set IKVM_VERBOSE_CAST=1
C:\j>\ikvm-0.36.0.11\bin\ikvm test
Exception in thread "main" java.lang.ClassCastException: Object of type "System.String[],
mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" cannot
be cast to "System.String, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
at test.main(test.java)
Note that the assembly qualified type names are displayed, as I believe this feature is particularly useful when trying to debug issues that arise from having loaded multiple assemblies that contain the "same" types.
While writing this I discovered that both JDK 1.6 and .NET 2.0 always generate descriptive exception messages for invalid casts:
C:\j>\jdk1.6\bin\java test
Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.String; can not
be cast to java.lang.String
at test.main(test.java:5)
C:\j>\ikvm\bin\ikvm test
Exception in thread "main" java.lang.ClassCastException: Unable to cast object of
type 'System.String[]' to type 'System.String'.
at test.main(test.java:5)
This last result is my local ikvm development version running on .NET 2.0 with a patch to enable taking the exception message from the .NET InvalidCastException, which I didn't previously do because on .NET 1.1 this message didn't contain any useful information.
On April 11, the OpenJDK 6 b09 source bundle was published.
So this is a little story in anticipation of tax day tomorrow.
VisualVM Beta 2 has been released.
We (almost) did it!
It's been quite a while since the last development snapshot. I'm still working on
integrating .NET 2.0 features, but I'm also doing random fixes/improvements here and
there as I come across them. The biggest visible change in this snapshot is the support
for defining .NET properties as Java fields. The main motivation was that I wanted
to handle the System.in/out/err fields more cleanly. They ...
It's been quite a while since the last development snapshot. I'm still working on
integrating .NET 2.0 features, but I'm also doing random fixes/improvements here and
there as I come across them. The biggest visible change in this snapshot is the support
for defining .NET properties as Java fields. The main motivation was that I wanted
to handle the System.in/out/err fields more cleanly. They are now implemented
like this:
@ikvm.lang.Property(get="get_in")
public final staticInputStream in;
static { in = null; }
private staticInputStream get_in()
{
return StdIO.in;
}
This defines a .NET property called "in" and associates the getter method of the property with the get_in() method. Note that we're only specifying the getter here in the Property annotation because the field is final, but you can also specify a setter method. The static initializer that initializes the property to null is necessary to keep javac happy, but it doesn't actually do anything. The ikvm bytecode compiler will ignore any assignments to read-only properties. Another thing to note is that the get_in() will automatically be made public (because the field is public), but from Java it will still appear private.
Changes since previous development snapshot:
WARNING: THIS IS A DEVELOPMENT SNAPSHOT, NOT AN OFFICIAL RELEASE.
Development snapshots are intended for evaluating and keeping track of where the project
is going, not for production usage. The binaries have not been extensively tested
and are not strong named.
If you want to run this version on Mono, you'll need a Mono version built from recent
svn, it does not work on Mono 1.9.
Binaries available here: ikvmbin-0.37.3026.zip