<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: JavaOne 2006, Friday</title>
	<atom:link href="http://www.obfuscated.org/2006/05/19/javaone-2006-friday/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.obfuscated.org/2006/05/19/javaone-2006-friday/</link>
	<description>I will not explain what this weblog is all about in a few words.</description>
	<pubDate>Thu, 20 Nov 2008 13:52:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
		<item>
		<title>By: Tej</title>
		<link>http://www.obfuscated.org/2006/05/19/javaone-2006-friday/#comment-403</link>
		<dc:creator>Tej</dc:creator>
		<pubDate>Thu, 25 May 2006 14:40:24 +0000</pubDate>
		<guid isPermaLink="false">#comment-403</guid>
		<description>&lt;p&gt;Back in the day I tried to migrate an EJB 1 app to EJB 2.  Dear god, it was painful.  Far more painful than migrating from Sybase to Oracle, which in itself says a lot.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Back in the day I tried to migrate an EJB 1 app to EJB 2.  Dear god, it was painful.  Far more painful than migrating from Sybase to Oracle, which in itself says a lot.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Tej</title>
		<link>http://www.obfuscated.org/2006/05/19/javaone-2006-friday/#comment-402</link>
		<dc:creator>Tej</dc:creator>
		<pubDate>Thu, 25 May 2006 14:39:26 +0000</pubDate>
		<guid isPermaLink="false">#comment-402</guid>
		<description>&lt;p&gt;EJB is really only useful in the Complete Enterprise Solution type of app.  Or stuff that absolutely needs to have someone else to blame should it break.  I find it ironic that the guy raised his hand for job security on AJAX apps.  EJB apps foster more job security than anything I've ever seen.&lt;/p&gt;

&lt;p&gt;But for things like large transaction apps that absolutely have to work for absolutely everyone, and one screwed transaction can mean millions of renminbi (financial sector type stuff, meaning Citibank, not FQ), EJB3 looks nice.  Of course they're definitely not first movers and probably are still looking at EJB1.&lt;/p&gt;

&lt;p&gt;Java 1.5 is much better than 1.4.  Going back to 1.4 temporarily recently has been painful since it keeps bitching at me because I've gotten used to autoboxing and generics.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>EJB is really only useful in the Complete Enterprise Solution type of app.  Or stuff that absolutely needs to have someone else to blame should it break.  I find it ironic that the guy raised his hand for job security on AJAX apps.  EJB apps foster more job security than anything I&#8217;ve ever seen.</p>

<p>But for things like large transaction apps that absolutely have to work for absolutely everyone, and one screwed transaction can mean millions of renminbi (financial sector type stuff, meaning Citibank, not FQ), EJB3 looks nice.  Of course they&#8217;re definitely not first movers and probably are still looking at EJB1.</p>

<p>Java 1.5 is much better than 1.4.  Going back to 1.4 temporarily recently has been painful since it keeps bitching at me because I&#8217;ve gotten used to autoboxing and generics.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Corey</title>
		<link>http://www.obfuscated.org/2006/05/19/javaone-2006-friday/#comment-399</link>
		<dc:creator>Corey</dc:creator>
		<pubDate>Mon, 22 May 2006 15:03:08 +0000</pubDate>
		<guid isPermaLink="false">#comment-399</guid>
		<description>&lt;p&gt;I won't argue that the patterns EJB supply could be useful.  It's just that the implementation seems &lt;em&gt;so* heavy and *so&lt;/em&gt; aukward that I can't see it providing anything worth the pain of using it.  Now, had I actually used an EJB implementation prior to 3, perhaps I'd be singing a different tune.  Who knows?&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I won&#8217;t argue that the patterns EJB supply could be useful.  It&#8217;s just that the implementation seems <em>so* heavy and *so</em> aukward that I can&#8217;t see it providing anything worth the pain of using it.  Now, had I actually used an EJB implementation prior to 3, perhaps I&#8217;d be singing a different tune.  Who knows?</p>]]></content:encoded>
	</item>
	<item>
		<title>By: robert</title>
		<link>http://www.obfuscated.org/2006/05/19/javaone-2006-friday/#comment-398</link>
		<dc:creator>robert</dc:creator>
		<pubDate>Mon, 22 May 2006 13:35:21 +0000</pubDate>
		<guid isPermaLink="false">#comment-398</guid>
		<description>&lt;p&gt;You know, I actually came away with a different opinion on EJB.  I've always liked stateless session beans as the "entry point" or session facade if you will for my business logic.  &lt;/p&gt;

&lt;p&gt;Presentation and navigation stuff stays up in the web layer and anything business related happens in a session bean or below (DAO, etc).  The reason I like them is that you get transactions for free and they are independent of the web layer.  This is good for reuse.&lt;/p&gt;

&lt;p&gt;With EJB3 they've basically peeled all the crap away that made EJB's a pain to use.  Now you just code a Java class and add maybe one or two annotations.  For that small amount of work, you get container managed transactions, dependency injection, the ability to expose your bean as a web service (one more annotation), etc.  They look pretty good to me.  The only downside is (still) that the code must be run inside of a J2EE container.  This can be a bit painful for testing but there's Cactus to address that.  If you don't like this aspect, then maybe Spring is the way to go.  I think the new EJB looks extremely good - better by leaps and bounds than previous versions.&lt;/p&gt;

&lt;p&gt;As for annotations, just think of them simply as source code.  Anything you would hardcode with source, annotations are appropriate for.  Anything you would not hardcode, use a database instead - just like you always did.  &lt;/p&gt;

&lt;p&gt;Anyhow, I'll just be glad to get on to Java 5.  I would kill for auto-unboxing alone.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>You know, I actually came away with a different opinion on EJB.  I&#8217;ve always liked stateless session beans as the &#8220;entry point&#8221; or session facade if you will for my business logic.  </p>

<p>Presentation and navigation stuff stays up in the web layer and anything business related happens in a session bean or below (DAO, etc).  The reason I like them is that you get transactions for free and they are independent of the web layer.  This is good for reuse.</p>

<p>With EJB3 they&#8217;ve basically peeled all the crap away that made EJB&#8217;s a pain to use.  Now you just code a Java class and add maybe one or two annotations.  For that small amount of work, you get container managed transactions, dependency injection, the ability to expose your bean as a web service (one more annotation), etc.  They look pretty good to me.  The only downside is (still) that the code must be run inside of a J2EE container.  This can be a bit painful for testing but there&#8217;s Cactus to address that.  If you don&#8217;t like this aspect, then maybe Spring is the way to go.  I think the new EJB looks extremely good - better by leaps and bounds than previous versions.</p>

<p>As for annotations, just think of them simply as source code.  Anything you would hardcode with source, annotations are appropriate for.  Anything you would not hardcode, use a database instead - just like you always did.  </p>

<p>Anyhow, I&#8217;ll just be glad to get on to Java 5.  I would kill for auto-unboxing alone.</p>]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.404 seconds -->
