July 2015 - forge-issues - Jboss List Archives

[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 1:24 AM: ---------------------------------------------------------------- I want to know the project design for enclosure of a local class (JSL 14.3. Local Class Declarations). Now a local class is enclosed by a 'Type' element indirectly enclosing instead of a method body directly enclosing. That is a good design but it's not clarified. Please declare the specification. The getQualifiedName() for local class seems broken. They must be named such as 'OuterClass$1LocalClass' or 'OuterClass$2LocalClass', though now they are named as 'OuterClass$LocalClass'. I've had some experimental code and refactors for that bug. But I cannot make a pull request if the project design for a local class is not fixed, was (Author: kuzukami): I want to know the project design for enclosure of a local class (JSL 14.3. Local Class Declarations). Now a local class is enclosed by a 'Type' element enclosing instead of the method body. That is a good design but it's not clarified. Please declare the specification. The getQualifiedName() for local class seems broken. They must be named such as 'OuterClass$1LocalClass' or 'OuterClass$2LocalClass', though now they are named as 'OuterClass$LocalClass'. I've had some experimental code and refactors for that bug. But I cannot make a pull request if the project design for a local class is not fixed, > 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

1
0
0 / 0

[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: --------------------------------------- I want to know the project design for enclosure of a local class (JSL 14.3. Local Class Declarations). Now a local class is enclosed by a 'Type' element enclosing instead of the method body. That is a good design but it's not clarified. Please declare the specification. The getQualifiedName() for local class seems broken. They must be named such as 'OuterClass$1LocalClass' or 'OuterClass$2LocalClass', though now they are named as 'OuterClass$LocalClass'. I've had some experimental code and refactors for that bug. But I cannot make a pull request if the project design for a local class is not fixed, > 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

1
0
0 / 0

[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 updated ROASTER-76: ---------------------------------- Summary: Which one encloses a local class. (was: Which one encloses the local class.) > 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

1
0
0 / 0

[JBoss JIRA] (ROASTER-76) Which one encloses the local class.

by Shoji Kuzukami (JIRA)

[ https://issues.jboss.org/browse/ROASTER-76?page=com.atlassian.jira.plugin... ] Shoji Kuzukami updated ROASTER-76: ---------------------------------- Component/s: API JDT > Which one encloses the 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

1
0
0 / 0

[JBoss JIRA] (ROASTER-76) Which one encloses the local class.

by Shoji Kuzukami (JIRA)

Shoji Kuzukami created ROASTER-76: ------------------------------------- Summary: Which one encloses the local class. Key: ROASTER-76 URL: https://issues.jboss.org/browse/ROASTER-76 Project: Roaster Issue Type: Quality Risk Reporter: Shoji Kuzukami -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-76) Which one encloses the local class.

by Shoji Kuzukami (JIRA)

[ https://issues.jboss.org/browse/ROASTER-76?page=com.atlassian.jira.plugin... ] Shoji Kuzukami updated ROASTER-76: ---------------------------------- Affects Version/s: 2.14.0.Final > Which one encloses the local class. > ----------------------------------- > > Key: ROASTER-76 > URL: https://issues.jboss.org/browse/ROASTER-76 > Project: Roaster > Issue Type: Quality Risk > Affects Versions: 2.14.0.Final > Reporter: Shoji Kuzukami > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-75) Encoding of source[?] code cannot be easily configured.

by Shoji Kuzukami (JIRA)

[ https://issues.jboss.org/browse/ROASTER-75?page=com.atlassian.jira.plugin... ] Shoji Kuzukami commented on ROASTER-75: --------------------------------------- I have many source codes with comments and identifiers written by the Japanese. It cannot be converted in the 'ISO8859-1' bytes. I'm using the UTF-8 encoding and bytes in the Java source code. > Encoding of source[?] code cannot be easily configured. > ------------------------------------------------------- > > Key: ROASTER-75 > URL: https://issues.jboss.org/browse/ROASTER-75 > Project: Roaster > Issue Type: Enhancement > Components: API, JDT > Affects Versions: 2.14.0.Final, 2.15.0.Final > Environment: Java 8 64bit, Eclipse Mars, Windows 8.1 Pro 64bit > Reporter: Shoji Kuzukami > Priority: Minor > Fix For: 2.x Future > > > The parser encoding for souce code can only be configured by the 'file.encoding' system parameter, as we can see in JavaParserImpl, "String encoding = System.getProperty("file.encoding", "ISO8859_1");". > Even though the Roaster API can receive a 'String' source as "public static JavaType<?> parse(final String data)" in the 'Roaster.java', the 'String' of source can only contain "ISO8859_1" charsets if we don't change the "file.encoding". > The parser SPI in 'JavaParser.java' is defined as "JavaUnit parseUnit(final InputStream data);" instead of "JavaUnit parseUnit(Reader source);". I think it is adequate considering that the Roaster API will accept some binary sources (such as bytecode) in near future. > I recommend that the SPI "JavaUnit parseUnit(final InputStream data);" is expanded into "JavaUnit parseUnit(final InputStream data, Charset encodingIfText );" and some encoding refactors are done in the 'Roaster.java' without any change of semantics in the Roaster APIs except for the 'String' souce APIs as "public static JavaType<?> parse(final String data)". > The 'Charset' argument is used only if the 'data' of InputStream must be interpreted as 'String' ( as a case of source code ). > If this idea is accepted by this project design, I'll refactor the code and do a pull-requeust. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-75) Encoding of source[?] code cannot be easily configured.

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/ROASTER-75?page=com.atlassian.jira.plugin... ] George Gastaldi updated ROASTER-75: ----------------------------------- Fix Version/s: 2.x Future > Encoding of source[?] code cannot be easily configured. > ------------------------------------------------------- > > Key: ROASTER-75 > URL: https://issues.jboss.org/browse/ROASTER-75 > Project: Roaster > Issue Type: Enhancement > Components: API, JDT > Affects Versions: 2.14.0.Final, 2.15.0.Final > Environment: Java 8 64bit, Eclipse Mars, Windows 8.1 Pro 64bit > Reporter: Shoji Kuzukami > Priority: Minor > Fix For: 2.x Future > > > The parser encoding for souce code can only be configured by the 'file.encoding' system parameter, as we can see in JavaParserImpl, "String encoding = System.getProperty("file.encoding", "ISO8859_1");". > Even though the Roaster API can receive a 'String' source as "public static JavaType<?> parse(final String data)" in the 'Roaster.java', the 'String' of source can only contain "ISO8859_1" charsets if we don't change the "file.encoding". > The parser SPI in 'JavaParser.java' is defined as "JavaUnit parseUnit(final InputStream data);" instead of "JavaUnit parseUnit(Reader source);". I think it is adequate considering that the Roaster API will accept some binary sources (such as bytecode) in near future. > I recommend that the SPI "JavaUnit parseUnit(final InputStream data);" is expanded into "JavaUnit parseUnit(final InputStream data, Charset encodingIfText );" and some encoding refactors are done in the 'Roaster.java' without any change of semantics in the Roaster APIs except for the 'String' souce APIs as "public static JavaType<?> parse(final String data)". > The 'Charset' argument is used only if the 'data' of InputStream must be interpreted as 'String' ( as a case of source code ). > If this idea is accepted by this project design, I'll refactor the code and do a pull-requeust. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-75) Encoding of source[?] code cannot be easily configured.

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/ROASTER-75?page=com.atlassian.jira.plugin... ] George Gastaldi commented on ROASTER-75: ---------------------------------------- Isn't it possible to convert to ISO8859-1 using the String signature? > Encoding of source[?] code cannot be easily configured. > ------------------------------------------------------- > > Key: ROASTER-75 > URL: https://issues.jboss.org/browse/ROASTER-75 > Project: Roaster > Issue Type: Enhancement > Components: API, JDT > Affects Versions: 2.14.0.Final, 2.15.0.Final > Environment: Java 8 64bit, Eclipse Mars, Windows 8.1 Pro 64bit > Reporter: Shoji Kuzukami > Priority: Minor > > The parser encoding for souce code can only be configured by the 'file.encoding' system parameter, as we can see in JavaParserImpl, "String encoding = System.getProperty("file.encoding", "ISO8859_1");". > Even though the Roaster API can receive a 'String' source as "public static JavaType<?> parse(final String data)" in the 'Roaster.java', the 'String' of source can only contain "ISO8859_1" charsets if we don't change the "file.encoding". > The parser SPI in 'JavaParser.java' is defined as "JavaUnit parseUnit(final InputStream data);" instead of "JavaUnit parseUnit(Reader source);". I think it is adequate considering that the Roaster API will accept some binary sources (such as bytecode) in near future. > I recommend that the SPI "JavaUnit parseUnit(final InputStream data);" is expanded into "JavaUnit parseUnit(final InputStream data, Charset encodingIfText );" and some encoding refactors are done in the 'Roaster.java' without any change of semantics in the Roaster APIs except for the 'String' souce APIs as "public static JavaType<?> parse(final String data)". > The 'Charset' argument is used only if the 'data' of InputStream must be interpreted as 'String' ( as a case of source code ). > If this idea is accepted by this project design, I'll refactor the code and do a pull-requeust. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ROASTER-75) Encoding of source[?] code cannot be easily configured.

by Shoji Kuzukami (JIRA)

[ https://issues.jboss.org/browse/ROASTER-75?page=com.atlassian.jira.plugin... ] Shoji Kuzukami updated ROASTER-75: ---------------------------------- Description: The parser encoding for souce code can only be configured by the 'file.encoding' system parameter, as we can see in JavaParserImpl, "String encoding = System.getProperty("file.encoding", "ISO8859_1");". Even though the Roaster API can receive a 'String' source as "public static JavaType<?> parse(final String data)" in the 'Roaster.java', the 'String' of source can only contain "ISO8859_1" charsets if we don't change the "file.encoding". The parser SPI in 'JavaParser.java' is defined as "JavaUnit parseUnit(final InputStream data);" instead of "JavaUnit parseUnit(Reader source);". I think it is adequate considering that the Roaster API will accept some binary sources (such as bytecode) in near future. I recommend that the SPI "JavaUnit parseUnit(final InputStream data);" is expanded into "JavaUnit parseUnit(final InputStream data, Charset encodingIfText );" and some encoding refactors are done in the 'Roaster.java' without any change of semantics in the Roaster APIs except for the 'String' souce APIs as "public static JavaType<?> parse(final String data)". The 'Charset' argument is used only if the 'data' of InputStream must be interpreted as 'String' ( as a case of source code ). If this idea is accepted by this project design, I'll refactor the code and do a pull-requeust. was: The parser encoding for souce code can only be configured by the 'file.encoding' system parameter, as we can see in JavaParserImpl, "String encoding = System.getProperty("file.encoding", "ISO8859_1");". Even the Roaster API can receive a 'String' source as "public static JavaType<?> parse(final String data)" in the 'Roaster.java', the 'String' of source can only contain "ISO8859_1" charsets if we don't change the "file.encoding". The parser SPI in 'JavaParser.java' is defined as "JavaUnit parseUnit(final InputStream data);" instead of "JavaUnit parseUnit(Reader source);". I think it is adequate considering that the Roaster API will accept some binary sources (such as bytecode) in near future. I recommend that the SPI "JavaUnit parseUnit(final InputStream data);" is expanded into "JavaUnit parseUnit(final InputStream data, Charset encodingIfText );" and some encoding refactors is done in the 'Roaster.java' without any change of semantics in the Roaster APIs except for the 'String' souce APIs as "public static JavaType<?> parse(final String data)". The 'Charset' argument is used only if the 'data' of InputStream must be interpreted as 'String' ( as a case of source code ). If this idea is accepted by this project design, I'll refactor the code and do a pull-requeust. > Encoding of source[?] code cannot be easily configured. > ------------------------------------------------------- > > Key: ROASTER-75 > URL: https://issues.jboss.org/browse/ROASTER-75 > Project: Roaster > Issue Type: Enhancement > Components: API, JDT > Affects Versions: 2.14.0.Final, 2.15.0.Final > Environment: Java 8 64bit, Eclipse Mars, Windows 8.1 Pro 64bit > Reporter: Shoji Kuzukami > Priority: Minor > > The parser encoding for souce code can only be configured by the 'file.encoding' system parameter, as we can see in JavaParserImpl, "String encoding = System.getProperty("file.encoding", "ISO8859_1");". > Even though the Roaster API can receive a 'String' source as "public static JavaType<?> parse(final String data)" in the 'Roaster.java', the 'String' of source can only contain "ISO8859_1" charsets if we don't change the "file.encoding". > The parser SPI in 'JavaParser.java' is defined as "JavaUnit parseUnit(final InputStream data);" instead of "JavaUnit parseUnit(Reader source);". I think it is adequate considering that the Roaster API will accept some binary sources (such as bytecode) in near future. > I recommend that the SPI "JavaUnit parseUnit(final InputStream data);" is expanded into "JavaUnit parseUnit(final InputStream data, Charset encodingIfText );" and some encoding refactors are done in the 'Roaster.java' without any change of semantics in the Roaster APIs except for the 'String' souce APIs as "public static JavaType<?> parse(final String data)". > The 'Charset' argument is used only if the 'data' of InputStream must be interpreted as 'String' ( as a case of source code ). > If this idea is accepted by this project design, I'll refactor the code and do a pull-requeust. -- 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