#173 Problem in replacing old comments of default abstract method

[Anonymous]

We are on JBuilder 9.0.125.0

The problem here happens to javastyle-jbuilder-2.9.19,
it is that IF you have the following situation:

1. You have an abstract method with the default
access -- only with the “abstract” as the modifier,i.e.:
abstract void foo();

JRefactory would be keen on replacing any of your
existing original comments on top of this kind of method
with its default one, if you dare to press “shift + ctrl +
P”!! This would certainly upset people who made efforts
in commenting their codes but suddenly get JR dismissed
as “Description of the Method”!!

i.e.: if you have:

/**
* My detailed comments
*/
abstract void foo();

After “shift + ctrl + P” you would get:

/**
* Description of the Method
*/
abstract void foo();

However the above problem would go away IF you put
at least “protected” level access to your abstract
method, i.e.: rather than “abstract void foo();”, we put
as:

protected abstract void foo();

Certainly you could put “public” if you’d like, as long as
you don’t leave the method as “headless” to JR, i.e.:
abstract void foo();, then JR would be keen on replacing
your own comments with its default one.

Since there is no difference between the “abstract void
foo();” and “protected abstract void foo();”, it is not a
big deal for us to spend half of a second to put
the “public” or “protected” modifier to your abstract
method.

However, this is certainly not acceptable to users who
are using a product which requires work around.

We hope JR team would solve this problem soon.

[Nobody/Anonymous]

Logged In: NO

There is also a subtle problem:

If you run the JR the 2nd time to reformat the codes (which
already formatted) bellow:

/**
* Description of the Method
*/
abstract void foo();

You would have the annoying "Unable to parse file" error
message.

This is not a user friendly message as JR found there is
nothing to do at the second go, therefore this message
should be internal to JR only and it should not be visible to
the user.

[Nobody/Anonymous]

Logged In: NO

There is actually NO work around for this problem -- the
existing java doc of a default access abstract method would
get wiped out by JR.

Sorry for my previous mistake:

What I said "...Since there is no difference between
the abstract void
foo(); and protected abstract void foo();, it is not a
big deal for us to spend half of a second to put
the public or protected modifier to your abstract
method...." was wrong, there is indeed the difference
between the default access and protected access and
therefore there is NO work around for the user in this specific
case.

We won't have any other way to keep our existing java doc
comments for the default access abstract method after
clicking "shift+ctrl+P", until the JR team corrects it.

[Nobody/Anonymous]

Logged In: NO

There is actually NO work around for this problem -- the
existing java doc of a default access abstract method would
get wiped out by JR.

Sorry for my previous mistake:

What I said "...Since there is no difference between
the abstract void
foo(); and protected abstract void foo();, it is not a
big deal for us to spend half of a second to put
the public or protected modifier to your abstract
method...." was wrong, there is indeed the difference
between the default access and protected access and
therefore there is NO work around for the user in this specific
case.

We won't have any other way to keep our existing java doc
comments for the default access abstract method after
clicking "shift+ctrl+P", until the JR team corrects it.