Using final in parameter lists

[Niclas Åstrand]

Hi all!

I've just started on my SCJD assignment and is currently experimenting with CheckStyle and have some questions.

1. The CheckStyle plugin is suggesting that i should mark my parameters as final. I wonder if this is really necessary? I cannot find
anything in Sun's coding conventions saying that parameters should be marked as final.

2. In the interface provided by Sun there are throws clauses for SecurityException which CheckStyle thinks is redundant. Can I remove them?

Thanks in advance!

Niclas

[Yucca Nel]

Nei de kan du ikke.

You must use the exact interface as stated in the MUST. You MUST also use only jdk API as provided by sun so I have serious doubts about you plugin. This project is a test of your ability to code a solution to a problem using the java api at your disposal. Please make sure to read your musts.

[Roel De Nijs]

Hi Niclas,

Welcome to the JavaRanch and good luck with your assignment!

1. I declared all my variables (parameters, local ones,...) final when it was applicable.

2. CheckStyle will indicate it's redundant, because you declared the SecurityException as a RuntimeException. If you would make it a checked exception it won't complain. But RuntimeException is in my opinion the correct choice for this exception, because it should never occur (when it occurs the Data class is used incorrectly). But I would advice not to change Sun's interface, just leave it as is.

Kind regards,
Roel

[Roel De Nijs]

Hi Yucca,

For your information: CheckStyle is just a plugin you can use in your IDE to check your code style: for example it will give warning if you start a class name with a small letter instead of a capital. He isn't using it as a dependency for his assignment (I guess).

Kind regards,
Roel

[Yucca Nel]

lol ok Anyway didn't use such fancy tech for my assignment as my IDE does auto camelCase lol. Yes you are correct that this exception is a candidate for Runtime Exception and not checked exception. Reason:

Joshua Bloch stated in effective java that Runtime exceptions should be thrown along the lines of avoidable situations indicating that if a user of your API does not obey the contract of your API then a relevant RuntimeException should be thrown. So this depends on your implementation of the SecutiyException if a user locks an entity and then does not unlock it again then this may be a good candidate for SecutityException IF and only IF you state that user should use your lock implemetation in a certain way:

For my assignment I stated clearly that users must

lock...
performAction
unlock...

So hat i did was make my unlock test for locking using adaptor design. If the record was not locked then throw security exception as this is due to programatic error as your API instructions ere not followed.

[Niclas Åstrand]

Okey, thank you for your help.

N