Skip to main content

Support for named code blocks

13 replies [Last post]
Joined: 2003-06-10

By the way, it would be interesting have support for named block in java language and javac compiler. This would allow to access information about method slicing in the runtime or after compilation.

The syntax could be like this:

@SomeAnnotation(...) {...}

@SomeAnnotation(...) synchronized(...) {...}

for(...) @SomeAnnotation(...) {...}

if() @SomeAnnotation(...) {...}
else @AnotherAnnotation(...) {...}

@SomeAnnotation(...) {
} catch()
@AnotherAnnotation(...) {

From a bytecode point of view, this can actually be implemented as a new attribute that would have values for start and end offsets within the method bytecode (similar to try/catch) and also value for the block annotation.

The use cases for this feature are belong to the postprocessing tools including AOP-like instrumentation. For example you can declaratively apply advices on synchronization block and for example implement non-intrusice persistence, data replication or clustering.

I wonder if this can be considered for Dolphin...

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-07-16

Sound like you really just want to use Ruby, Groovy, or Scala (depending on your level of interest in Java and/or dynamic vs. static typing).

Joined: 2004-05-23

I'd just like to use APT for myself! -- I'll get to it...

I admit that some uses of annotations can make the code harder to maintain and less readable -- if the annotation implementations are hard to find and/or hard to understand in context -- but, a couple of standard annotations might go a long way.

This would be classic:

public void [b]foo() {[/b]
[b]@[/b]AWTEventThread [b]{[/b]
// Body of run method here.

I do feel several good points have been made about possible problems; but some aspects seem very good.

- Steev.

Joined: 2003-08-24

Stop trying to use annotations for everything!

EJB3 annotations are useful because they place configuration meta-data right beside the method/class being configured. @AWTEventThread is utterly useless in the sense you can already do this using normal Java code and it is right beside the code it affects.

We need more hard-line guidelines for when annotations should be used versus normal code. I personally believe annotations should be used as the exception to the rule, not before normal Java code.

Joined: 2003-06-10

Folks, as one who brought this up I have to say that things been suggested here is wasn't the reason I suggested this feature.

The goal is to help compilers and debuggers to get information about code. That means optional debug logging, null reference analysis, hints for profilers, and all kind of stuff you don't want to have in production code, but don't wan't to erase either.

Joined: 2006-05-14

i wanna be online my site. but not frameset, syntax, document DTML, tidy dor body my web.
i want to know is it. and i wanna too aplication without purchase.
how do aplication for all

Joined: 2003-06-11

This can be easily achieved today, creating methods for every block you want to annotate. A good compiler will optimize the invocations of this methods.

If you want to probe the usefulness of this type of annotations, you could make a compiler with support for this anotations, and automatically generate synthetic private methods for every anotated block. You can also anotate this special synthetic methods with a new anotation to indicate the container method or even the sequence of blocks.

Remember generics where implemented before as an extension to Java, while achieving full compatibility with the current java bytecode format at this time.

Joined: 2004-10-07

at least, some people try to do the same thinks with C#


Joined: 2006-05-12

The upshot of this idea -- being able to put annotations on blocks of code ... or even anywhere -- seems so natural and useful, I'm surprised not to see more discussion about it.

Lots of uses:

- mark items @TODO inside of methods, for parts of methods not implemented yet

(if a target is needed, a {} could be used, but if we talk about retention=source annotations, it could make sense not to have any target at all on some annotations)

- writing parallel/distributed code (my favourite usage, since this is ugly with inner Runnables; such annotation could have extensions for, eg, running in a Display thread, specifying dependencies, joins, dropping tasks if more recent are submitted, etc):

System.out.println("one thread");
@RunInBackground(name="fooA",priority=5) {
System.out.println("if apt does its job, this is a different thread");

- parametrising try/catch behaviour (don't write thousands of catch instructions)

- localising log levels (thereby allowing log statements to be removed in production; this is Euxx's comment)

- marking different sections of code as being written by different authors

Don Schwarz noted this desire early on, at , but I've not seen many other people clamouring for it. I think it would definitely take java+annotations to the next level.

Personally it seems Java 1.5 went 95% of the way to allowing a powerful and slick macro facility, and then people got cold feet. The macro facility is in place (eg apt, and Sun's suggested @remote to generate interfaces), so no one can take the moral high ground about a pure macro-less language ... but it's limited to entities when the real power of it comes from annotation preprocessing at the code level.

Please, could we see annotations on code blocks, and/or target-less source-retention-only annotations?


Joined: 2004-05-23

I think this is a great idea.

- Steev Coco.

Joined: 2003-06-10

I quite like the idea... a uses I can think of:
Naming and grouping inserted statements; this would make it easy for bytecode instrumentation users to insert instructions and also to check if a method body contains a instruction group; for instance, profilers or loggers (using instrumentation) could simply query all the blocks with the annotation to see if they had already inserted changes;

It would be good to make this consistent in the whole bytecode, by giving the method body an annotation as well (method_body_ or something).

Message was edited by: murphee

Joined: 2003-06-10

I've blogged a bit more about internal details and added some simple example at

Joined: 2003-12-02

sounds suspiciously like you want labels and goto to allow jumping to whereever you wish within the execution path.

If you want that, use Basic...

Joined: 2003-06-10

> sounds suspiciously like you want labels and goto to
> allow jumping to whereever you wish within the
> execution path.

You suspect wrongly; these aren't supposed to be jump targets, instead it would allow post-processing or runtime tools to access groups of statements by name.