I was trying to parse java sources that was written by other encoding(Not UTF-8)
but unexpected error occured.

Because CommentsParser.parse() using fixed encoding value(UTF-8) like below.
and JavaParser is using this method.

public CommentsCollection parse(final String source) throws IOException, UnsupportedEncodingException {
        InputStream in = new ByteArrayInputStream(source.getBytes());
        return parse(in,"UTF-8");
}

To do that all the comments should be preserved (see #2 ), at least. Possibly also the layout should be kept as-is.

Any thoughts about that? I would like to take a look at that and I would appreciate suggestions, help, advices, etc.

When running deadode4j version 2.0.0, I stumbled over these classes that probably should be removed:

• japa.parser.Position
• japa.parser.ast.TreeVisitor

They were both introduced in late 2013, but are no longer used.

Also, I'd suggest moving class japa.parser.ASTHelper to the test source, as it is only used in that context. Then one could remove lots of methods which are not used.

Now I'll happily create a patch for this, I just wanted to ask what the policy is regarding downgrade compatibility - as there could be some people out there using those classes. So you might want to deprecate those classes now and remove them with the 2.0.0 release. Please indicate what your intentions are.

We should give the possibility to include or exclude them (as with do for modifiers and throws declarations).

So the user could choose if get something like:

void foo(int a, long b)

or

void foo(int, long)

There are 100+ warning during the JavaDoc generation. javadoc:jar goal

Things like a @param is documented, but no description is provided.

We can come back to that after the 2.0.0 release. I will just fix the errors #80 before that.

As seen here: http://code.google.com/p/javaparser/issues/detail?id=9#c21

This was Júlio's plan with the project.

We did that for comments in issue #3 but it applies everywhere.

I could do that in this way, if you agree:

    public List<Parameter> getParameters() {
        if (null == parameters) {
            parameters = new ArrayList<Parameter>();
        }
        return parameters;
    }

Thoughts?

Similarly to #57 I think it could be useful to have a common interface for all things that have the method getName (there are a few).

So I would estimate that the existing comment related tests made up about 50% of the test capital.

Does anyone else want to have a crack at these?

I'm happy to do it, but don't want to hog all the fun! Although I will be on holiday from next week so will take a little while to get around to.

Right not to check if an element has packageLevelAccess we need to check if it is neither public, private or protected. It could be useful to have a method to do that.

I'm using VariableDeclarator for retrieving field's init value

List<VariableDeclarator> variables = fieldDeclaration.getVariables();
for (VariableDeclarator variableDeclarator : variables) {                   
    VariableDeclaratorId fieldName = variableDeclarator.getId();
    Expression fieldValue = variableDeclarator.getInit();
    ...

There is a problem.
See the code below. First Case is No problem.
But In second Case, "variableDeclarator.getInit()" returns "//field2 null"
In other word, "variableDeclarator.getInit()" returns value include line comment

//Case 1
private String field1 = null; //field1

//Case 2
private String field2 
                    = null; //field2

How Can I retrieve or parse only field value without comment?

may line contains "<>" gives an exception ? Parsing can not be done. it gives;
japa.parser.ParseException: Encountered " "<" "< ""

I'm switching my project from 1.0.8 to the latest version (my project indexes Java sources with lucene). I found my indexer is 2x slower and consuming more memory.

I tried to run bisect. and found the bug was introduced in 6f070b8.

Since it is a huge commit (17K lines change), it will take me more time to investigate. Let me know if you have any clue.

I assume a parameter's type being null only occurs for lambda expressions, thus why it didn't pop up until now.

This causes NullPointerExceptions at least for

• com.github.javaparser.ast.visitor.GenericVisitorAdapter
• com.github.javaparser.ast.visitor.ModifierVisitorAdapter
• com.github.javaparser.ast.visitor.VoidVisitorAdapter

The other adapters seem to be unaffected, one of them was explicitly adapted to it. I'd appreciate a double-check of this.

Before introducing a mere if (parameter.getType() != null) everywhere, I wanted to discuss how this should be approached. Does it make sense to introduce a new class representing lambda parameters? Although lambda parameters can have a type too, it seems that it's the only instance a paramater can have no type. Or am I missing something?

Different classes (TypeDeclaration, MethodDeclaration, FieldDeclaration, others?) have a method getModifers, we could declare a common interface, so that certain operation could be performed on all of this classes.

Line 233 of ASTHelperJavadoc comment for

    public static ReferenceType createReferenceType(PrimitiveType type, int arrayCount) {
...
    }

 *            number <b>os</b> arrays or 0 if is not a array.

==>
* number of arrays or 0 if is not a array.

I'm developing a program like grepcode.com (https://github.com/stepinto/polaris). It uses JavaParser. I need position information about class name in a TypeDeclaration i.e. "xxx" in "class xxx {...}". Currently the position of a TypeDeclaration is the whole class body.

I think we can use NameExpr instead of String for its name. For backward compatibility, we need to add another field "NameExpr nameExpr". I can prepare a patch if you think my idea is right.

MethodDeclaration has the same problem.

I try to use javaparser to get the comment from this method but it's always null. It's will be ok if the comment first then annotations.

@GET
@Path("/original")
/**
 * Return the original user.
 */
public User getOriginalUser(String userName) {
    return userService.getOriginalUser(userName);
}

Here is my test class

public class Annot {
  @Test
  public void myTest() {
  }
}

Here is my annotation visitor

public class AnnotationPrinter {

    public static void main(String[] args) throws Exception {
        System.err.println("Parsing " + args[0]);
        FileInputStream in = new FileInputStream(args[0]);
        CompilationUnit cu;
        try {
            cu = JavaParser.parse(in);
        } finally {
            in.close();
        }
        new AnnotationVisitor().visit(cu, null);
    }
    private static class AnnotationVisitor extends VoidVisitorAdapter {
        @Override
        public void visit(AnnotationDeclaration n, Object arg) {
            System.out.println("Annotations:");
            System.out.println(n);
            System.out.println(arg);
            System.out.println(n.getName());
        }
    }
}

Expectation: The annotation Test should have been picked up by the annotation visitor.

Hello,

Is there the library (the current version 1.0.9) deployed on any maven repository?
If not, is there any schedule about it?

Thanks.

Regards
Chema.

Here is example code

public class ClassWithBlockComments {

    /* comment to a method */
    void foo(){};

    /*// comment put randomly in class: <==This is a Problem

    another orphan.
    It spans over more lines */

}

Of course it's not normal coding style.
But Unfortunately this kind of source exist.

Here is where the problem occurred.(CommentParser:line 82)
In that case, the value of "currentContent" is empty.
So "currentContent.toString().length()-1" make StringIndexOutOfBoundException

case IN_BLOCK_COMMENT:
    if (prevChar=='*' && c=='/'){
        // delete last character
        String content = currentContent.deleteCharAt(currentContent.toString().length()-1).toString();
        ...

This allows Java 7 to auto close the resource. This would mean moving to java 7.

(imported from google code comments)

...and also how we would like it to work.

See Node.java, line 225:

@Override public boolean equals(final Object obj) {
    return EqualsVisitor.equals(this, (Node) obj);
}

This is a violation of the expected behavior of Equals, going to fix it and write a test for it.

Example of code causing the exception:

        Node n = new CompilationUnit();
        assertFalse(n.equals("anObjectWhichIsNotANode, it is a String"));

We could generate the Javadoc documentation and provide it as github pages.

I think it is technically possible but it would require maven skills far superior to mine. Volunteers are really welcome :D

There are a lot of comments like:
"//To change body of implemented methods use File | Settings | File Templates."

(see for example AnnotationDeclaration)

I was trying to parse the following class:

public class Test {
    public static @interface SomeAnnotation {
        String value();
    }

    // Parser bug: the type of this field
    @SomeAnnotation("http://someURL.org/")
    protected Test test;
}

getType() on the FieldDeclaration of test returns a ReferenceType with:

//someURL.org/")
Test

It looks like the parser is treating the ':' character as some kind of separator, regardless of being inside a String literal...

(Tested on the latest version 1.0.12-SNAPSHOT as of this writing)

In commit a27c8a8 ASTParser has been changed to don't store comments in memory.

In some cases, as our case (Parse Compilation units, make some changes after a process and replace the original file) this can cause to loose comments (that was one main problem in original library version).

We need some way to configure this behaviour.

Thanks in advance.

Move http://code.google.com/p/javaparser/w/list over to https://github.com/matozoid/javaparser/wiki

I will come up with a pull request for that shortly...

Given we are getting better tests, it could be nice to calculate also code coverage.
I am not familiar with anything for Java.
Do you know something we could use?

No surprise after #82, but I didn't catch it immediately. Will provide a fix.

I propose splitting the project into three modules:

core - Main module with all the libraries code
grammar - Contains grammar and generated sources
acceptance-tests - All the JBehave bases testing

Rational - Not plainly obvious what code is generated and that you have to run javacc:javacc initially from the command line. The IDE can get pissy while referencing src files from the target directory.

Any other suggestions logical divisions, names there of...

Make comment parsing work 100%, and write decent tests for it.

It will be great if you can upload stable jars of this project to be used as libraries. :) Thanks

Maybe we could have continuos integration using travis, to ensure all tests keep passing.

I can take care of that if it is ok for you.

This patch: http://code.google.com/p/javaparser/issues/detail?id=9#c19 left the unit tests broken. They were fixed by always creating an empty list for comments. The rest of the API seems to initialize lists to nulls. This needs to be made consistent again.

It can be useful for different users (for example I am building a Java linter and I could use it).
All sort of reporting and analysis on Java code could take advantage of that method.
What do you think?

These two are left over from the project's life on Google Code.

Suggestions for improvements below:

I failed to parse some Java 8 files with lambda expressions; my stack trace was something like this

java.lang.NullPointerException
    at com.github.javaparser.ast.Node.setAsParentNodeOf(Node.java:331)
    at com.github.javaparser.ast.expr.MethodCallExpr.setArgs(MethodCallExpr.java:96)
    at com.github.javaparser.ast.expr.MethodCallExpr.<init>(MethodCallExpr.java:63)
    at com.github.javaparser.ASTParser.PrimarySuffixWithoutSuper(ASTParser.java:3180)

Obviously, the provided arguments was a list containing a null value. I boiled it down to a simple statement that cannot be parsed:

Stream<CharSequence> stream = Stream.generate((Supplier<CharSequence>) () -> "Fail");

Removing the cast makes the problem go away.

As this is certainly to be fixed within the java_1_8.jj file, I won't come up with a fix (this stuff is just beyond me). I can however set up a branch with a test case or something.

This issue came up from a comment in #50.
I copy the description from there.

The two files "TestCommentsParser" and "TestCommentsParsing" seem just to be two buckets with slightly different names.

Some tests use Hamcrest matchers other don't.

What I assume is legacy test code, that uses main rather than JUnit.

It would be good to get the additional comment support into a release version on maven central.

A chap called before seems to have done this previously. Anyone else offer advice on how to do this?

Nothing like documentation, especially when it is wrong!

Need to tidy up several items that come out of the javadoc:jar goal. Documenting exceptions that aren't thrown etc.

Could execute with <maven.javadoc.failOnError>false</maven.javadoc.failOnError>, but wrong is wrong at the end of the day.

I'll sort today,

Hi guys,
I'm wondering if there are build instructions? Currently I've cloned the repo and imported it to eclipse but there are a few errors and the structure is strange. Are there special steps that need to be taken?

--Chris

A rather horrible sort was found here: #75

Fix it by using built in JDK sorting algorithms, and search around for more of these bubble sorts.

We should write a few lines on how to build the project and how to include it as a dependency.

We should either doing that in the README.md or add a reference there.