Don't make IDEA 'too smart' on EJB errors... (non-final static fields)

Hello,

Specification says that you should not use non-final static fields, but I
don't know any EJB container where deploying the bean with such a field
results in an error. Why mark this as an error, then?

Don't try to make IDEA to check every statement in EJB specification and
mark non-compliant code with errors. IMHO, you should mark only the errors
that will prevent the successful deployment of the code (like in java source
code -- you should mark only errors that will prevent code complication).

Roman Elizarov.



4 comments
Comment actions Permalink

Hypothetically speaking:

What happens when someone develops an EJB container that conforms to all the
strict rules of the specification and some 'poor soul' using Idea thinks
his/her code is correct because all those errors aren't hi-lighted? When
said 'poor soul' tries to deploy, the container will throw all sorts of
exceptions and the 'poor soul' will wonder why his/her favourite IDE failed
to flag those errors in the first place?

I think it is better for the IDE to flag the errors so that we programmers
write better, more conformant code. On the other hand, I also think there
should be an option to turn it off, because the current code I am working
with is full of red lines where rmi, net etc is used, and it is bloody
annoying!! ;)

Just a thought...

- scott

"Roman Elizarov" <elizarov@acm.org> wrote in message
news:ah8ivt$v5d$1@is.intellij.net...

Hello,

>

Specification says that you should not use non-final static fields, but I
don't know any EJB container where deploying the bean with such a field
results in an error. Why mark this as an error, then?

>

Don't try to make IDEA to check every statement in EJB specification and
mark non-compliant code with errors. IMHO, you should mark only the errors
that will prevent the successful deployment of the code (like in java

source

code -- you should mark only errors that will prevent code complication).

>

Roman Elizarov.

>
>
>


0
Comment actions Permalink

Websphere 4.x gives a warning for this case.

Ara.

"Roman Elizarov" <elizarov@acm.org> wrote in message
news:ah8ivt$v5d$1@is.intellij.net...

Hello,

>

Specification says that you should not use non-final static fields, but I
don't know any EJB container where deploying the bean with such a field
results in an error. Why mark this as an error, then?

>

Don't try to make IDEA to check every statement in EJB specification and
mark non-compliant code with errors. IMHO, you should mark only the errors
that will prevent the successful deployment of the code (like in java

source

code -- you should mark only errors that will prevent code complication).

>

Roman Elizarov.

>
>
>


0
Comment actions Permalink

"Ara Abrahamian" <ara_e_w@yahoo.com> wrote in message
news:ahe8rh$8o1$1@is.intellij.net...

Websphere 4.x gives a warning for this case.


WebSphere gives warnings about everything. Perhaps, if you don't wash
your hands before using it you'll get a warning as well.

The problem is that real world situations push you into doing some
(many?) not recommended things (usings statics for local caching,
accessing files, even using threads not managed by the app server).
The spec slowly covers more and more of these areas but the app servers
(and especially WebSphere) implement the later that we might
want.

r.



0
Comment actions Permalink

Lint used to let you suppress pedantic warnings using special
'lint-supression-comments.'

Maybe IDEA can interpret (even intentionally suggest) special comments which
will suppress this kind of warning. Such as:

/**

  • @IDEA allow-violation-of-non-final-static-ejb-fields

*/
static int violation = 0;

You get the idea.

cc

Roman Elizarov wrote:

Hello,

>

Specification says that you should not use non-final static fields, but I
don't know any EJB container where deploying the bean with such a field
results in an error. Why mark this as an error, then?

>

Don't try to make IDEA to check every statement in EJB specification and
mark non-compliant code with errors. IMHO, you should mark only the errors
that will prevent the successful deployment of the code (like in java source
code -- you should mark only errors that will prevent code complication).

>

Roman Elizarov.


0

Please sign in to leave a comment.