users@javaee-spec.java.net

[javaee-spec users] [jsr342-experts] Re: Code-Examples in the EE Spec

From: Werner Keil <werner.keil_at_gmail.com>
Date: Fri, 2 Mar 2012 11:32:23 +0100

Markus/all,

Thanks a lot for pointing this out.

I assume also living in Central Europe most of the time you picked this
blog quote randomly or because you happen to meet Eberhard more often?

Beside an obvious point this coming from a former SpringSource staff
hopefully won't fuel more "Spring vs. Java EE" discussions we all see
everywhere too much.

Having been in a lot of big projects, especially with a few clients where
people often relied on such samples and turned some even into production
code, I can tell you, without people who understand Spring, Java EE or both
to their rescue, samples and documentation provided by Spring for free
without an expensive trainer on site are as pseudo and dangerous as some of
the ones you pointed out here.

I agree in the interest of honesty and transparency, it would be good to
state those in many Java Specs, not just EE.

Cheers,
Werner
Am 02.03.2012 10:59 schrieb "Markus Eisele" <myfear_at_web.de>:

> Hi all,
>
> I would like to start a short discussion about the use and quality of
> code-examples in EE 7 and the contained specs.
> The discussion I had with a couple of guys personally and via twitter
> ended up with Eberhard writing up his thoughts
> a bit more detailed here
>
> http://jandiandme.blogspot.com/2012/02/dangerous-code-example-in-ejb-31-spec.html
>
> To be honest, I have not seen this as a major issue. But looking
> around and asking my peers
> shows, that many of them are looking at the spec documents as the
> single point of truth if some container seems to behave weird.
>
> Beside the fact, that the spec documents should point out basic
> concepts and don't
> provide tutorial-like examples. I would like to see a general
> statement in place, which should also be included by all contained
> specs to
> explicitly state if code is pseudo code or incomplete to any other
> reason. Maybe this is something that could
> be added to to general DISCLAIMER OF WARRANTIES which already covers
> more general technical inaccuracies.
>
> Would love to get feedback about this and how your experiences in the
> field are.
>
> Thanks,
> - Markus
>