J3EE is moron bait
I’ve been trying to ignore this nonsense, but frankly, it’s just so ridiculous and such a nice big fat juicy target that it’s hard to pass up.
The ‘J3EE’ discussions highlight precisely what is wrong with the java community. It strikes at the core of what inspired me to start writing. That gleeful, childish, shameless tugging of one’s own genitalia in public in order to encourage others to also tug at said genitalia for no discernible purpose other than the very obvious.
Where would one start? I mean, half the people realise that the J3EE term is a joke, the other half though are perfectly willing to entertain it as a serious name (setting aside legal issues). Now it’s not too odd to have someone partake of the crack pipe every now and then, but this idea is no crack pipe side effect, it’s so braindamaged that it can only be caused by a full frontal lobotomy.
Amazing as this might be to you toy app junkies, J2EE is not there for fun. It’s not there because a bunch of wankers got together and started an opensource project of stuff they thought is ‘neat’. You might all get off on agile development, TDD, role playing, and silly hand-scribbled notes to do your design. Sadly for you, that’s not how specs work. A spec is indeed a big lumbering giant, one that often is unpleasant and annoying to work with. The value proposition however is not that it’ll make you code any faster, but that it’s a specification for future behaviour, and a commitment to certain contracts and behaviours.
So this insane J3EE idea suggests using hibernate, spring, and pretty much everything that is currently cool. Gosh, I wonder what happens in a year, when all you cutting edge fuckwits have moved onto the next cool thing. You won’t care of course, you can be your happy-idiot self and stumble along giggling at every new thing. The people who will care though are those stupid enough to be taken by your childish hype and enthusiasm and actually went with your ‘J3EE’, and are now stuck with a bunch of legacy apps that even the original developers thereof will say ‘oh, we only support the latest version, and anyway, Hibernate/Spring/AOP/IOC/Pico/Geronimo/JBoss 3.2/Microkernels/JDO/yourmom are no longer supported by us and we recommend you use cool thing X instead. So much for vendor neutrality! You’d basically be choosing to stake your future on about 5 guys, most of whom have shown in one way or another that they’re at least partially retarded.
The only light at the end of the tunnel though is that there are some lone voices out there that ‘get it’. Juergen Hoeller from springframework seems to ‘get’ it, he understands that this silly new proposal has nothing to do with J2EE, and is a layer that would sit on top and make the life of webmonkeys easier, and is at best a ‘best practices’ sort of guide. Cedric Beust also gets it (as shown in a comment on TSS). For those of you who took this ‘joke’ a bit too seriously, it’s time to wake up, or even better, fuck off to another profession.
January 23rd, 2004 at 10:50 am
Any recommended professions to fuck off to?
January 23rd, 2004 at 10:55 am
C is for cookie. That’s good enough for me!
January 23rd, 2004 at 11:50 am
Thanks for the bile, Hani. A bit disappointed you didn’t jump on my Ruby piece though, that was clearly bilebait.
Setting that aside, I’ll actually try to respond in a serious way:
Yes, J3EE is more or less a joke, but…
Most of J2EE is actually quite nice. I don’t mind things like Servlets, JDBC, JTA, JMS, JMX, etc. It’s also nice to have a spec you can rely on, you can actually write really portable applications with it (if you avoid using EJB). But if you are saying that having a spec means that it should not evolve then you are the moron. I believe much of the stuff going on at the moment (AOP, IoC, attributes, lightweight containers) is most certainly going to become the future of J2EE.
I’m working on the .NET platform on my current project and I must say that Microsoft really do get it (in some respects, VS.NET is still absurdly crappy). Creating a pooled object with transaction support is literally about 5 lines of code, *and* you can run it directly in your unit tests, no container. Attributes, some AOP (interceptors), lightweight container. What can I say? If Sun/IBM/BEA don’t get it soon they will start loosing to Big Red.
January 23rd, 2004 at 12:21 pm
First You don’t know what your talking about Hani Post! SUCKA!
January 23rd, 2004 at 1:43 pm
*yawn* J2EE already does Ioc. Maybe you mean dependency injection? As for “light weight containers”, what exactly do you want to drop from the current containers? Pooling? Cache? Transactions? Security? What does “light weight container” even mean? Now, it takes 8 lines to create a stateless session bean (pooled object with transactions) + the xdoclet attributes (not counting imports). Is that really what you’re complaining about, the difference between 5 lines and 8 lines of code? Get real. And you want to run that with your unit tests? Just integrate any of the existing open source containers into your test suite. Big deal. Hani was right about you guys.
January 23rd, 2004 at 1:45 pm
Thank you Hani.
January 23rd, 2004 at 1:45 pm
your != you’re you jizzgobbler
January 23rd, 2004 at 1:48 pm
Hani,
How do you walk with balls as big as yours?
Great bile!!!
January 23rd, 2004 at 3:35 pm
LOL. It’s flamebait. So friggin obvious that I’m surprised you swallow it.
Even the proponents of “J3EE” acknowledge that.
It’s not about a new spec. It’s about providing lightweigh POJO based deelopment models that can leverage the power of J2EE underneath. Without the need to deal with the complexities directly.
Even BEA, IBM and Oracle does that. They offer tools that let you develop for J2EE with POJOs.
P.S. Please rant about mocks soon! D.S.
Aslak - a hani fan.
January 23rd, 2004 at 3:42 pm
You are of course aware that Juergen Hoeller who “gets it” is one of the main developers on the Spring framework.
Hahahahahahahahaha!
January 23rd, 2004 at 6:34 pm
To the one who does not know what ligthweigth means.
How do you create J2EE object with 8 lines of code ? I got to maintain J2EE project wit 600 clases. When going through classes where moustly generated by J2EE wizards from Db tables. each table was represented with 13 generated classes
or interfaces. That just java classes , not counting deployment descriptors e.t.c. Thats less than 50 entities. There should had been one or zero business clases per entity.
Zero when entity is managed by build in framework standard behaviour.
January 24th, 2004 at 3:53 am
J2EE object in 8 lines:
public class J2EEObject implements SessionBean {
public void ejbCreate() throws CreateException {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void ejbRemove() {}
public void setSessionContext(SessionContext ctx) { this.ctx = ctx; }
}
And no, don’t ask me to format it. The rest is either meta tags or your component logic. Pretty simple. We have callbacks (look, its an IoC container!!!) for creation, removal, activation, passivation and per invocation context. What’s so damn difficult about it?
January 24th, 2004 at 5:17 am
What’s difficult about it?
Well, for example using it:
Context ctx = new InitialContext();
J2EEObjectHome home = PortableRemoteObject.narrow(J2EEObjectHome.class, ctx.lookup(”someJndiName”)); // (where do I get the JNDI name from? I can’t even remember!)
J2EEObject o = home.create();
o.doSomething();
In C#:
new DotNetObject().DoSomething(); // only problem: ugly upper case on method name
Setting up declarative transaction:
In C#:
[Transaction(TransactionOption.Required)]
public class DotNetObject : ServicedComponent
Or setting up pooling:
In C#
[ObjectPooling(MinPoolSize=1, MaxPoolSize=100, CreationTimeOut=30)]
public class DotNetObject : ServicedComponent
I know that you can get around some of the limitations with XDoclet but in DotNet all that is built into the standard as a *supported* way of building components. Besides wasn’t Hanis point that you should *not* base your code on some cutting edge fuckwits spastic convolusions in front of a keyboard? (If you look at the XDoclet 1 codebase, that’s more or less what it is.)
Don’t get me wrong here, I love Java and J2EE, but the EJB mess really is completely pointless.
Now I’ve not even talked about whether you really need all that stuff from the start. I’ve built quite a few EJB-based systems in my days, and I’ve built quite a few “POJO” ones too. Guess which ones where more stable, portable, scalable, understandable, maintainable? The EJB system? Pfft, guess again.
January 25th, 2004 at 3:42 am
Yes so you start with complaining how J2EE must go through evil name service (I should have seen that one coming, it is the “pico” equivalent of an AOP zealot coming up with Yet Another Example of How to Implement Tracing (YAEHIT) — woohoo!! Big Deal!! Save the World!) to find other components, and then completely fail to show how .NET does it.
JSR-175 is in 1.5 if I recall, so your calls for progress have been taken a note of long time ago.
Yes and your POJO system serving 20 users was more portable (hah!), more scalable (sure!), and more maintanable (yeah if you are the single developer). Sure, we all buy that. Why don’t you come up with some concrete evidence to prove it. Show they’re for real and maybe people would actually take this POJO stuff seriously.
January 25th, 2004 at 7:22 am
Don’t implement SessionBean directly. Create a reusable AbstractSessionBean that implements this interface and subclass that, overriding only the methods you need to use. This’ll make things easier to read. As for the JNDI, create yourself a decent ServiceLocator with 2 public methods; create() (for Home Interface) and lookup() (for Remote). Have lookup() perform an implicit create. Pass in the Home and Remote interface classes in as parameters. This’ll reduce your JNDI lookup + narrow + create to a single line. Make a standard practice of putting the JNDINAME as a public constant on the Remote interface so your ServiceLocator doesn’t need the extra parameter. Once you do the legwork on this the first time, you shouldn’t have to spend any time thinking about any of this stuff anymore.
January 25th, 2004 at 10:46 am
Huh? You didn’t get how .NET looks up components? I’ll explain it to you again:
DotNetComponent c = new DotNetComponent();
That’s called a constructor, it’s used to look up components in .NET.
Yes, attributes are in JDK 1.5, but how long time will it take until they become part of J2EE? How long time before we won’t have to create the stupid home/remote-interfaces? I’d say don’t hold your breath. When they do I might reconsider my current position on EJB.
Oh, and your “8 line EJB” is not complete. You also need at least two more interfaces (and remember your actual bean is *not* allowed to implement the interfaces, noooo, that would be much to compile-time safe for the poor J2EE developer, he might be confused by the compiler errors and by the smart intentions in IDEA).
Riiight… You can use all sorts of clever hacks to work around some of the limitations. You can use XDoclet to generate that for you. That’s all smells for an underlying technology simply not up to the test.
Proof!? How can you *prove* anything in this business? We don’t even know what productivity *is*. Prove to me how EJB is better than not using it.
You managed to create a portable scaleable system with EJB? How did you manage to working around the completely different locking strategies that WebSphere and WebLogic uses (without falling down to non-portable extensions). The different pooling srategies, threading behaviour.
I’m not sure… But it sounds like you’re the one who hasn’t tried to implement a really scaleable system with EJB.
January 25th, 2004 at 9:47 pm
Uh, Jon, around these here parts the bile comes from Hani ..
January 25th, 2004 at 10:04 pm
I heard they trained monkeys to program computers so you will no longer be needed.
January 26th, 2004 at 11:23 am
Is that a racist comment?
January 26th, 2004 at 1:51 pm
“To the one who does not know what ligthweigth means.
How do you create J2EE object with 8 lines of code ? I got to maintain J2EE project wit 600 clases. When going through classes where moustly generated by J2EE wizards from Db tables. each table was represented with 13 generated classes
or interfaces. That just java classes , not counting deployment descriptors e.t.c. Thats less than 50 entities. There should had been one or zero business clases per entity.
Zero when entity is managed by build in framework standard behaviour.” -Linards
Linards,
your post makes me happy–reminding me that I will always have a job.
First, I take it english isn’t your first language–can’t hold that against you, but you should try harder.
Second, that’s what you get for letting wizards and tools design your app for you.
Try reading the spec. Then read a J2EE patterns book. Once you understand both, then perhaps you’ll understand why you look like a retard right now.
January 26th, 2004 at 11:09 pm
My take on J2EE is that it’s improved with every
release.
There is marked improvement from EJB 1.0
to EJB 2.0, from JSP 1.0 to JSP 2.0 and so on.
Let’s not give up on these guys yet - they’ve
shown the ability to adjust based on user
feedback.
January 26th, 2004 at 11:22 pm
And here I thought J3EE was a joke Hani made up. You mean this tripe is doing the rounds at TSS?
The place that makes blogs look good.
January 27th, 2004 at 3:37 am
> DotNetComponent c = new DotNetComponent();
> That’s called a constructor, it’s used to
> look up components in .NET.
That’s creating a new instance though, isn’t it? How do I hook up with an existing component instance? You’re not suggesting every time I need to use a distributed object I have to create a new instance of it, so how does one find the existing pool that someone created in .NET if there’s no lookup involved? How do you differentiate between creating and finding?
> Oh, and your “8 line EJB” is not complete. You
> also need at least two more interfaces
Well he said the rest is metatags. Can only assume this means XDoclet, EJBGen or such. Tags work for both .NET and J2EE (it’s not in the J2EE spec but then there isn’t a spec of “light weight containers” either, and the .NET with its single vendor implementation leaves a lot to be desired).
Attributes like scalability and maintainability are measurable. Show a single large production site using the new “light weight containers” and go after them and ask for data.
As for your point on locking strategies — well what do you expect if you move between two implementations that must implement features not in the spec. Are you claiming I can port from one “light weight container” implementation to another without having to deal with these problems? I’d like to see that! Or are you claiming I can port from one .NET implementation to another without having to deal with the exact same issues? I’d like to see that too.
So far you’ve provided nothing that convinces me your “lightweight container” or POJO strategies solves any of these problems. It is easy to criticize J2EE spec but you’d be a lot more convincing if you’d actually provided some answers to the points you complain about.
January 27th, 2004 at 7:15 am
600 j2ee ‘objects’? well don’t blame j2ee for poor design. obviously your company’s hiring policy isn’t very good.
we have two ‘j2ee’ classes exluding the servlets and jsps at the front end. one is a stateless bean and the other is it’s service locator.
the only other part that need manual maintainence are the domain objects, the pojo objects that perform operations on same. the transfer objects are generated from schemas with castor.
so we have ONE “ejb” class to maintain. which is a little plumbing (more than 8 lines) but it’s code that would have to be repeated no matter what the layer. and what gives us declarative transactions, proxies and pooling and distributed execution better than a j2ee container?
January 28th, 2004 at 4:15 am
I think you need to change professions, or perhaps lifestyles. This isn’t a post to agree or disagree with your point. It is only to say, relax, take it easy or switch jobs. You only live once. You’re constantly hostile and that only promotes more hostility. Just my opinion.
January 29th, 2004 at 1:05 am
Who the f— are you calling hostile?
Where’s my clown? I’ll show you hostility!
January 29th, 2004 at 9:11 pm
the solution is of course to skip silly J3EE
and instead work on true jakarta-way replacement,
enter commons-services already under construction:
http://www.mail-archive.com/jetspeed-dev@jakarta.apache.org/msg09585.html
January 30th, 2004 at 1:30 am
ALL YOUR J4EE ARE BELONG TO US
someone set us up the J4EE patent
we get signal
main SCO turn on
January 31st, 2004 at 12:47 pm
Huh? You didn’t get how .NET looks up components? I’ll explain it to you again:
DotNetComponent c = new DotNetComponent();
That’s called a constructor, it’s used to look up components in .NET.
what ignorant bile. You are showing a creator() most EJB code is about FINDERS. What an ignorant pig. We are talking about BEGINNER stuff here, not even that complex. Oh I get it, it is because ioc shit only deals with singletons and stateless stuff.
say don’t hold your breath. When they do I might reconsider my current position on EJB.
after pooping your pants like this I wouldn’t run around talking about big boy stuff like EJB.
May 17th, 2004 at 3:39 pm
JAVA IS TEH ROXXOR!