Use of import

[GraxCode]

Instead of using fully qualified names, you should use imports to make the code more readable. only use full names if an import with the same (short!) name already exists.

[Storyyeller]

That would make classes in the default package ambiguous, but I suppose that's already true due to the java.lang pruning that already exists. It would require doing an extra pass over the class before writing out the source code, but that could be done.

[samczsun]

If this is being added, I would request adding it as optional behavior. Personally, I much prefer FQNs because there's no ambiguity and it's easier to add in newlines than it is to jump back and forth between imports.

For example, if there are 5 packages [a-e], and each has a class a, technically there is no ambiguity if the code just calls a.someStaticMethod(), but you would need to check the imports to see which a is being referenced

[GraxCode]

Thats why duplicate short class names should be referenced as FQNs (and only one "a" class should be imported) as i described before, fernflower for example uses the same behaviour.

[Storyyeller]

Yeah, I would use FQNs whenever there are multiple identifiers with the same short name to avoid confusion. The real question is how to handle java.lang classes and classes in the default package. There's also the separate question of class members shadowing classes, but I don't think there's any way to reliably avoid ambiguity in those cases.

[Storyyeller]

By the way, as long as you're here, do you have any opinions on new assembler syntax for the Java 9 Module attribute?

[samczsun]

If you want to make this an optional feature, then I have no objections. However, if you plan to make it the only style of output, then consider this example:

The example

Given the following classes in the JAR:

a/a/a
a/a/b
a/b/a
a/c/a
a/d/a

and this code

public class Test {
  public int doMath() {
    return a.a.a.addition(5, 6);
  }
}

It's immediately obvious which package's a is being referenced. In larger files, I don't want to have to memorize which package holds which single letter class, when I could just read the FQN.

Re: Module attribute, I haven't looked at it too closely yet, so any opinions I have right now won't be very well thought out

[GraxCode]

If there is, for example, a class called "Integer" in the default package, you could use FQNs on the java.lang.Integer class. You can't handle that case in a good way. Maybe force FQNs if this happens

I would also recommend to add an option to turn off imports.

[asmblur]

I'm all for FQN with the option of disabling them. If there's one thing I hate more than verbosity it's obscurity.