July 2015 - forge-issues - Jboss List Archives

[JBoss JIRA] (ROASTER-74) It's better for precise operation that the source code writer retains original spaces

by Shoji Kuzukami (JIRA)

Shoji Kuzukami created ROASTER-74: ------------------------------------- Summary: It's better for precise operation that the source code writer retains original spaces Key: ROASTER-74 URL: https://issues.jboss.org/browse/ROASTER-74 Project: Roaster Issue Type: Enhancement Components: JDT Affects Versions: 2.x Future Environment: Win 8.1 Pro 64bit, Eclipse Mars 64bit, Java 8 Reporter: Shoji Kuzukami I want to verify a source code modified by the 'roast' by using a diff based utility because the modification can unexpectedly break the semantics of original source code by any bugs of the library. But the code writer #toString() in roaster writes a 'formatted' source code removing some white spaces in the original. So the diff utility cannot be simply applied. It's better that the source code writer emits such a code that the original code is minimally operated as well as it can, because the roaster formatter can be used independently by calling Formatter.format(String). Although this is a design-concept issue of this project, it's happy for me that the pull-request following is accepted. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-66) JavaClass - hasSuper(Class) and getSuper(Class)

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/ROASTER-66?page=com.atlassian.jira.plugin... ] George Gastaldi updated ROASTER-66: ----------------------------------- Affects Version/s: 2.14.0.Final > JavaClass - hasSuper(Class) and getSuper(Class) > ----------------------------------------------- > > Key: ROASTER-66 > URL: https://issues.jboss.org/browse/ROASTER-66 > Project: Roaster > Issue Type: Enhancement > Affects Versions: 2.14.0.Final > Reporter: Claus Ibsen > Fix For: 2.x Future > > > I want to know from a JavaClass which super class and its parents extend. So I can check if it extends a given class. > Today the only way is to use getSuperType which returns a String with the FQN. Then I manually need to look into that class and its parent and so on. > I want a one stop method to do that for me. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-57) Method parameter should allow manipulation of 'final' modifier

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/ROASTER-57?page=com.atlassian.jira.plugin... ] George Gastaldi closed ROASTER-57. ---------------------------------- Assignee: George Gastaldi Fix Version/s: 2.14.1.Final Resolution: Done > Method parameter should allow manipulation of 'final' modifier > -------------------------------------------------------------- > > Key: ROASTER-57 > URL: https://issues.jboss.org/browse/ROASTER-57 > Project: Roaster > Issue Type: Enhancement > Affects Versions: 2.11.1.Final > Reporter: Nicolas Challut > Assignee: George Gastaldi > Fix For: 2.14.1.Final > > > Currently, it's impossible to set final a method parameter but generally a mutator have final parameter -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-72) Adds a new API to parse the multiple declarations of type in a file.

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/ROASTER-72?page=com.atlassian.jira.plugin... ] George Gastaldi updated ROASTER-72: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/forge/roaster/pull/34 > Adds a new API to parse the multiple declarations of type in a file. > -------------------------------------------------------------------- > > Key: ROASTER-72 > URL: https://issues.jboss.org/browse/ROASTER-72 > Project: Roaster > Issue Type: Feature Request > Components: API, JDT, Tests > Affects Versions: 2.14.0.Final > Environment: Java 8, Windows 8.1 64 bit, Eclipse mars 64bit > Reporter: Shoji Kuzukami > Fix For: 2.x Future > > > Although the java language permits multiple type declarations of top level in a java file, the 'roaster' cannot support this function in the API level. Therefore, I tentatively hack and create an API for the support of multiple declarations. > Please refine and refactor the API until the next release because I cannot devote more efforts on this. The new API is initially marked as @Deprecated for such reasons. > --comments-- > Adds a new API and data structure to parse the multiple declarations of > classes in a java file. > An instance of the 'JavaSourceUnit' represents a java source file which > contains multiple declarations of type. > An API named Roaster.parse2(String encoding, InputStream data) is > tentatively created to extract the JavaSourceUnit result. > Some tests for the new function are created at > 'JavaClassMultiDeclsInAFile.java'. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-72) Adds a new API to parse the multiple declarations of type in a file.

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/ROASTER-72?page=com.atlassian.jira.plugin... ] George Gastaldi updated ROASTER-72: ----------------------------------- Fix Version/s: 2.x Future > Adds a new API to parse the multiple declarations of type in a file. > -------------------------------------------------------------------- > > Key: ROASTER-72 > URL: https://issues.jboss.org/browse/ROASTER-72 > Project: Roaster > Issue Type: Feature Request > Components: API, JDT, Tests > Affects Versions: 2.14.0.Final > Environment: Java 8, Windows 8.1 64 bit, Eclipse mars 64bit > Reporter: Shoji Kuzukami > Fix For: 2.x Future > > > Although the java language permits multiple type declarations of top level in a java file, the 'roaster' cannot support this function in the API level. Therefore, I tentatively hack and create an API for the support of multiple declarations. > Please refine and refactor the API until the next release because I cannot devote more efforts on this. The new API is initially marked as @Deprecated for such reasons. > --comments-- > Adds a new API and data structure to parse the multiple declarations of > classes in a java file. > An instance of the 'JavaSourceUnit' represents a java source file which > contains multiple declarations of type. > An API named Roaster.parse2(String encoding, InputStream data) is > tentatively created to extract the JavaSourceUnit result. > Some tests for the new function are created at > 'JavaClassMultiDeclsInAFile.java'. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-73) AbstractJavaSource#getQualifiedName(), #getCanonicalName() seems broken and loops infinitely in the worst case.

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/ROASTER-73?page=com.atlassian.jira.plugin... ] George Gastaldi closed ROASTER-73. ---------------------------------- Assignee: Shoji Kuzukami Resolution: Done > AbstractJavaSource#getQualifiedName(), #getCanonicalName() seems broken and loops infinitely in the worst case. > --------------------------------------------------------------------------------------------------------------- > > Key: ROASTER-73 > URL: https://issues.jboss.org/browse/ROASTER-73 > Project: Roaster > Issue Type: Bug > Components: JDT > Affects Versions: 2.14.0.Final > Environment: Win 8.1 Pro 64bit, Java 8 64bit , Eclipse 64bit > Reporter: Shoji Kuzukami > Assignee: Shoji Kuzukami > Priority: Critical > Fix For: 2.14.1.Final > > > There are apparent bugs in the AbstractJavaSource#getQualifiedName(), #getCanonicalName(). The bug appears #getQualifiedName() for a twice nested inner class. In my worst case, the call of method loops inifinitely. I'll make a patch for this bug and append test cases in the following pull request of this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-73) AbstractJavaSource#getQualifiedName(), #getCanonicalName() seems broken and loops infinitely in the worst case.

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/ROASTER-73?page=com.atlassian.jira.plugin... ] George Gastaldi updated ROASTER-73: ----------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/forge/roaster/pull/35 > AbstractJavaSource#getQualifiedName(), #getCanonicalName() seems broken and loops infinitely in the worst case. > --------------------------------------------------------------------------------------------------------------- > > Key: ROASTER-73 > URL: https://issues.jboss.org/browse/ROASTER-73 > Project: Roaster > Issue Type: Bug > Components: JDT > Affects Versions: 2.14.0.Final > Environment: Win 8.1 Pro 64bit, Java 8 64bit , Eclipse 64bit > Reporter: Shoji Kuzukami > Priority: Critical > Fix For: 2.14.1.Final > > > There are apparent bugs in the AbstractJavaSource#getQualifiedName(), #getCanonicalName(). The bug appears #getQualifiedName() for a twice nested inner class. In my worst case, the call of method loops inifinitely. I'll make a patch for this bug and append test cases in the following pull request of this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-73) AbstractJavaSource#getQualifiedName(), #getCanonicalName() seems broken and loops infinitely in the worst case.

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/ROASTER-73?page=com.atlassian.jira.plugin... ] George Gastaldi updated ROASTER-73: ----------------------------------- Fix Version/s: 2.14.1.Final > AbstractJavaSource#getQualifiedName(), #getCanonicalName() seems broken and loops infinitely in the worst case. > --------------------------------------------------------------------------------------------------------------- > > Key: ROASTER-73 > URL: https://issues.jboss.org/browse/ROASTER-73 > Project: Roaster > Issue Type: Bug > Components: JDT > Affects Versions: 2.14.0.Final > Environment: Win 8.1 Pro 64bit, Java 8 64bit , Eclipse 64bit > Reporter: Shoji Kuzukami > Priority: Critical > Fix For: 2.14.1.Final > > > There are apparent bugs in the AbstractJavaSource#getQualifiedName(), #getCanonicalName(). The bug appears #getQualifiedName() for a twice nested inner class. In my worst case, the call of method loops inifinitely. I'll make a patch for this bug and append test cases in the following pull request of this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-73) AbstractJavaSource#getQualifiedName(), #getCanonicalName() seems broken and loops infinitely in the worst case.

by Anonymous (JIRA)

[ https://issues.jboss.org/browse/ROASTER-73?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when kuzukami created pull request #35 in GitHub ------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > AbstractJavaSource#getQualifiedName(), #getCanonicalName() seems broken and loops infinitely in the worst case. > --------------------------------------------------------------------------------------------------------------- > > Key: ROASTER-73 > URL: https://issues.jboss.org/browse/ROASTER-73 > Project: Roaster > Issue Type: Bug > Components: JDT > Affects Versions: 2.14.0.Final > Environment: Win 8.1 Pro 64bit, Java 8 64bit , Eclipse 64bit > Reporter: Shoji Kuzukami > Priority: Critical > > There are apparent bugs in the AbstractJavaSource#getQualifiedName(), #getCanonicalName(). The bug appears #getQualifiedName() for a twice nested inner class. In my worst case, the call of method loops inifinitely. I'll make a patch for this bug and append test cases in the following pull request of this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-73) AbstractJavaSource#getQualifiedName(), #getCanonicalName() seems broken and loops infinitely in the worst case.

by Shoji Kuzukami (JIRA)

Shoji Kuzukami created ROASTER-73: ------------------------------------- Summary: AbstractJavaSource#getQualifiedName(), #getCanonicalName() seems broken and loops infinitely in the worst case. Key: ROASTER-73 URL: https://issues.jboss.org/browse/ROASTER-73 Project: Roaster Issue Type: Bug Components: JDT Affects Versions: 2.14.0.Final Environment: Win 8.1 Pro 64bit, Java 8 64bit , Eclipse 64bit Reporter: Shoji Kuzukami Priority: Critical There are apparent bugs in the AbstractJavaSource#getQualifiedName(), #getCanonicalName(). The bug appears #getQualifiedName() for a twice nested inner class. In my worst case, the call of method loops inifinitely. I'll make a patch for this bug and append test cases in the following pull request of this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues July 2015