@Nullable for javadoc?

For those of us still stuck in 1.4 land, is it possible ( or does it
already? ) to add javadoc support to the nullness inspections?

So we could add:

/**

  • @Nullable

*/
public Object something() {
....
}

??

12 comments
Comment actions Permalink

Mark

>

/**

  • @Nullable

*/



It's been requested - by me -, and "won't fix"ed by M.. for performance
reasons.


Alain

0
Comment actions Permalink

Alain Ravet wrote:

It's been requested - by me -, and "won't fix"ed by M.. for performance
reasons.


Thats a pity, I would have thought all those megabytes of indexes might
be able to cover that.

0
Comment actions Permalink

Mark Derricutt wrote:

Alain Ravet wrote:

>> It's been requested - by me -, and "won't fix"ed by M.. for
>> performance reasons.


Thats a pity, I would have thought all those megabytes of indexes might
be able to cover that.


You've probably heard this before but why don't you use RetroWeaver? You
could only use it for annotations, and you wouldn't be risking almost
anything, because RW wouldn't be modifying any executable code, only
class meta-data.

0
Comment actions Permalink

You could only use it for annotations


Just curious, how to tell RW to only support annotations and not, for
example, the for-each-loop or auto(un)boxing? Does it finally enforce you
are not using accidently a 1.5-only class or method?

Tom

0
Comment actions Permalink

Just curious, how to tell RW to only support
annotations and not, for
example, the for-each-loop or auto(un)boxing?


You don't, unfortunately. Many of the new features (ie, the foreach loop) are just compiler syntatic sugar, and won't even make it to the the compiled class. If you decompile a .class file, you can't tell if a regular for loop or a foreach loop was used. The same holds true for static imports, auto(un)boxing and even generics. You can still ask IDEA to warn you about these, thou.

Does it finally enforce you
are not using accidently a 1.5-only class or method?


There's the verifier, and if you check it out the Retroweaver Plugin from the repository, you'll find it has been greatly improved lately. I've made a couple of changes myself, and incorporated a few patches from the retroweaver community to make sure the verifier would be up to IDEA users high demands :)

... the truth is there's one bug with the verifier right now: it's getting confused when verifying an enum class for the first time (on a clean rebuild), and will report bogus errors for them. But that's the only problem right now, as far as I know.

0
Comment actions Permalink

Keith Lea wrote:

"... why don't you use RetroWeaver? You could only use it for annotations, and you wouldn't be risking almost anything, because RW wouldn't be modifying any executable code, only class meta-data."

Word of caution: while retroweaver provides great opportunities, nothing in this world comes free - there is always a risk, i.e. such innocent-looking code would break:
... new BigDecimal(0) ..., or even worse - 1.4.1 JDK on Solaris blew up (core dump) just because of retroweaved stuff. I was burned hard by this one 8-(

0
Comment actions Permalink

Andrei Tokar wrote:

Keith Lea wrote:

"... why don't you use RetroWeaver? You could only use it for annotations, and you wouldn't be risking almost anything, because RW wouldn't be modifying any executable code, only class meta-data."

Word of caution: while retroweaver provides great opportunities, nothing in this world comes free - there is always a risk, i.e. such innocent-looking code would break:
... new BigDecimal(0) ..., or even worse - 1.4.1 JDK on Solaris blew up (core dump) just because of retroweaved stuff. I was burned hard by this one 8-(


I don't believe RW caused a core dump. Have you reported these issues to
RW team?

0
Comment actions Permalink

Many of the new features (ie, the foreach loop) are just compiler syntatic sugar, and won't even make it to the the compiled class.


Really, I thought, the foreach loop uses Iterable instead of Iterator.

Tom

0
Comment actions Permalink

Really, I thought, the foreach loop uses Iterable
instead of Iterator.


Oh, you're right! My bad on this one, I forgot about Iterable. Damn, this doesn't sounds good for my SCJP exam :P

0
Comment actions Permalink

Well, the new BigDecimal(0) constructor (and lots of other BigDecimal constructors taking a primitive argument) isn't available on JDK 1.4, so this would throw a NoSuchMethodError at runtime, but definitely should not core dump. You can't blame RW on this one, exactly because it doesn't change the bytecode for this constructor call. You've apparently found a bug on Sun JVM.

... that being said, the RW verifier would have marked this constructor call a verification error, so as long as you keep the verifier option turned on, you should be safe from dangers like these.

0
Comment actions Permalink

I absolutely do understand what is the core reason of BigDecimal(0) problem (and some others I hit, that was an example). And yes it gives you NoSuchMeth at <b>RUNTIME</b>. Core dump on the other hand is a totally unrelated issue, which have surfaced only after ANY dependencies on 1.5 were removed. Apparently JVM chokes up on some metadata during class loading (weird/unexpected characters in attribute name, just a guess?). And it's not RW fault, I am talking about 1.4.1_03 JVM on Solaris only, 1.4.2 is perfectly fine, but if you stuck with weblogic 8.1 SP1... That is exactly the primary reason for RW existence, isn't it?
Anyway, my point is that there are problems, which are of runtime nature, so be careful - don't assume good 1.4 code does not need testing after being RWed, that's all.

0
Comment actions Permalink

Anyway, my point is that there are problems, which
are of runtime nature, so be careful - don't assume
good 1.4 code does not need testing after being RWed,
that's all.


QFT

0

Please sign in to leave a comment.