Skip to main content

Blog Archive for forax during October 2006

Last week, an early draft of Java Module System (JSR277) was published. To sum up, this draft defines : the concept of exportable module, which is closed to OSGi bundle or eclipse plugin. the way modules are packaged, as super jar named Java Archive Module (or jam). and how modules are store in a local repository. One short paragraph at the end of the section 12 of the...
With a colleague, we discuss about the fact that function type can or not obfuscate Java code and he advocate the fact that a code in Java is always readable if you have an IDE that can auto-format the code. The following example doesn't answer to the question about function type but shows that it is always possible to write an obfuscated code even in Java. This example is extracted...
Recently a user named jirkahana post a topic on the java.net JDK forum about the fact that javax.xml.stream.XMLReader inherits from a non generified Iterator. I've kickly sumbitted a bug report (6472193 and as i'm a jdk contributor, i've provided a patch that correct the bug. Now, we are late in the sceduling of mustang, and only showstoppers bug can be corrected. So here is my question...
When you want to add features to a language without breaking backward compatibility, a widespread idea that you can't add new keywords. That is why we can currently see weird proposal in Java space that try to reuse old keywords to express new kind of abstraction, by example, synchronized (closure v0.2 section 3) or (Neal Gafter blog about for). Why introducing a new keyword breaks...
Neal proposes to use for to tag methods that take a synchronous closure as parameter and to call this new kind of method. It's better than to use synchronized as proposed before but (there is always a but :) i see two drawbacks. First, for is used to tag the whole method and not one of its parameter so there is no way to define a method that takes a synchronous closure and an...