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
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...