J2SDK 5.0 feature usage?

Submitted by epr on Mon, 04/11/2005 - 08:18.

I think it is getting time to investigate when we should start to use j2sdk 5.0 features.
Currently the classpath project has a generics branch with 5.0 classes, but this will not be the main branch for at least several month.

However I would love to use the enum feature and I think it can be done without too much effort.

Using 5.0 features will however force the use of a 5.0 compiler for all of us. So it is not a small step to take.
Since j2sdk 5.0 is now widely available and eclipse 3.1(M6) is getting stable enough to use, I propose to discuss if we should start using some of the features, like enum's and maybe generics. (but not for collections yet).

What do you think.

PS. Please do not use 5.0 features until we decided on this.

Ewout

‹ JBuilder open source Building a Scalable JVM ›

Annotations

Submitted by lsantha on Mon, 04/11/2005 - 20:33.

Among the new language features and APIs of Jdk 1.5 annotations could have a special usage in JNode.
They could be a good replaceement for the many marker interfaces and "marker exceptions" used at the momnet.
For this we would need to define a standard set of JNode annotations that could be aplied systematically to the code.
Annotations can be useful for giving hints to the runtime system about the code being run.
For instance, an annotation named @NoEscape applied (very carefully) to a method, could inform the bytecode to native compiler that the method creates no escaping objects which means that code is generated to explicitly free all locally allocated memory when the method exits, reducing the burden on the GC.
(A compiler with built-in escape analysis would make this feature obsolate)

An other Jdk1.5 feature, the support for byte code instrumentation would be useful for logging, profiling and espcially debugging (an important lacking feature in JNode) purposes.

Levente

@NoEscape

Submitted by monochromata on Tue, 04/12/2005 - 12:49.

I think if all locally generated objects should be explicitly freed on method exit (don't know if this is really a good idea, but that should be decided by the GC experts) this decision should be made automatically at runtime (your second suggestion), since the annotation-approach introduces a new source of errors.

E.g. a method that previously contained only local variables is changed to assign a value to a field but the developer forgets to remove the @NoEscape tag. What would then happen at runtime?

Sebastian

Bad things

Submitted by lsantha on Tue, 04/12/2005 - 13:09.

This was just an example, and I was aware of its dangers.
It is a risky feature but it might have some benefits if used carefuly only in JNode specific code at places where it would really make sense and by people who know what they are doing. This idea came to my mind on knowing that the optimising L2 compiler seems to be far away not to mention one with escape analysis...

Levente