[
https://issues.jboss.org/browse/ROASTER-125?page=com.atlassian.jira.plugi...
]
Kevin Mian Kraiker edited comment on ROASTER-125 at 9/11/17 8:41 AM:
---------------------------------------------------------------------
Since I needed to work with initializers in a project that already used Roaster, I gave a
try delving in this part of the issue - what I ended up with is available in the master
branch of [
https://github.com/CRC-Mismatch/roaster]. With the state as of this comment, I
found three main problems:
# Only Classes and Enums allow initializer blocks, but the common
AbstractJavaSourceMemberHolder super type is also extended by JavaInterfaceImpl, so
it's not possible to simply implement an InitializerHolder in it. The only possible
solutions I thought of were either implementing them separately in both JavaClassImpl and
JavaEnumImpl (unmaintainable), creating an interface and using default implementations
(hackish, I'm not sure how the BodyDeclaration could be accessed from it and would
also require Java 1.8) or reorganizing the Abstract classes so that both JavaEnumImpl and
JavaClassImpl extend a new Abstract class that JavaInterfaceImpl does not.
# The order of initializer blocks is important, and also "interacts" with the
order of the field declarations, so it's not as easy as using Lists.
# The only way to refer to initializer blocks is by position and/or static modifier, so
getting and removing intializer blocks depend on where they appear, and adding a new one
must allow defining a position where to insert it.
And that's just for the initalization blocks, anonymous instances are still another
mystery.
was (Author: mismatch):
Since I needed to work with initializers in a project that already used Roaster, I gave a
try delving in this part of the issue - what I ended up with is available in the master
branch of [
https://github.com/CRC-Mismatch/roaster]. With the state as of this comment, I
found three main problems:
# Only Classes and Enums allow initializer blocks, but the common
AbstractJavaSourceMemberHolder super type is also extended by JavaInterfaceImpl, so
it's not possible to simply implement an InitializerHolder in it. The only possible
solutions I thought of were either implementing them separately in both JavaClassImpl and
JavaEnumImpl (unmaintainable), creating an interface and using default implementations
(hackish, I'm not sure how the BodyDeclaration could be accessed from it and would
also require Java 1.8) or reorganizing the Abstract classes so that both JavaEnumImpl and
JavaClassImpl extend a new Abstract class that JavaInterfaceImpl does not.
# The order of initializer blocks is important, and also "interacts" with the
order of the field declarations, so it's not as easy as using Lists.
# The only way to refer to initializer blocks is by position and/or static modifier, so
getting and removing intializer blocks depend on where they appear, and adding a new one
must allow defining a position where to insert it.
And that's just for the initalization blocks, anonymous instances are still another
mystery.
Add APIs for class and member initializers
-------------------------------------------
Key: ROASTER-125
URL:
https://issues.jboss.org/browse/ROASTER-125
Project: Roaster
Issue Type: Feature Request
Reporter: Aaron Tull
There are gaps in the API JavaClassSource for finding the body of static and member
initializers. For instance, the following class shows 3 code blocks which cannot be
accessed from the API without delving into the AST internals.
{code:java}
public class TestSource {
{
// ... instance initialization block
}
static {
// ... static initialization block
}
private Runnable innerMember = new Runnable() {
@Override
public void run() {
// ... member field initialization to anonymous class instance
}
}
// class definition not found
private static Runnable nestedMember = new Runnable() {
@Override
public void run() {
// ... static field initialization to anonymous class instance
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)