For ARM-blocks you can have a look at the @Cleanup annotation of
Lombok and have ARM-blocks for Java right now!
The following code will close both streams correctly after they run
out of scope.
import lombok.Cleanup;
import java.io.*;
public class CleanupExample {
public static void
The neat thing about this is that we do not have to wait until the
Java API has been retrofitted with the Disposable interface. However,
you won't get the scope limitation benefits (the in and out variable
is scoped the whole method). I kind of wish we could use annotations
on blocks, so this
Caster, that is not entirely correct. The close methode (actually,
close is just the default, you can specify an other method name if you
want) will be called when the variable goes out of scope.
Unfortunately, java does not allow an annotation on a code block. So
an equivalent programm would be:
Fabrizio Giudici wrote:
mbien wrote:
Hi Fabrizio,
I 'll work on a JNI/GlueGen based OpenCL binding to Java as part of my
bachelor thesis. If everything works well it will be an optional
extension of JSR231 aka JOGL (and will also fully interoperate with
JOGL).
...open source as soon
I think you misunderstood Roel. I am aware of the method name argument
override, I was merely exploring the different implementations and
implications of these two ARM blocks. The JDK7 version would have to
rely on a new interface Disposable being added to the libraries, as
the abomination known
Casper,
You are correct. I just wanted the other readers to know that it is
not limited to close. It is however limited to no-args methods.
Roel
On Sep 1, 4:10 pm, Casper Bang casper.b...@gmail.com wrote:
I think you misunderstood Roel. I am aware of the method name argument
override, I was
I actually prefer @Cleanup to the JDK 7 proposal in that it presumably
just cleans up at the end of the variable's scope ala C++.
If you need ordering amongst several @Cleanup variables, then you can
always introduce {...} scoping, right? If so, then I'd rather introduce
such things only as
True, but I don't think many are aware of this. The JDK7 proposal by
Joshua Bloch specifically adds the multi-scoping aspect over the
existing C# implementation, which only allows multi-scoping of the
same type.
Constructs that minimizes variable leakage into scope space (temporary
variables)
Yes, you can scope to your hearts content with {} blocks. For those
not aware of this:
There's a rarely used feature of the java language: separate blocks.
You can put { (statements) } anywhere in java code where a statement
is legal. Like any other occurrence of {} to delimit code, any
Hi Friends,
I need your help.
I have written this code to get the transliteration in Java. BUt it
gives me incorrect output for 4 words...
%@ page language = java %
%@ page import = java.sql.* %
%@ page import = java.util.* %
%@ page import = java.io.* %
%@ page import=java.lang.* %
%@ page
Casper Bang wrote:
True, but I don't think many are aware of this.
Hmm I've used {...} liberally for scoping in Java and C++ since I
first used C++. It's one reason I consider C unusable even compared to
C++'s and despite C++'s sins.
The JDK7 proposal by
Joshua Bloch specifically adds
for local variables, javac actually does almost nothin:it only frees
that local variable slot for a future local variable
theres a nice puzzle about that in the java specialists newsletter:
http://www.javaspecialists.eu/archive/Issue173.html
of course youre not suppose to know its about local
Don't know what happens underneath, but they appear to be parsed by
the production rule Block - {Statement*} and have the Tree node
associated with a com.sun.tools.javac.code.Scope hashtable that's
special in that they can be nested. That would make sense I guess,
going the other way, a
On Tue, Sep 1, 2009 at 5:44 PM, Mark Derricutt m...@talios.com wrote:
I've always been intrigued by these blocks we have in java, what does javac
actually generate for them?
Not much. It just reuses slots. But don't take my word for it
~/test$ cat Test.java
public class Test {
public
14 matches
Mail list logo
