[JBoss JIRA] (ROASTER-129) Improve the javadoc of addImport
by George Gastaldi (Jira)
[ https://issues.jboss.org/browse/ROASTER-129?page=com.atlassian.jira.plugi... ]
George Gastaldi reassigned ROASTER-129:
---------------------------------------
Assignee: George Gastaldi
> Improve the javadoc of addImport
> --------------------------------
>
> Key: ROASTER-129
> URL: https://issues.jboss.org/browse/ROASTER-129
> Project: Roaster
> Issue Type: Enhancement
> Affects Versions: 2.20.5.Final
> Environment: Windows 10, Java 8
> Reporter: Kai Müller
> Assignee: George Gastaldi
> Priority: Optional
>
> Hello all,
> I want to provide an idea for an enhancement of the javadoc of "Importer.Import addImport(Type<?> type)".
> Currently the javadoc says: "The method returns the name that can be used inside the code to reference the type".
> Please corret me if I'm wrong, but the returned Import object has two methods (simple name and qualified name), but the result of them are dynamical generated. That means, regardless if an import happened or not, both methods each returning in both cases the same result.
> So, I want to ask you, about your opinion to change either the code (complex) or the javadoc (simple). In the case of the second here is an idea: "The method returns a import object which can be used for further working with the type. Please note, that in the case the import was skipped because of duplicate import the result of the call is the same, as the import woudn't be skipped".
> Sample code:
> public static void main(final String[] args) {
> final JavaClassSource javaClassSource = Roaster.create(JavaClassSource.class);
> final Import imprtOne = javaClassSource.addImport("packageOne.ClassOne");
> final Import imprtTwo = javaClassSource.addImport("packageOne.ClassOne");
> System.out.println(imprtOne.getQualifiedName());
> System.out.println(imprtOne.getSimpleName());
> System.out.println(imprtTwo.getQualifiedName());
> System.out.println(imprtTwo.getSimpleName());
> }
> Best regards,
> Kai
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ROASTER-129) Improve the javadoc of addImport
by George Gastaldi (Jira)
[ https://issues.jboss.org/browse/ROASTER-129?page=com.atlassian.jira.plugi... ]
George Gastaldi updated ROASTER-129:
------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/forge/roaster/pull/84
> Improve the javadoc of addImport
> --------------------------------
>
> Key: ROASTER-129
> URL: https://issues.jboss.org/browse/ROASTER-129
> Project: Roaster
> Issue Type: Enhancement
> Affects Versions: 2.20.5.Final
> Environment: Windows 10, Java 8
> Reporter: Kai Müller
> Priority: Optional
>
> Hello all,
> I want to provide an idea for an enhancement of the javadoc of "Importer.Import addImport(Type<?> type)".
> Currently the javadoc says: "The method returns the name that can be used inside the code to reference the type".
> Please corret me if I'm wrong, but the returned Import object has two methods (simple name and qualified name), but the result of them are dynamical generated. That means, regardless if an import happened or not, both methods each returning in both cases the same result.
> So, I want to ask you, about your opinion to change either the code (complex) or the javadoc (simple). In the case of the second here is an idea: "The method returns a import object which can be used for further working with the type. Please note, that in the case the import was skipped because of duplicate import the result of the call is the same, as the import woudn't be skipped".
> Sample code:
> public static void main(final String[] args) {
> final JavaClassSource javaClassSource = Roaster.create(JavaClassSource.class);
> final Import imprtOne = javaClassSource.addImport("packageOne.ClassOne");
> final Import imprtTwo = javaClassSource.addImport("packageOne.ClassOne");
> System.out.println(imprtOne.getQualifiedName());
> System.out.println(imprtOne.getSimpleName());
> System.out.println(imprtTwo.getQualifiedName());
> System.out.println(imprtTwo.getSimpleName());
> }
> Best regards,
> Kai
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ROASTER-129) Improve the javadoc of addImport
by Kai Müller (Jira)
[ https://issues.jboss.org/browse/ROASTER-129?page=com.atlassian.jira.plugi... ]
Kai Müller commented on ROASTER-129:
------------------------------------
Valid point, the positive side of retuning a value is, that it can be directly used to use either the fqn or simple name. In the case of null you need an additional code line...
> Improve the javadoc of addImport
> --------------------------------
>
> Key: ROASTER-129
> URL: https://issues.jboss.org/browse/ROASTER-129
> Project: Roaster
> Issue Type: Enhancement
> Affects Versions: 2.20.5.Final
> Environment: Windows 10, Java 8
> Reporter: Kai Müller
> Priority: Optional
>
> Hello all,
> I want to provide an idea for an enhancement of the javadoc of "Importer.Import addImport(Type<?> type)".
> Currently the javadoc says: "The method returns the name that can be used inside the code to reference the type".
> Please corret me if I'm wrong, but the returned Import object has two methods (simple name and qualified name), but the result of them are dynamical generated. That means, regardless if an import happened or not, both methods each returning in both cases the same result.
> So, I want to ask you, about your opinion to change either the code (complex) or the javadoc (simple). In the case of the second here is an idea: "The method returns a import object which can be used for further working with the type. Please note, that in the case the import was skipped because of duplicate import the result of the call is the same, as the import woudn't be skipped".
> Sample code:
> public static void main(final String[] args) {
> final JavaClassSource javaClassSource = Roaster.create(JavaClassSource.class);
> final Import imprtOne = javaClassSource.addImport("packageOne.ClassOne");
> final Import imprtTwo = javaClassSource.addImport("packageOne.ClassOne");
> System.out.println(imprtOne.getQualifiedName());
> System.out.println(imprtOne.getSimpleName());
> System.out.println(imprtTwo.getQualifiedName());
> System.out.println(imprtTwo.getSimpleName());
> }
> Best regards,
> Kai
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ROASTER-129) Improve the javadoc of addImport
by George Gastaldi (Jira)
[ https://issues.jboss.org/browse/ROASTER-129?page=com.atlassian.jira.plugi... ]
George Gastaldi commented on ROASTER-129:
-----------------------------------------
A valid approach is to return {{null}} when {{addImport}} is called and the import should not happen. Some places already test for that, see https://github.com/forge/roaster/blob/d9a17b8ea9e6cb4f430cdea434875424a04...
> Improve the javadoc of addImport
> --------------------------------
>
> Key: ROASTER-129
> URL: https://issues.jboss.org/browse/ROASTER-129
> Project: Roaster
> Issue Type: Enhancement
> Affects Versions: 2.20.5.Final
> Environment: Windows 10, Java 8
> Reporter: Kai Müller
> Priority: Optional
>
> Hello all,
> I want to provide an idea for an enhancement of the javadoc of "Importer.Import addImport(Type<?> type)".
> Currently the javadoc says: "The method returns the name that can be used inside the code to reference the type".
> Please corret me if I'm wrong, but the returned Import object has two methods (simple name and qualified name), but the result of them are dynamical generated. That means, regardless if an import happened or not, both methods each returning in both cases the same result.
> So, I want to ask you, about your opinion to change either the code (complex) or the javadoc (simple). In the case of the second here is an idea: "The method returns a import object which can be used for further working with the type. Please note, that in the case the import was skipped because of duplicate import the result of the call is the same, as the import woudn't be skipped".
> Sample code:
> public static void main(final String[] args) {
> final JavaClassSource javaClassSource = Roaster.create(JavaClassSource.class);
> final Import imprtOne = javaClassSource.addImport("packageOne.ClassOne");
> final Import imprtTwo = javaClassSource.addImport("packageOne.ClassOne");
> System.out.println(imprtOne.getQualifiedName());
> System.out.println(imprtOne.getSimpleName());
> System.out.println(imprtTwo.getQualifiedName());
> System.out.println(imprtTwo.getSimpleName());
> }
> Best regards,
> Kai
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ROASTER-129) Improve the javadoc of addImport
by George Gastaldi (Jira)
[ https://issues.jboss.org/browse/ROASTER-129?page=com.atlassian.jira.plugi... ]
George Gastaldi commented on ROASTER-129:
-----------------------------------------
Can you elaborate on how do you plan to change the behavior of the returned import object?
> Improve the javadoc of addImport
> --------------------------------
>
> Key: ROASTER-129
> URL: https://issues.jboss.org/browse/ROASTER-129
> Project: Roaster
> Issue Type: Enhancement
> Affects Versions: 2.20.5.Final
> Environment: Windows 10, Java 8
> Reporter: Kai Müller
> Priority: Optional
>
> Hello all,
> I want to provide an idea for an enhancement of the javadoc of "Importer.Import addImport(Type<?> type)".
> Currently the javadoc says: "The method returns the name that can be used inside the code to reference the type".
> Please corret me if I'm wrong, but the returned Import object has two methods (simple name and qualified name), but the result of them are dynamical generated. That means, regardless if an import happened or not, both methods each returning in both cases the same result.
> So, I want to ask you, about your opinion to change either the code (complex) or the javadoc (simple). In the case of the second here is an idea: "The method returns a import object which can be used for further working with the type. Please note, that in the case the import was skipped because of duplicate import the result of the call is the same, as the import woudn't be skipped".
> Sample code:
> public static void main(final String[] args) {
> final JavaClassSource javaClassSource = Roaster.create(JavaClassSource.class);
> final Import imprtOne = javaClassSource.addImport("packageOne.ClassOne");
> final Import imprtTwo = javaClassSource.addImport("packageOne.ClassOne");
> System.out.println(imprtOne.getQualifiedName());
> System.out.println(imprtOne.getSimpleName());
> System.out.println(imprtTwo.getQualifiedName());
> System.out.println(imprtTwo.getSimpleName());
> }
> Best regards,
> Kai
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ROASTER-128) Roaster doesn't check for invalid imports
by Kai Müller (Jira)
[ https://issues.jboss.org/browse/ROASTER-128?page=com.atlassian.jira.plugi... ]
Kai Müller commented on ROASTER-128:
------------------------------------
Hi,
I opened ROASTER-129 for this. It maybe has something to do with ROASTER-10.
However, the following code now failed unexpected:
{code:java}
public static void main(final String[] args) {
final JavaClassSource javaClassSource = Roaster.create(JavaClassSource.class);
final Import imprtOne = javaClassSource.addImport("packageOne.ClassOne");
final Import imprtTwo = javaClassSource.addImport("packageTwo.ClassOne");
System.out.println(imprtOne.getQualifiedName());
System.out.println(imprtOne.getSimpleName());
System.out.println(imprtTwo.getQualifiedName());
System.out.println(imprtTwo.getSimpleName());
}
{code}
Exception in thread "main" java.lang.IllegalArgumentException: Attempted to import the illegal type [packageTwo.ClassOne]
at org.jboss.forge.roaster.model.impl.AbstractJavaSource.addImport(AbstractJavaSource.java:195)
at Test.main(Test.java:20)
Can you please check. AFAIK, it has somethig to do that instead of addImport(Type<T>), addImport(String) is used.
Thanks,
Kai
> Roaster doesn't check for invalid imports
> -----------------------------------------
>
> Key: ROASTER-128
> URL: https://issues.jboss.org/browse/ROASTER-128
> Project: Roaster
> Issue Type: Bug
> Components: JDT
> Affects Versions: 2.20.0.Final
> Environment: Windows 10, Java 8
> Reporter: Kai Müller
> Assignee: Kai Müller
> Priority: Major
> Fix For: 2.20.5.Final
>
>
> Hi guys,
> while working with your library I ran into the following problem. The method setType adds an import if possible and needed. But it doesn't check, if e.g. the class to import is equal to the current class or if another import with the same class name but other package exists.
> The provided example leads to the following result:
> package testPackage;
> import package1.Type;
> import package2.Type;
> public class Main {
> Type field1;
> Type field2;
> }
> This class will not compile and there is no workaround, because there is no way to tell this method NOT to add an import.
> In addition, I want to ask you, if you can check the following javadoc of "Importer.Import addImport(Type<?> type)". In this doc it's mentioned that "The method returns the name that can be used inside the code to reference the type". But the returned "Import" object has no such method. I's need to be done via the "resolveType" of the "Importer" object. I would expect, that either the javadoc should be changed or the "Import" get's an additional method.
> Thank you very much,
> Kai
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ROASTER-10) Auto generated imports when a field type is set causes .java file to not compile.
by Kai Müller (Jira)
[ https://issues.jboss.org/browse/ROASTER-10?page=com.atlassian.jira.plugin... ]
Kai Müller edited comment on ROASTER-10 at 1/16/19 2:51 PM:
------------------------------------------------------------
Hi, with 2.20.5 my code compiles but is WRONG:
{code:java}
public static void main(final String[] args) {
final JavaClassSource javaClass = Roaster.create(JavaClassSource.class);
javaClass.setPackage("testPackage").setName("Main");
// Field one
javaClass.addField().setName("field1").setType("package1.Type");
// Field two
javaClass.addField().setName("field2").setType("package2.Type");
// out
System.out.println(javaClass.toString());
}
{code}
The code which is produced is:
{code:java}
package testPackage;
import package1.Type;
public class Main {
Type field1;
Type field2;
}
{code}
BR,
Kai
was (Author: kaijmueller):
Hi, we 2.20.5 my code compiles but is WRONG:
{code:java}
public static void main(final String[] args) {
final JavaClassSource javaClass = Roaster.create(JavaClassSource.class);
javaClass.setPackage("testPackage").setName("Main");
// Field one
javaClass.addField().setName("field1").setType("package1.Type");
// Field two
javaClass.addField().setName("field2").setType("package2.Type");
// out
System.out.println(javaClass.toString());
}
{code}
The code which is produced is:
{code:java}
package testPackage;
import package1.Type;
public class Main {
Type field1;
Type field2;
}
{code}
BR,
Kai
> 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
> Priority: Major
> 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.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ROASTER-10) Auto generated imports when a field type is set causes .java file to not compile.
by Kai Müller (Jira)
[ https://issues.jboss.org/browse/ROASTER-10?page=com.atlassian.jira.plugin... ]
Kai Müller commented on ROASTER-10:
-----------------------------------
Hi, we 2.20.5 my code compiles but is WRONG:
{code:java}
public static void main(final String[] args) {
final JavaClassSource javaClass = Roaster.create(JavaClassSource.class);
javaClass.setPackage("testPackage").setName("Main");
// Field one
javaClass.addField().setName("field1").setType("package1.Type");
// Field two
javaClass.addField().setName("field2").setType("package2.Type");
// out
System.out.println(javaClass.toString());
}
{code}
The code which is produced is:
{code:java}
package testPackage;
import package1.Type;
public class Main {
Type field1;
Type field2;
}
{code}
BR,
Kai
> 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
> Priority: Major
> 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.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ROASTER-129) Improve the javadoc of addImport
by Kai Müller (Jira)
Kai Müller created ROASTER-129:
----------------------------------
Summary: Improve the javadoc of addImport
Key: ROASTER-129
URL: https://issues.jboss.org/browse/ROASTER-129
Project: Roaster
Issue Type: Enhancement
Affects Versions: 2.20.5.Final
Environment: Windows 10, Java 8
Reporter: Kai Müller
Hello all,
I want to provide an idea for an enhancement of the javadoc of "Importer.Import addImport(Type<?> type)".
Currently the javadoc says: "The method returns the name that can be used inside the code to reference the type".
Please corret me if I'm wrong, but the returned Import object has two methods (simple name and qualified name), but the result of them are dynamical generated. That means, regardless if an import happened or not, both methods each returning in both cases the same result.
So, I want to ask you, about your opinion to change either the code (complex) or the javadoc (simple). In the case of the second here is an idea: "The method returns a import object which can be used for further working with the type. Please note, that in the case the import was skipped because of duplicate import the result of the call is the same, as the import woudn't be skipped".
Sample code:
public static void main(final String[] args) {
final JavaClassSource javaClassSource = Roaster.create(JavaClassSource.class);
final Import imprtOne = javaClassSource.addImport("packageOne.ClassOne");
final Import imprtTwo = javaClassSource.addImport("packageOne.ClassOne");
System.out.println(imprtOne.getQualifiedName());
System.out.println(imprtOne.getSimpleName());
System.out.println(imprtTwo.getQualifiedName());
System.out.println(imprtTwo.getSimpleName());
}
Best regards,
Kai
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ROASTER-129) Improve the javadoc of addImport
by Kai Müller (Jira)
[ https://issues.jboss.org/browse/ROASTER-129?page=com.atlassian.jira.plugi... ]
Kai Müller commented on ROASTER-129:
------------------------------------
I just read ROASTER-10 and maybe by changing the behaviour of the returned import project, this issue could easily be resolved.
What do you think?
> Improve the javadoc of addImport
> --------------------------------
>
> Key: ROASTER-129
> URL: https://issues.jboss.org/browse/ROASTER-129
> Project: Roaster
> Issue Type: Enhancement
> Affects Versions: 2.20.5.Final
> Environment: Windows 10, Java 8
> Reporter: Kai Müller
> Priority: Optional
>
> Hello all,
> I want to provide an idea for an enhancement of the javadoc of "Importer.Import addImport(Type<?> type)".
> Currently the javadoc says: "The method returns the name that can be used inside the code to reference the type".
> Please corret me if I'm wrong, but the returned Import object has two methods (simple name and qualified name), but the result of them are dynamical generated. That means, regardless if an import happened or not, both methods each returning in both cases the same result.
> So, I want to ask you, about your opinion to change either the code (complex) or the javadoc (simple). In the case of the second here is an idea: "The method returns a import object which can be used for further working with the type. Please note, that in the case the import was skipped because of duplicate import the result of the call is the same, as the import woudn't be skipped".
> Sample code:
> public static void main(final String[] args) {
> final JavaClassSource javaClassSource = Roaster.create(JavaClassSource.class);
> final Import imprtOne = javaClassSource.addImport("packageOne.ClassOne");
> final Import imprtTwo = javaClassSource.addImport("packageOne.ClassOne");
> System.out.println(imprtOne.getQualifiedName());
> System.out.println(imprtOne.getSimpleName());
> System.out.println(imprtTwo.getQualifiedName());
> System.out.println(imprtTwo.getSimpleName());
> }
> Best regards,
> Kai
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months