[JBoss JIRA] (ROASTER-125) Add APIs for class and member initializers
by Kevin Mian Kraiker (JIRA)
[ 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:39 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 post, 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.
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 post, 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.
> 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)
6 years, 7 months
[JBoss JIRA] (ROASTER-125) Add APIs for class and member initializers
by Kevin Mian Kraiker (JIRA)
[ https://issues.jboss.org/browse/ROASTER-125?page=com.atlassian.jira.plugi... ]
Kevin Mian Kraiker commented on ROASTER-125:
--------------------------------------------
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 post, 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.
> 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)
6 years, 7 months
[JBoss JIRA] (ROASTER-10) Auto generated imports when a field type is set causes .java file to not compile.
by Antoine Lefebvre (JIRA)
[ https://issues.jboss.org/browse/ROASTER-10?page=com.atlassian.jira.plugin... ]
Antoine Lefebvre commented on ROASTER-10:
-----------------------------------------
I also got an issue when trying to create a wrapper class that encapsulate a class of the same name.
Example:
{code:java}
package myPackage;
import anotherPackage.myClass;
public class myClass()
{
private myClass _myclass; // this is wrong it is should use the FQN i.e. anotherPackage.myClass
}
{code}
> Auto generated imports when a field type is set causes .java file to not compile.
> ---------------------------------------------------------------------------------
>
> Key: ROASTER-10
> URL: https://issues.jboss.org/browse/ROASTER-10
> Project: Roaster
> Issue Type: Bug
> Components: API
> Affects Versions: 2.2.0.Final
> Reporter: Walter Medvedeo
> Fix For: 2.x Future
>
>
> When we set the Type for a given field using the FieldSource.setType( X ) methods an import is generated automatically.
> Under some situations it causes the resulting class to not compile and it's not posible to fix it using the api.
> In order to avoid this, and also to be able to modify a given class in a more "safe or controlled" way (for example in cases when we don't want to manage complex refactorings or controlling imports), It's desirable to have setType( X, boolean addImports) method that just change the field type to the provided type name and don't add imports.
> e.g:
> Given the following declaration:
> private org.test.Class1 myField;
> myField.setType("org.somepackage.Class2", false)
> will produce the following result:
> private org.somepackage.Class2 myField;
> and:
> myField.setType("Class2", false)
> will produce the following result:
> private Class2 myField.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months