[JBoss JIRA] (ROASTER-77) JavaType#isLocalClass() is required to avoid some bugs
by Anonymous (JIRA)
[ https://issues.jboss.org/browse/ROASTER-77?page=com.atlassian.jira.plugin... ]
Issue was automatically transitioned when kuzukami.sh created pull request #39 in GitHub
----------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> JavaType#isLocalClass() is required to avoid some bugs
> ------------------------------------------------------
>
> Key: ROASTER-77
> URL: https://issues.jboss.org/browse/ROASTER-77
> Project: Roaster
> Issue Type: Enhancement
> Components: API, JDT, Tests
> Affects Versions: 2.14.0.Final
> Environment: Win 8.1 Pro 64bit, Java 8, Eclipse Mars
> Reporter: Shoji Kuzukami
>
> Although a local class (JSL 14.3. Local Class Declarations) is not fully supported and located in the Roaster, the Roaster library emits a JavaType object corresponds to a local class in some cases. To avoid these not-supported JavaType objects in my application, I introduced an API 'JavaType#isLocalClass()'.
> It's considered that the API will be required even if the local class specification is fully supported in the Roaster. Therefore this introduction of API will not constraint the design of future API.
> Some tests are applied on the API, then the result seems good.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (ROASTER-77) JavaType#isLocalClass() is required to avoid some bugs
by Shoji Kuzukami (JIRA)
[ https://issues.jboss.org/browse/ROASTER-77?page=com.atlassian.jira.plugin... ]
Shoji Kuzukami updated ROASTER-77:
----------------------------------
Description:
Although a local class (JSL 14.3. Local Class Declarations) is not fully supported and located in the Roaster, the Roaster library emits a JavaType object corresponds to a local class in some cases. To avoid these not-supported JavaType objects in my application, I introduced an API 'JavaType#isLocalClass()'.
It's considered that the API will be required even if the local class specification is fully supported in the Roaster. Therefore this introduction of API will not constraint the design of future API.
Some tests are applied on the API, then the result seems good.
was:
Although a local class (JSL 14.3. Local Class Declarations) is not fully supported and located in the Roaster, the Roaster library emits a JavaType object corresponds to a local class in some cases. To avoid these not-supported JavaType objects in my application, I introduced an API 'JavaType#isLocalClass()'.
It's considered that the API will be required even if the local class specification is fully supported in the Roaster. Therefore this introduction of API will not constraint the design of future API design.
Some tests are applied on the API, then the result seems good.
> JavaType#isLocalClass() is required to avoid some bugs
> ------------------------------------------------------
>
> Key: ROASTER-77
> URL: https://issues.jboss.org/browse/ROASTER-77
> Project: Roaster
> Issue Type: Enhancement
> Components: API, JDT, Tests
> Affects Versions: 2.14.0.Final
> Environment: Win 8.1 Pro 64bit, Java 8, Eclipse Mars
> Reporter: Shoji Kuzukami
>
> Although a local class (JSL 14.3. Local Class Declarations) is not fully supported and located in the Roaster, the Roaster library emits a JavaType object corresponds to a local class in some cases. To avoid these not-supported JavaType objects in my application, I introduced an API 'JavaType#isLocalClass()'.
> It's considered that the API will be required even if the local class specification is fully supported in the Roaster. Therefore this introduction of API will not constraint the design of future API.
> Some tests are applied on the API, then the result seems good.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (ROASTER-77) JavaType#isLocalClass() is required to avoid some bugs
by Shoji Kuzukami (JIRA)
Shoji Kuzukami created ROASTER-77:
-------------------------------------
Summary: JavaType#isLocalClass() is required to avoid some bugs
Key: ROASTER-77
URL: https://issues.jboss.org/browse/ROASTER-77
Project: Roaster
Issue Type: Enhancement
Components: API, JDT, Tests
Affects Versions: 2.14.0.Final
Environment: Win 8.1 Pro 64bit, Java 8, Eclipse Mars
Reporter: Shoji Kuzukami
Although a local class (JSL 14.3. Local Class Declarations) is not fully supported and located in the Roaster, the Roaster library emits a JavaType object corresponds to a local class in some cases. To avoid these not-supported JavaType objects in my application, I introduced an API 'JavaType#isLocalClass()'.
It's considered that the API will be required even if the local class specification is fully supported in the Roaster. Therefore this introduction of API will not constraint the design of future API design.
Some tests are applied on the API, then the result seems good.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (ROASTER-76) Which one encloses a local class.
by Shoji Kuzukami (JIRA)
[ https://issues.jboss.org/browse/ROASTER-76?page=com.atlassian.jira.plugin... ]
Shoji Kuzukami edited comment on ROASTER-76 at 7/10/15 3:32 AM:
----------------------------------------------------------------
Another option for the local class specification hit me. Is it a relatively balanced desgin that the 'JavaType#isLocalClass()' is added in the 'JavaType' interface? It's a minimum refactor. The short code of jdt library below can detects the local class decleartion.
-------
public static boolean isLocalClass( final BodyDeclaration dec){
if (dec instanceof TypeDeclaration)
{
TypeDeclaration td = (TypeDeclaration) dec;
return td.isLocalTypeDeclaration();
}
return false;
}
------
was (Author: kuzukami):
Another option for the local class specification hit me. Is it a relatively balanced desgin that the 'JavaType#isLocalClass()' is add in the 'JavaType' interface? It's a minimum refactor. The short code of jdt library below can detects the local class decleartion.
-------
public static boolean isLocalClass( final BodyDeclaration dec){
if (dec instanceof TypeDeclaration)
{
TypeDeclaration td = (TypeDeclaration) dec;
return td.isLocalTypeDeclaration();
}
return false;
}
------
> Which one encloses a local class.
> ---------------------------------
>
> Key: ROASTER-76
> URL: https://issues.jboss.org/browse/ROASTER-76
> Project: Roaster
> Issue Type: Quality Risk
> Components: API, JDT
> Affects Versions: 2.14.0.Final
> Reporter: Shoji Kuzukami
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (ROASTER-76) Which one encloses a local class.
by Shoji Kuzukami (JIRA)
[ https://issues.jboss.org/browse/ROASTER-76?page=com.atlassian.jira.plugin... ]
Shoji Kuzukami commented on ROASTER-76:
---------------------------------------
Another option for the local class specification hit me. Is it a relatively balanced desgin that the 'JavaType#isLocalClass()' is add in the 'JavaType' interface? It's a minimum refactor. The short code of jdt library below can detects the local class decleartion.
-------
public static boolean isLocalClass( final BodyDeclaration dec){
if (dec instanceof TypeDeclaration)
{
TypeDeclaration td = (TypeDeclaration) dec;
return td.isLocalTypeDeclaration();
}
return false;
}
------
> Which one encloses a local class.
> ---------------------------------
>
> Key: ROASTER-76
> URL: https://issues.jboss.org/browse/ROASTER-76
> Project: Roaster
> Issue Type: Quality Risk
> Components: API, JDT
> Affects Versions: 2.14.0.Final
> Reporter: Shoji Kuzukami
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (ROASTER-76) Which one encloses a local class.
by Shoji Kuzukami (JIRA)
[ https://issues.jboss.org/browse/ROASTER-76?page=com.atlassian.jira.plugin... ]
Shoji Kuzukami edited comment on ROASTER-76 at 7/10/15 3:20 AM:
----------------------------------------------------------------
Really? It is too heavy to support fully the specification.
But I yet want to know which design guideline is preferable, 'A local class must be contained in the #getNestedClasses() of the directly enclosing method' or 'contained in the one of indirectly enclosing "Type"'?
Is it preferable that "directly enclosing method" design?
It's happy for me that a local class is removed from #getNestedClasses() of 'indirectly enclosing "Type"' because I can avoid the bug of "The getQualifiedName() for local class" in my application.
was (Author: kuzukami):
Really? It is too heavy to support fully the specification.
But I yet want to know which design guideline is preferable, 'A local class must be contained in the #getNestedClasses() of the directly enclosing method' or 'contained in the one of indirectly enclosing "Type"'?
Is it preferable that "directly enclosing method" design?
That's happy for me that a local class is removed from #getNestedClasses() of 'indirectly enclosing "Type"' because I can avoid the bug of "The getQualifiedName() for local class" in my application.
> Which one encloses a local class.
> ---------------------------------
>
> Key: ROASTER-76
> URL: https://issues.jboss.org/browse/ROASTER-76
> Project: Roaster
> Issue Type: Quality Risk
> Components: API, JDT
> Affects Versions: 2.14.0.Final
> Reporter: Shoji Kuzukami
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (ROASTER-76) Which one encloses a local class.
by Shoji Kuzukami (JIRA)
[ https://issues.jboss.org/browse/ROASTER-76?page=com.atlassian.jira.plugin... ]
Shoji Kuzukami edited comment on ROASTER-76 at 7/10/15 3:20 AM:
----------------------------------------------------------------
Really? It is too heavy to support fully the specification.
But I yet want to know which design guideline is preferable, 'A local class must be contained in the #getNestedClasses() of the directly enclosing method' or 'contained in the one of indirectly enclosing "Type"'?
Is it preferable that "directly enclosing method" design?
That's happy for me that a local class is removed from #getNestedClasses() of 'indirectly enclosing "Type"' because I can avoid the bug of "The getQualifiedName() for local class" in my application.
was (Author: kuzukami):
Really? It is too heavy to support fully the specification.
But I yet want to know which design guideline is preferable, 'A local class must be contained in the #getNestedClasses() of the directly enclosing method' or 'contained in the one of indirectly enclosing "Type"'?
Is it preferable that "directly enclosing method" design?
That's happy for me that a local class is removed from #getNestedClasses() of 'indirectly enclosing "Type"' because I can avoid the bug of "The getQualifiedName() for local class" in my application if they are removed.
> Which one encloses a local class.
> ---------------------------------
>
> Key: ROASTER-76
> URL: https://issues.jboss.org/browse/ROASTER-76
> Project: Roaster
> Issue Type: Quality Risk
> Components: API, JDT
> Affects Versions: 2.14.0.Final
> Reporter: Shoji Kuzukami
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (ROASTER-76) Which one encloses a local class.
by Shoji Kuzukami (JIRA)
[ https://issues.jboss.org/browse/ROASTER-76?page=com.atlassian.jira.plugin... ]
Shoji Kuzukami edited comment on ROASTER-76 at 7/10/15 3:19 AM:
----------------------------------------------------------------
Really? It is too heavy to support fully the specification.
But I yet want to know which design guideline is preferable, 'A local class must be contained in the #getNestedClasses() of the directly enclosing method' or 'contained in the one of indirectly enclosing "Type"'?
Is it preferable that "directly enclosing method" design?
That's happy for me that a local class is removed from #getNestedClasses() of 'indirectly enclosing "Type"' because I can avoid the bug of "The getQualifiedName() for local class" in my application if they are removed.
was (Author: kuzukami):
Really? It is too heavy to support fully the specification.
But I yet want to know which design guideline is preferable, 'A local class must be contained in the #getNestedClasses() of the directly enclosing method' or 'contained in the one of indirectly enclosing "Type"'?
Is it preferable that "directly enclosing method" design?
That's happy for me that a local class is removed from #getNestedClasses() of 'indirectly enclosing "Type"' because I can avoid the bug of "The getQualifiedName() for local class" in my application if local classes are removed from 'JavaType#getNestedClasses()'.
> Which one encloses a local class.
> ---------------------------------
>
> Key: ROASTER-76
> URL: https://issues.jboss.org/browse/ROASTER-76
> Project: Roaster
> Issue Type: Quality Risk
> Components: API, JDT
> Affects Versions: 2.14.0.Final
> Reporter: Shoji Kuzukami
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (ROASTER-76) Which one encloses a local class.
by Shoji Kuzukami (JIRA)
[ https://issues.jboss.org/browse/ROASTER-76?page=com.atlassian.jira.plugin... ]
Shoji Kuzukami edited comment on ROASTER-76 at 7/10/15 3:18 AM:
----------------------------------------------------------------
Really? It is too heavy to support fully the specification.
But I yet want to know which design guideline is preferable, 'A local class must be contained in the #getNestedClasses() of the directly enclosing method' or 'contained in the one of indirectly enclosing "Type"'?
Is it preferable that "directly enclosing method" design?
That's happy for me that a local class is removed from #getNestedClasses() of 'indirectly enclosing "Type"' because I can avoid the bug of "The getQualifiedName() for local class" in my application if local classes are removed from 'JavaType#getNestedClasses()'.
was (Author: kuzukami):
Really? It is too heavy to support fully the specification.
But I yet want to whether 'A local class must not be contained in the JavaType#getNestedClasses()' of indirectly enclosing "Type" instead of the directly enclosing method or not,
because I can avoid the bug of "The getQualifiedName() for local class" in my application if local classes are removed from 'JavaType#getNestedClasses()'.
Now it is true that A local class is contained in the JavaType#getNestedClasses() of indirectly enclosing "Type".
> Which one encloses a local class.
> ---------------------------------
>
> Key: ROASTER-76
> URL: https://issues.jboss.org/browse/ROASTER-76
> Project: Roaster
> Issue Type: Quality Risk
> Components: API, JDT
> Affects Versions: 2.14.0.Final
> Reporter: Shoji Kuzukami
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (ROASTER-76) Which one encloses a local class.
by Shoji Kuzukami (JIRA)
[ https://issues.jboss.org/browse/ROASTER-76?page=com.atlassian.jira.plugin... ]
Shoji Kuzukami edited comment on ROASTER-76 at 7/10/15 3:13 AM:
----------------------------------------------------------------
Really? It is too heavy to support fully the specification.
But I yet want to whether 'A local class must not be contained in the JavaType#getNestedClasses()' of indirectly enclosing "Type" instead of the directly enclosing method or not,
because I can avoid the bug of "The getQualifiedName() for local class" in my application if local classes are removed from 'JavaType#getNestedClasses()'.
Now it is true that A local class is contained in the JavaType#getNestedClasses() of indirectly enclosing "Type".
was (Author: kuzukami):
Really? It is too heavy to support fully the specification.
But I yet want to whether 'A local class must not be contained in the JavaType#getNestedClasses()' of indirectly enclosing "Type" or not,
because I can avoid the bug of "The getQualifiedName() for local class" in my application if local classes are removed from 'JavaType#getNestedClasses()'.
Now it is true that A local class is contained in the JavaType#getNestedClasses() of indirectly enclosing "Type".
> Which one encloses a local class.
> ---------------------------------
>
> Key: ROASTER-76
> URL: https://issues.jboss.org/browse/ROASTER-76
> Project: Roaster
> Issue Type: Quality Risk
> Components: API, JDT
> Affects Versions: 2.14.0.Final
> Reporter: Shoji Kuzukami
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months