On server, we probably can use bean validation
(
http://beanvalidation.org/1.1/) because it is part of EE6.
We could put the constraints on the domain entities as well as SLSB methods
and the container should do the validation work for us.
On the agent side though, the bean validation approach is kinda heavy-weight
(because for example method validation requires use of something like dynamic
proxies (for EVERY call that should be validated) - i.e. any agent class).
Intellij's approach for @(Not)Null is more ligthweight - it just inserts code
during compilation that does those checks. I'm no expert in this, but I think
bean validation does that only on demand at runtime and it is the
responsibility of some sort of container (JPA,CDI,...) to invoke the
validation.
On Thursday, November 28, 2013 09:16:38 John Mazzitelli wrote:
Get rid of the JetBrains annotations!!! They are useless for those
that
don't use IntelliJ anyway (as you say, we cant' trust them anyway).
I would not say they're useless. Those annotations are @Documented and as such
appear in the javadoc. So you might say they at least are a form of hint to
the callers (even if we don't get the runtime validation that only IntelliJ
can provide in a non-portable way).
I beleive JDK7 introduced similar annotations (or I remember reading
SOME
JDK is going to introduce them) - I'd be ok if we use those.
But those JetBrains ones have got to go.
----- Original Message -----
> Hey,
>
> as I just got bitten again by trusting on @NotNull:
>
> We should decide if we want to keep those annotations and enforce them
> or remove them. The way it is right now just creates confusion.
>
> Personally I am for keeping + enforcing.
>
> Perhaps there is a more official variant from a JSR than the Jetbrains
> counterpart, so that tooling that uses JSR annotations (Findbugs?) can
> work with them.
>
> There may be libraries out there that do not honor @NotNull so that
> we may need to change our code then:
>
> Caused by: com.google.gwt.user.client.rpc.SerializationException:
> java.lang.NullPointerException
>
> at
> com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReade
> r.deserialize(ServerSerializationStreamReader.java:691)
> [gwt-servlet-2.5.0.jar:]
>
> [..]
> Caused by: java.lang.NullPointerException
>
> at
> org.rhq.core.domain.configuration.definition.ConfigurationDefiniti
> on.setName(ConfigurationDefinition.java:139) [
>
> (this NPEd because I made a change to setName() -- but still the getter
> for
> the name also says @NotNull, and the
> behavior that GWT is setting the name to null violates this contract on
> retrieval ).
>
> Heiko
>
> --
> Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
> Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
> Handelsregister: Amtsgericht München HRB 153243
> Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie
> Peters
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel