selling one short for free work?

[tk]

Question for you java gurus in general.

I've done quite a bit of server side in Java (Struts, Servlet, JDBC) and GUI
in Java(Swing) for the past 5 years. Before that, C++ involving alot of
systems and network programming and real time programming for about 7 years.

I'm trying to fill a gap in my J2EE background which is EJB. I've got a
good thing setup right now on my own with an environment of Eclipse, JBoss
and mysql and have been relearning EJB's (I took a training course in it
last year) and it has been going well...

I'm due to lose my job in a month (due to a contract ending) and may be out
of work for a while (with this bad economy)...

Since so many companies in this bad economy can afford to cherry-pick and
place incredible demands about required experience in jobs, am I selling
myself short if I offer to work for free for a company on an EJB-related
project/task? The EJB's and their interfaces and JBoss makes sense to me.
I've already developed Session and Entity beans without any problems.
Biggest problem is getting in the door with companies because they want 2.5
years of experience with this or 1.5 years experience with that, etc...
You know how it is...

Just recently (I don't have .NET) a company (which I don't know the name of)
required 1.5 years of .NET and proof (in the form of paystubs and a call by
one's current manager) that 1.5 years were actually spent programming in
C#/.NET. Nothing else (according to them) would count. So you know it's
hard out there

 

[A Bag Of Memes]

Question for you java gurus in general.

I've done quite a bit of server side in Java (Struts, Servlet, JDBC) and GUI
in Java(Swing) for the past 5 years. Before that, C++ involving alot of
systems and network programming and real time programming for about 7 years.

I'm trying to fill a gap in my J2EE background which is EJB. I've got a
good thing setup right now on my own with an environment of Eclipse, JBoss
and mysql and have been relearning EJB's (I took a training course in it
last year) and it has been going well...

I'm due to lose my job in a month (due to a contract ending) and may be out
of work for a while (with this bad economy)...

Since so many companies in this bad economy can afford to cherry-pick and
place incredible demands about required experience in jobs, am I selling
myself short if I offer to work for free for a company on an EJB-related
project/task?

If you understand session beans (which are pretty straightforward) then I
suggest don't worry too much about entity beans. JDO and other technologies
are better solutions for all of the problems I've see entity beans used for.
EJB was despised and avoided by all of the companies with which I recently
interviewed, including the one that hired me.

 

[Roedy Green]

Since so many companies in this bad economy can afford to cherry-pick and
place incredible demands about required experience in jobs, am I selling
myself short if I offer to work for free for a company on an EJB-related
project/task?

That won't necessarily work to get the experience. The companies
offering EJB experience probably already have a budget for the guy
they want, and they want the least hassle.

If you can't get a job, start a project of your own, with an eye to
being able to demo it to a future employer.

 

[Roedy Green]

Just recently (I don't have .NET) a company (which I don't know the name of)
required 1.5 years of .NET and proof (in the form of paystubs and a call by
one's current manager) that 1.5 years were actually spent programming in
C#/.NET.

I remember in the early days of Java jobs were calling for 5 years
Java experience. Even Gosling and Joy would barely qualify.

They can ask all they want. Can they get it? If they can, they might
as well ask for a lot.

 

[tk]

If you understand session beans (which are pretty straightforward) then I

suggest don't worry too much about entity beans. JDO and other technologies
are better solutions for all of the problems I've see entity beans used for.
EJB was despised and avoided by all of the companies with which I recently
interviewed, including the one that hired me.

Our current company (who is using EJB's but has not allowed me to do much on
the middle tier) avoids
Entity beans as well.

About companies despising EJB's, that's fine and dandy but I still want to
learn it

thanks!!!

 

[tk]

That won't necessarily work to get the experience. The companies

offering EJB experience probably already have a budget for the guy
they want, and they want the least hassle.

But then again in this bad economy, that's not always the case either.

 

[tk]

EJB was despised and avoided by all of the companies with which I
recently
I was curious as to their reasoning for this? My current company is using
EJB's (God I wish I could get into that group but they're just not
interested and I have proved myself on everything they asked me to do) and
have had alot of success in it.

And since JBoss is free, there's no reason to despise it.

 

[A Bag Of Memes]

I was curious as to their reasoning for this? My current company is using
EJB's (God I wish I could get into that group but they're just not
interested and I have proved myself on everything they asked me to do) and
have had alot of success in it.

Entity beans try to solve three distinct problems: object persistence,
querying and distributed processing. As a persistence mechanism they are
more cumbersome than JDO. Queries are limited by implementation differences
between J2EE app servers and a poorly defined spec. They are rarely used
for distributed processing since clustered app servers like WebLogic hide
the details of distribution.

When EJBs first showed up, Sun's plan seemed to be that there would be
multiple J2EE apps running on distributed app servers talking to each
other's entity beans. The problem is everything has to be in Java to work.
Language neutral web services are filling that niche instead. I've worked
at several companies that tried to use entity beans for object-relational
mapping and all of them found maintaining multiple interfaces required for
distributed processing to be more trouble than it was worth. Sun added
local interfaces to address this problem, but the distributed pattern is
still there.

Session beans are useful as a prettier kind of remote procedure call, but
they still have to have Java on both ends.

 

[Sudsy]

A Bag Of Memes wrote:

Entity beans try to solve three distinct problems: object persistence,
querying and distributed processing. As a persistence mechanism they are
more cumbersome than JDO. Queries are limited by implementation differences
between J2EE app servers and a poorly defined spec. They are rarely used
for distributed processing since clustered app servers like WebLogic hide
the details of distribution.

When EJBs first showed up, Sun's plan seemed to be that there would be
multiple J2EE apps running on distributed app servers talking to each
other's entity beans. The problem is everything has to be in Java to work.
Language neutral web services are filling that niche instead. I've worked
at several companies that tried to use entity beans for object-relational
mapping and all of them found maintaining multiple interfaces required for
distributed processing to be more trouble than it was worth. Sun added
local interfaces to address this problem, but the distributed pattern is
still there.

<snip>

I always viewed entity EJBs as just another abstraction layer. The
idea would be that you could replace the back-end RDBMS and only
have to re-implement your entity beans. In fact, with CMP you're
supposed to be able to avoid even that! YMMV ;-)
Business logic goes into the session beans, replacing properietary
stored procedures or triggers in the RDBMS.
But there's no hard-and-fast rule which says that you can't make
JDBC calls directly from stateless session beans. All of the
support mechanisms (connection pools) are already there in the
J2EE server so it's not as though there's a lot of overhead with
this alternate approach.
I worked on a couple of projects where this architecture was
selected as the customer didn't want to mess with entity beans.
With a single data source, that decision makes a lot of sense.
Now if you had multiple data stores, using two-phase commit...
Different tools for different jobs, as I'm wont to say.

 

[A Bag Of Memes]

A Bag Of Memes wrote:

<snip>

I always viewed entity EJBs as just another abstraction layer. The
idea would be that you could replace the back-end RDBMS and only
have to re-implement your entity beans. In fact, with CMP you're
supposed to be able to avoid even that! YMMV ;-)

Why not use JDO then? EJB carries the baggage of distributed processing
that most folks don't need.

 

[Sudsy]

Why not use JDO then? EJB carries the baggage of distributed processing
that most folks don't need.

Okay, but let's review the following statement from Sun's website:

"Alternatives to JDO include direct file I/O, serialization, JDBC, and
Enterprise Java Beans (EJB) Bean Managed Persistence (BMP) or Container
Managed Persistence (CMP) Entity Beans."

You're correct in suggesting that JDO is an alternative to entity
EJBs, but if you've already purchased a J2EE server in order to
implement your business logic in session EJBs, would you really
want to introduce another ingredient to the mix?

 

[A Bag Of Memes]

Okay, but let's review the following statement from Sun's website:

"Alternatives to JDO include direct file I/O, serialization, JDBC, and
Enterprise Java Beans (EJB) Bean Managed Persistence (BMP) or Container
Managed Persistence (CMP) Entity Beans."

You're correct in suggesting that JDO is an alternative to entity
EJBs, but if you've already purchased a J2EE server in order to
implement your business logic in session EJBs, would you really
want to introduce another ingredient to the mix?

If the other ingredient makes the code simpler and easier to maintain,
definitely. Entity beans are a poor solution to several problems. JDO is a
good solution to a single problem. I'd much rather use session beans, web
services, RMI or RPC to talk to components that use JDO internally than
maintain EJBs. Just because I've bought a J2EE server doesn't mean I ought
to use entity beans.