Arjan Times

Originally posted by Ismael Upright:
Just a few people asking about EJB 4.0 like me or saying about their hopes related to EJB 4.0

It will probably be *years*, maybe even more than a decade before EJB 4.0 will see the light of day in a Sun certification. The first update to EJB3 will be EJB3.1. I compiled a small progress page for that here: http://jdevelopment.nl/open-source/java-ee-6-progress-page/

Keep in mind that it may still be up to 2 years before the Java EE 6 specification is finalized. I know the original target was 2008, but if you look at the current state of things this seems highly unlikely. After the Java EE 6 specification has been released, it may take up to 2 or 3 years for all major vendors to implement this. Just look at the current situation with Java EE 5. Also, it may take up to 5 years for the Sun certification exam to get updated to EJB3.1 and probably up to 7 years for books to get updated. With a little luck, books about SCBCD for EJB3.1 will be in stores around 2017.

Assuming EJB4 comes right after EJB3.1, do the math yourself when a SCBCD for EJB4 will appear. If the current pace of advancement continues in the future, something like around 2025 may be a conservative estimate.

Basically what I'm saying is that you probably have some 17 years to go without having to worry about EJB4

Originally posted by Kapil Sreedharan:
But which is the book tat we need to prepare for SCBCD5.

There is no 'official' book. Sun and the publishers think that people who are able to go for the SCBCD5 exam are so smart that they are more than able to select the study material from existing books about EJB3 and JPA themselves.

(note the slightly sarcastic undertone)

Originally posted by Charles Lyons:
Okay, but surely the SCWCD would be a prerequisite to JSF? You should understand all the basic components (which JSF relies upon) before using JSF, so you'd end up taking the SCWCD anyway.

It would be great if the exam was indeed positioned that way, but somehow I feel it isn't. The concepts of a Servlet and a Filter are indeed good to know before starting with JSF. JSP is already less relevant, although it's still the default view technology for JSF. A slight alignment of the terminology (e.g. the term "action" is never used for custom tags in JSF) and some focus on 'bridging' concepts (e.g. the unified EL) would do miracles.

But maybe it's just me being too picky about puzzle pieces fitting together

As far as I can tell, the authors of the new specs went "hey, we've got a great platform here which does everything we want, so let's just make a few minor changes and call it a new spec - that way we keep in line with the rest of Java EE 5 where the changes are really in the EJBs".

I agree with you completely. The thing is, if the authors of the new specs went that way, why couldn't the authors of the exam do the same?

It are indeed only small additions. Perhaps they wouldn't justify creating an entire new exam for, but if you are creating a new exam anyway, why leave these out? It's a minor detail, but there are now indeed generics in the APIs, yet students have to learn explicitly that supposedly Java EE 5 does not have generics in those APIs. We constantly have to remind students that SCWCD 5 is not about Java EE 5, but about J2EE 1.4, even though the exam was released long after Java EE 5 was released. I just fail to see the logic in there.

Plus, inclusion of the unified EL instead of the JSP 2.0 EL and the annotations + resource injections would form a perfect bridge to a possible JSF follow-up exam. As you probably know, the unified EL is identical to what you use in JSF (hence the name ) and the annotations + resource injections for a Servlet are identical to what you use in JSF managed beans.

My point was not in downloading/installing on a home machine, but the system requirements on a server to run.

Ok, I hear you. I have always worked for companies that had their own servers, so for me this never was a problem really. Also, on my own machine I don't see a lot of difference in resource consumption between plain Tomcat (with added libraries) and Jboss or Glassfish. I guess you're right that in a shared hosting environment where every byte matters the advantage for Tomcat is still there.

Originally posted by Charles Lyons:
Except for JSF becoming a core part of the spec, what changes would those be? Do you mean the minor things like whitespace trimming in JSPs? Or perhaps EL 2.1 - the new features of which only really work within JSF?

I mainly refer to JSF itself. Several exam authors, including Bert, have already mentioned that JSF is too large to fit in to the SCWCD exam and that a separate exam would be a possibility.

The thing is that pure JSP programming does not happen a lot any more. At least not in the projects I was or am involved with. I'm a big fan of learning the fundamentals of the technology I or my teammates use though. SCWCD only partially fulfills that. The Servlet API and web.xml are still very relevant, but much of JSP and JSTL really isn't. Of course, that's just for me personally, although I feel it's also not very relevant anymore for a lot of other people.

As I already mentioned in several posts, I was also put off by the fact that SCWCD 5 is about J2EE 1.4. There's not a -single- Java EE 5 thing in there. The exam already was about a 6 years old programming paradigm, but it also actually is about a 6 years old spec. The least they could have done is update the exam to JSP 2.1 and Servlet 2.5. Some keep stressing that the changes in those specs were too small to warrant inclusion in the updated exam, but if they were so small you could just as well say that there's no reason to explicitly exclude them from the exam.

to run an EJB server properly you need better infrastructure than to run just, say, a Tomcat container.

This is another discussion really, but I think that kind of comment very much represents a ~2002 way of thinking. During that time Java application servers were big commercial things with a hefty price tag and complicated support contracts. Tomcat could just be downloaded and it worked. Fast forward to 2008. A full Java EE implementation can be downloaded just as fast as one can download Tomcat. They are free, they are open source and they install just as simple. Most people I know add at least JSF, JPA and JTA and often JMS separately to Tomcat. If you add all that, you suffer quite some overhead of keeping a ton of individual jars up to date. It's far easier to start with a full implementation (Jboss, Glassfish, Geronimo) and remove what you don't need, then to start with a minimal implementation (Tomcat, Jetty) and add stuff from different locations, with unknown dependencies and varying release schedules.

At least Jboss very easily lets you disable stuff you don't need, and Glassfish lazily loads parts of the Java EE API that your app is actually using.

This is why the vast majority of hosting companies who offer Java Web hosting only offer the Web tier

The kind of people who make use of shared hosting rarely do a lot more than building some simple web pages.

It is also true that while you do logic with EJBs, you can do everything from logic to presentation within the Web tier

You can, but as your application grows you really shouldn't. It's perfectly ok for small web sites to do everything in the web tier, but the larger your app gets, the more you'll be fighting against spaghetti code creeping up everywhere. At some point in time you simply *need* MVC, where the M in there is based on a solid foundation of a DAO approach with services and transactions.

I'm not advocating that every small web site should be MVC, but when you need it, you need it. No point in arguing with that. Not every building is a high-rise, but if you do need a high-rise you better have some architecture to support it.

(yes, it won't do things like CMP for you, but if it's only a simple model it doesn't really matter and you can code the support up for yourself or use an existing framework).

I'm not sure I follow. We have JPA these days and it works really well. It's a simple XML or annotations (you choose) based model. It can be used in a Java SE application, or in a container managed environment. The latter gives you the benefit of simple declarative transactions among others. Of course, if you really wanted you could also use JPA directly as a scriptlet on a JSP page.

JPA is on the SCBCD exam...

EJBs have also frequently been referred to as a "bloated" API, though with the new annotations this is much less of a truism.

Much less? It's a complete anti statement with EJB3. Many people find EJB3 to be lighter than say Spring (which arguably isn't that light actually, but still) and with something like OpenEJB3 you can even unit test your enterprise beans outside the application server.

Originally posted by Paul Michael:
Most people (if I got my statistics right) take WCD first before BCD.

I'm considering taken them the other way around for a very specific reason: SCWCD is seriously outdated, while SCBCD is very up to date. Where I work, we're mainly using JSF and Facelets. Although the Servlet part of SCWCD is still interesting, I feel weird training for a J2EE 1.4 set of technologies, while we are completely based on Java EE 5. Don't forget that J2EE 1.4 is from 2002. There have been some changes in the world during the past 6 years, but the material in SCWCD hasn't changed at all to reflect this. Basically you're learning nearly 6 year old stuff.

My hope is that while I study for SCBCD, Sun will introduce a new exam that focuses on the Java EE 5 web layer, instead of the one from J2EE 1.4. There have been a few hints here and there that something like this may happen, although sadly nothing really substantial.

Originally posted by Marc Peabody:
You're looking at the wrong material. The exam uses the J2EE 1.4 specs and APIs. In 1.4 they all return a plain old Enumeration.

As I mentioned before in other topics; this is exactly why it's so highly confusing that SCWCD 5 is about 1.4 and not about 5.

Originally posted by Anirudh Vyas:

And no, i don't think anything is fixed in JSF dude, Just take a look at spec 1.2 you would know what i am talking about.

Perhaps you don't exactly understand what I mean. The thing is, JSF in its core is very simple and basic. It's more of a meta framework (a framework core) to build stuff on.

Take for example your little rant against the datatable, which you used to point out that JSF basically s*cks. A remark like that is quite typical for people who don't get what JSF is about. The DataTable component that comes with the base JSF implementation is just that. An 'example'. It doesn't point to any weakness in the JSF architecture itself. The whole point of JSF is among others that it standardizes a component model that others leverage to take advantage of.

You might want to contrast this with the Java language itself. Sun created the Java language, and at the same time also delivered a small library with it. As we all know, the JDK 1.0 library was small and its classes at times a bit cumbersome and arcane. Yet, the language itself facilitated that others could build great software with it. The absence of some basic classes in that JDK 1.0 library might have been unfortunate, but in no way was this related to a weakness in the Java language itself. Over time, the standard library expanded, and a lot of quality classes were included, without changing the language.

This is currently the same with JSF. The basic infrastructure is there now. The standard set of components is extremely basic and sometimes barely usable. Yet, see what component sets have been build that take advantage of the spec.

Phases, are not aligned for one.

What do you mean by that? Phases come right after each other. Restore / create view, apply request values, perform validation and conversion, etc. With what do you want to align that? It alligns perfectly well with the best practices of how one would do things manually. It's in anyway exactly the order in which I have been doing things in the past using Servlet based MVC. If you -really- want to replace the JSF lifecycle (and its associated) phases with something else, then even this is allowed in JSF. You'd be truly amazed at how much you can decorate, extend, or replace in JSF.

Components customization is a nightmare in jsf.

Not in the core spec. Inherit your Java class from some (UI) component, override some behavior and presto, instant customization of a component. Of course you mean that to use such a component on a JSP page, you have to create a taghandler and an entry in some TLD file as well. That's unfortunate indeed, but know what? JSP is just -a- method to create the component tree and hand it over to the faces controller, not -the- method.

Then its JSP used in JSF. I think JSP is a straight violation of MVC design pattern. JSP can contain blah blah logic

You are -so- not getting it. Like I said above, JSP is -a- method to construct a tree out of a set of components. Nothing stops you at creating this tree in pure Java. And guess what things you can do in pure Java? Do business logic... According to you, there almost can't be an MVC design pattern. If you're doing a Java, C++, C#, whatever client side application, the view layer is typically composed using that language; e.g. JButton someButton = new JButton(); somePanel.addWidget(someButton); You know the drill. Now -that's- MVC as pure as it can get. Yet, this way of working theoretically allows you to mix business logic (not just logic, but business logic) in your view layer. You would be stupid to do so, but it's possible.

With JSP, you can do so too. Mix business logic in the part that is supposed to create the component tree and nothing more. You would be an *ss if you did so, but it's indeed possible. Nevertheless, JSP itself does not violate the MVC pattern. Namely, this pattern does not exclude the use of logic in the view. It's actually perfectly legal to use logic; RENDER logic.

Of course there is another often used method for creating the component tree, and that is Facelets. To reiterate my above statement; the fact that Facelets exists is -not- a proof that JSF was broken and needed something like Facelets to fix it. Quite the contrary, JSF in its core was specifically created so that something like Facelets could be made possible. There is absolutely no dependency on JSP anywhere in the JSF spec, nor is there any such dependency in the current implementations. JSP in only the default method, but absolutely not a required one for a JSF application.

Originally posted by Anirudh Vyas:
I don't understand why JSF has to be on the list of certification at all. Personally, I'd like to see JSF turn into Wicket Framework.

Why would you want that? If you like Wicket, just use that...

Currently just about everything in JSF is a nightmare.

That's your opinion, I find JSF to be very elegant and extremely extensible.

But let me guess, you are the kind of person who thinks stuff like Facelets and Seam or perhaps even Richfaces 'fixes' things broken in JSF right?

Originally posted by Bryan Basham:

I can tell you that Sun Microsystems does not have a certification on JSF currently; however, I have recommended that they incorporate some JSF topics into Sun's SCWCD exam.

That's probably not going to happen. SCWCD has recently been updated (well, it's name was updated and some 'bugs' where fixed) so it'll be at least a couple of years till the next SCWCD update. Next to that Bert Bates among others has already mentioned that JSF is way too large to squeeze into the SCWCD exam.

So I guess if you want to be certified you have to learn about Struts and JSP/JSTL, while the rest of world is using JSF. Sad...

Originally posted by Seena Conne:
How do you know that it covers 1.4 and not 1.5 when the title of the exam says Java Platform, Enterprise Edition 5. Doesn't that mean it is JEE 5 and not J2EE 1.4?

That's the cause of my confusion

It's the cause of everybody's confusion I think. I constantly have to direct people to either the FAQ or the official exam directives. At first, most people just don't believe me when I tell them a Java EE 5 exam is actually about J2EE 1.4. No matter how tiny and how small the differences are, it's just plain weird to name the exam 5 when it's about 1.4.

Again, if the exam creators are so against (or just don't see the point in) asking things about Servlet 2.5 etc, then why -did- they choose the name of the exam to be SCWCD 5? Wouldn't SCWCD 1.4 r2 orso be a far better name?

Originally posted by Marc Peabody:

The changes are typically so minor that they wouldn't have made the cut even if the exam were completely rewritten.

I understand what you are saying, but I'm not sure I made it clear what I meant to say myself . The thing is, I'm ok with the fact that there may not be any questions about the things that have changed. They are indeed minor things and as you said, there are bigger fish to fry.

However, and this is a key thing IMHO, the exam is set up in such a way that a student has to be careful to -avoid- her new knowledge about Java EE 5. The exam has the 5 in it, yet if it so happens that a question on the exam includes something that is legal in Java EE 5, but not in J2EE 1.4, then you *must* answer that it is not legal!

I know this is a subtle thing, but I hope you understand my point.

The thing is, no matter if you think the Servlet 2.5 additions are minor, major or something in between, it's *very* confusing that an exam with the "5" in it, is actually about J2EE 1.4.

What's next? A new SCJP 7 that is strictly about Java SE 6?

Originally posted by Ulf Dittmer:
(The jsp:param tag is used to add parameters to an applet tag. It has nothing to do with HTTP request parameters.)

jsp:param is (also) used to store parameters in page scope, which is the scope that is valid for a single page only for a single request, excluding the pages that have included it, or the pages that it includes itself.

As such, jsp:param is used to communicate values to a page that's been included by another page. Page scope is debatable though, since it doesn't exist in JSF anymore and most people seem to 'scale up' to JSF at some point in time. Nevertheless, for the exam you should know exactly what page scope is all about ;)
[ February 24, 2008: Message edited by: Arjan Times ]

Originally posted by Charles Lyons:
Have you looked at the changes between the J2EE 1.4 and Java EE 5 versions of the specs? There are only a handful of really minor things which may, occasionally, prove useful to you (like trimming extraneous whitespace) but nothing there which will affect your day-to-day development at all.

What you are basically saying is that there is not really a good reason to include those 'minor' tweaks, right? I would rather pose the question the other way around; was there really a good reason to exclude them?

If they are so minor, why not just include them? Why cause all this confusion? Why call an exam version "5" when it's about "1.4"?

Originally posted by Aleksander Switalski:


These objectives have been removed by accident probably, because I had questions about EL functions and operators on SCWCD 5 exam.
Someone did copy-paste on objectives not quite right

Wow, if what you say is true than that's quite uhmm.. careless of Sun. I've seen some small typos in objectives before. E.g. SJCP 5 had a class mentioned in its objectives, which they simply forgot to remove. Since published objectives may never be changed, this class was never removed from the list (according to Bert in his book).

But actually copy-pasting something wrongly so that 2 subjects are omitted.

Not good...

I wonder why Sun doesn't update its objectives for such an obvious typo?

Originally posted by Marc Peabody:
The 1.4 specs will be valid for version 5 of SCWCD since no new topics were added.

On top of that the 5 specs are invalid for version 5 of the SCWCD exam. So, if you want to take the SCWCD 5 exam, don't even look at Servlet 2.5 etc. You run the risk that you remember something that is in Servlet 2.5, but isn't in Servlet 2.4. For the SCWCD exam, you must mentally assume that there is only Servlet 2.4.

For example, I use something like the following a lot:

<servlet-mapping> <servlet-name>color</servlet-name> <url-pattern>/color/*</url-pattern> <url-pattern>/colour/*</url-pattern> </servlet-mapping>

When taking the SCWCD 5 exam, I actually have to remember that I must forget that something like this is possible. If the exam makers are really tricky (and as we know, sometimes they are ), they might just ask a question using the above syntax. The answer would be naturally that it works, but specifically for SCWCD 5 you must remember that it doesn't work and that the AS will not start up in this case.

So, the 5 in SCWCD 5 has no relation at all with the 5 in Java EE 5.