×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Rapid J2EE Development

timothy posted more than 8 years ago | from the zip-zoom dept.

Java 146

pankaj_kumar writes "'Tools are an aid to productivity, but you only get the benefits of the tool by using it for the right task; hammers bang in nails and screwdrivers are for screws.' This quote from chapter 9 ("Scripting") from Alan Monnox's Rapid J2EE Development applies not only to the choice of the programming language but to the whole array of software development activities thoroughly and eloquently covered in the book." Read on for the rest of Kumar's review.

"Using a Hole-Hawg for the job of a homeowners drill can have deleterious effect on productivity by causing serious harm to the health of the inexperienced operator." Just identifying a tool for a task is not enough. You should also be able to match the demands of the task to the characteristics of the tool and your ability to handle the tool. The good news is that this book passes even this stringent test, suggesting very practical and hands-on approach for choosing the tool with right characteristics for the specific demands of the task.

The ever-growing body of literature on development best practices, the burgeoning ranks of supporting tools and the accompanying debates on their relative merits can easily overwhelm most practitioners. Worst, a large chunk of the developer community may never spend the time and effort and miss the opportunity to take advantage of them altogether. Rapid J2EE Development offers an easy path to such Java developers by bringing together a number development techniques, best practices and description of supporting open source tools in a single book.

Whether you are a confused Java developer, overwhelmed project leader or plain lost manager, this book has something for you. Wondering about how to design complicated class hierarchies to encapsulate the ever-changing business rules? Worry not, follow the advice of Chapter 10, "Working to Rule" and use Jess, an open-source Expert System Shell. Don't have the time or motivation to download and play with it? No problem. The coverage includes not only an overview and discussion on when and where to use it but also presents a sample session and illustrative code snippets.

If you're confused with all the hype around AOP (Aspect Oriented Programming) and uncertain about where to start, start with the chapter "Aspect Oriented Programming," which introduces the notion of crosscutting concerns in any large software project, presents the AOP terminology to nail down these concerns and associated actions, and covers AspectJ and AspectWerkz to apply AOP to your projects. The brief description of these tools may not answer each and every question, but the example- and code-driven approach will certainly make you feel a lot more comfortable and motivate to explore further.

Not able to decide whether to use XP (Extreme Programming) or RUP (Rational Unified Process) for your next project involving four different development teams in three different continents interacting with as many customer groups? The Chapter "Embracing Adaptive Methods" outlines an approach to making such methodology decisions, though it is not very obvious from the chapter title. (Of course, you will have to read the sections that talk about when XP works best and when the rigors of RUP start paying off to make your decision.) And although there is not much discussion around mixing elements of development methodologies or adapting them in the middle of an ongoing project, the author's account of a real case study does exactly this.

These are just a few examples. Other topics covered include use of UML for modeling, code generators, Model-Driven Architectures, Java-based scripting languages, Object Relational mapping, build and test automation, and use of the right IDE plug-ins for J2EE projects. Among the development tools, all the usual suspects are there: Apache Ant, Eclipse, Jython, JUnit, HttpUnit, JMeter. In fact, I also found description of tools that were somewhat new to me: MyEclipse, AndroMDA, Middlegen and few others.

I found the book to be highly readable, insightful and loaded with the right kind of details. For example, the information on debugging with Eclipse explains how to configure a J2EE program for remote debugging, and how to debug a Web application using JSPs, something that is quite hard to do without the right tools and the right methods. Even the UML primer, with its well-chosen examples, is a good refresher.

It is easy to get superficial when covering a lot of ground: a common pitfall for authors of books on new technologies is that they themselves get caught up in the hype and lose perspective, but Alan somehow manages to keep the extraneous stuff out and deliver what a hands-on professional looks for. He tempers his zeal with practical realities and conveys the same to the reader with anecdotes and discussions with colorful stories such as the Cargo Cult Software trap and Christmas Puppy Syndrome.

The book manages to introduce a number of the very best open source Java tools available to boost productivity in a very natural manner and with the appropriate context, and it succeeds in giving a "feel" for the tool by presenting hands-on sessions. Most other such efforts that I am aware of usually end up being a drab list of tools with descriptions taken from home pages.

Given the number of topics and tools covered, it would be unrealistic to expect in-depth coverage of everything. What this book does is to create the right context, introduce the appropriate topics, and generate sufficient motivation to explore further. Fair enough. In fact, I believe this is the best approach for any book in this "Google era" -- the book should tell what you should look for and let Google do the rest.

So, is there anything not to be liked about the book? Well, I was a little disappointed to not find my favorite BeanShell among various Java scripting alternatives. Another thing I noticed is that the coverage of system manageability issues, especially in a book with J2EE in its title, was quite conspicuous by its absence. Also, some of the points, especially those around use of best practices and development techniques, could be made more emphatically with help of focused and concrete anecdotes.

Of course, no book can cover everything, especially on topics that are open-ended by nature. Overall, I think it does justice to the subject matter and is worth reading by anyone even remotely connected to the business of creating, maintaining or operating Java/J2EE software.


You can purchase Rapid J2EE Development from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

146 comments

FP (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#12296342)

Use Ruby? FP!

What's that humming? (5, Funny)

Anonymous Coward | more than 8 years ago | (#12296349)

Is it.... Yes, it's all the buzzwords! A giant swarm of them!

Re:What's that humming? (1)

nametaken (610866) | more than 8 years ago | (#12296481)


Aye, and what's this... the "hole-hawg" example? Now I know I've seen this in some other authors book. Was it Neal Stephenson's "In the Beginning was the Command Line"? I think so!

Re:What's that humming? (1)

Urusai (865560) | more than 8 years ago | (#12296833)

Wow, my instant reaction too. Usually buzzwords are an attempt to pretend you have something to say but don't, and are featured prominently in business/management theory. Does the IT buzzword storm mean the end of IT relevance to reality?

Re:What's that humming? (0)

Anonymous Coward | more than 8 years ago | (#12296867)

It's a reaction to the extremely swift proliferation of new tools, many of which do similar jobs. It's not so much a failure of natural languages to catch up as it is a failure to design richer more versitile languages for talking with machines.

Re:What's that humming? (1)

John Seminal (698722) | more than 8 years ago | (#12296982)

Is it.... Yes, it's all the buzzwords! A giant swarm of them!

I liked playing around with Java and JSP. But I hate J2EE, it makes the simple so damn complex. I think very few people understand it inside and out, and most people just use the buzzwords. When I was studying J2EE, I started with EJB's, moved on to JNDI, and on and on and on. It never ended. My brain finally could take no more, and I went back to HTML programming and database sql contracts. When you learn SQL, you can work just about anywhere with any database. When you learn J2EE, you still have 5 more years of work ahead of you. And it is possible that what you learn TODAY might be obsolete TOMORROW.

I try and get most places to use a tomcat and JSP solution. If a small company wants J2EE, I tell them good luck finding someone.

Re:What's that humming? (3, Informative)

Bellyflop (681305) | more than 8 years ago | (#12297316)

JSP uses javax.servlet which is part of J2EE. I think perhaps you're referring to EJBs, JNDI and the rest of J2EE though I'm not sure. They are a bit difficult to grasp at first and they are the wrong tool for some jobs, and sometimes the right tool used the wrong way for other jobs.

HTML and SQL is definitely effective for some jobs, but a total mess for others. I worked with a company whose commerce site consisted of ASPs that really did very little and HUGE SQL stored procs (multiple thousands of lines of spaghetti) that only one guy could really change. Thankfully, they threw it all out for a more rational solution.

It's true, J2EE might be considered totally obsolete tomorrow if something incredibly powerful and useful comes out, but that's true of any technology, including HTML and SQL. Remember, there was DB technology before SQL. But beign obsolete doesn't mean it won't be used of course...I still see a lot of Fortran and COBOL out there.

Re:What's that humming? (4, Interesting)

achacha (139424) | more than 8 years ago | (#12297669)

From my experience since introduction of EBJ, it is the wrong tool for every job. I hate to generalize, but I have tried to find a place where EJB works better than other technologies out there and have not. The worst part is for the areas where EJB did work it was so horribly slow that it was only usable on the small scale. Overall, EJB (and the bulk of J2EE) seems to be designed on paper and not in practice. The most useful parts are servlets , you can use them to build nearly everything that you can't build with JSP.

Where I currently work, EBJ was attempted and 6 months later completely gutted and removed, the performance, complexity, tediousness in deployment, and lack of people who know it well were the biggest problems (and this is a place with almost 1000 java developers). At first it seemed like it would work well, allow separation of business and presentation and allow persistence; that's what you get on paper, in real life it is too cumbersome to work with.

I think EJB is going to go the way of CORBA (into the great code graveyard), nice in concept but not very useful when you take your idea from the lab to the real world.

Re:What's that humming? (2, Insightful)

tonejava (772709) | more than 8 years ago | (#12297685)

I hate J2EE, it makes the simple so damn complex

This is one thing I don't understand. People believe that J2EE is the be all end all solution for everything and it's not. If you have a basic site that requires minimal dynamicism then J2EE is not always the right solution - I would purely recommend PHP. If you are using messaging, require flexible reusability, modularity for a distributed system then I would recommend J2EE.

A simple e-commerce website needs no more than say 3 base services: database connectivity, security, email. J2EE offers you those 3 plus a persistence layer (EJB), Messaging (JMS), Object oreinted code, separation of functionality (web containers, ejb containers, third party containers) and extensibility. Yes you need to design a J2EE application a PHP web application can be whipped up with as little design required as possible.

I think very few people understand it inside and out,

I would agree with you there. Alot of people believe just because they can write a Hello World App in Java then they can program J2EE. Also J2EE is vast people don't expect you know the full system inside out unless you have been working in the industry for at least 5-10 years.

When you learn SQL, you can work just about anywhere with any database

Understanding SQL is good but I would never fully place all functionality into stored procedures unless the database system is required to remove load off the Java app server. If there is legacy SQL procedures in place for say password encryption or data integrity then fine it sits in the DB. If it requires going through thousands of tables then sure let the database do it. It's all about finding balance without affecting portability of code.

And it is possible that what you learn TODAY might be obsolete TOMORROW

Java is constantly evolving and yes there is more than one way to acheive the same result. It's all about how much time you have and what resources are available.

For example we recently had 5 months to put together a document delivery solution which applied DRM to PDF documents. One of our contractors was all into the "design it my way" solution which affected the project heavily. He tried to design his own user security system (Authentication and Authorisation ). He spent nearly 4 weeks working on it and left without even finishing his work! With tight time constraints there is no time to redesign the wheel, make use of whats out there! Our original path was to design the system using EJB's for the persistence layer but it took too long to design and learn so we switched to Hibernate.

Working with J2EE is all about knowing what resources are out there you can use and keeping up to date. Yes knowing the basics is always required if not core but Java opens up your options and when used correctly is an excellent language for RAD. Modelling a project and generating your Java code, table DDL's and any ancillary schemas makes the project move much more quickly and you will always have your model to refer back to which is much easier to follow than trying to wade through all that code.

does not cover Spring I suppose? (3, Informative)

BigGerman (541312) | more than 8 years ago | (#12296350)

Spring is a must-know-about thing for potential readers of this book, IMHO

The most important J2EE Bean of all (1, Insightful)

Anonymous Coward | more than 8 years ago | (#12296797)

is the Get-The-Money-For-The-Project-Up-Front Bean. I've seen too many J2EE projects flounder with performance problems for years before they are replaced with a simple and fast servlet solution. Everyone ends up doing the same, admit it.

Re:The most important J2EE Bean of all (1)

saden1 (581102) | more than 8 years ago | (#12296938)

Performance cost of using frameworks (spring or struts for that matter) is next to nothing. Performance problems are often due to bad design and coding practices. Just yesterday I fixed a bug where one of our developers wrote a query to get hundreds of records and then needlessly go back to the database for each of those records to retrieve related data.

Simple and fast servlet solution? Seriously, what does that mean?

Re:The most important J2EE Bean of all (1)

Seb C. (5555) | more than 8 years ago | (#12297034)

May be you (and your co-worker) should take a look at Hibernate [hibernate.org] In my company, we are using something similar (well, same concept, just another implementation with less feature -don't shoot at me, i'm not to blame for that-) and the whole stuff performs quite well (so hibernate should perform even better, heh ;-) )

Re:The most important J2EE Bean of all (2, Interesting)

saden1 (581102) | more than 8 years ago | (#12297243)

We were one of the earliest adopters of Hibernate. In fact, we even took the Hibernate source code and altered it to meet our needs. Eventually we encountered complex problems that couldn't be solved with Hibernate and settled for iBATIS [ibatis.com] instead. We have to write our own queries but that's a given for any complex project. And I personally like the idea of placing your queries in an XML resource file. Perhaps this is doable with Hibernate now but at the time it wasn't.

Re:The most important J2EE Bean of all (1)

enomar (601942) | more than 8 years ago | (#12297169)

Servlets are a J2EE spec. I think by J2EE projects, you meant EJB based projects.

Fuck you all! (-1, Troll)

Anonymous Coward | more than 8 years ago | (#12296354)

Fuck you all you fucking slashfucks! You fucking stink and smelel because you don't wash and you don't use clean operating systems instead you wallow in linux lard getting fat and stupid so all you can fucking do is fucking laze about fucking choiking in GNU/semen posting on slashfuck all day! Fuck you all for being fucking retatded nerds with no life an that you are going to mid be down and thenm shove me up your arse!

Re:Fuck you all! (0)

Anonymous Coward | more than 8 years ago | (#12297532)

I have never seen anybody use the "F-Word" so many times in just three sentences.

Re:Fuck you all! (0)

Anonymous Coward | more than 8 years ago | (#12297696)

My favorite part was the poster's decision to censor the word "ass."

Re:Fuck you all! (0)

Anonymous Coward | more than 8 years ago | (#12297973)


It's funny because it's true! HAHAHA!

fp? (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#12296356)

w00t!

I'm confused (2, Interesting)

elid (672471) | more than 8 years ago | (#12296358)

How much of this book has to do with J2EE and how much has to do with software development in general? (What is XP doing in a J2EE book?)

Re:I'm confused (2, Interesting)

kin_korn_karn (466864) | more than 8 years ago | (#12296577)

Since moving to Java the main thing I've been doing is getting into arguments about what belongs in what object. As such, your message is either a very subtle play on OO pedantry or naturally ironic.

Let's pretend I'm smart. (0)

Anonymous Coward | more than 8 years ago | (#12296999)

It's the one of those that makes me seem most intelligible.

Dear god, the link (0)

Anonymous Coward | more than 8 years ago | (#12296378)

http://www.epinions.com/hmgd-Tools-Cordless-Drills _and_Screwdrivers-9-Black-Black___Decker_7_2v_Vers apak_Cordless_Drill_Kit_W_Keyless_Chuck

You can bet a java developer made that site.

Re:Dear god, the link (1)

DrJimbo (594231) | more than 8 years ago | (#12296881)

A Java developer would have said:

http://www.epinions.com/hmgdToolsCordlessDrills AndScrewdrivers9BlackBlackDecker72vVers apakCordlessDrillKitWKeylessChuck

Rapid J2EE development? Oxymoron? (-1, Troll)

Anonymous Coward | more than 8 years ago | (#12296400)

I've never witnessed a J2EE project that was completed on time or on budget. I'm serious. Moderators, start your engines.

Re:Rapid J2EE development? Oxymoron? (1)

iabervon (1971) | more than 8 years ago | (#12296572)

I've been in a J2EE project completed on time and on budget. We were smart enough to avoid almost all of J2EE and wrap the portions we had to deal with in sane interfaces. There is a bit of useful code in the Servlet section such that you don't have to write quite all of it yourself.

Re:Rapid J2EE development? Oxymoron? (2, Interesting)

micromuncher (171881) | more than 8 years ago | (#12296595)

If you woulda said any large project, I'd agree. But J2EE, like anything else, gives you a lot of rope to hang yourself with.

For example, a lot of n00bs think that any enterprise app should be using EJBs. The fekn reality is, most enterprise apps are 2-tier screaming out for POJOs and O_R Mapping tools.

So - it goes back to the quote - right tool for the right job.

So, uh (-1)

Anonymous Coward | more than 8 years ago | (#12296416)

Is this guy selling drills?

Rapid is a a bit of a misnomer innit (2, Interesting)

Timesprout (579035) | more than 8 years ago | (#12296448)

Enterprise Java is supposed to be big, complex and time consuming, that why its enterprise level where there are very few shortcuts worth taking.

RAPID J2EE?! (4, Funny)

C10H14N2 (640033) | more than 8 years ago | (#12296739)

Wait for the next book in the series: "Quick-and-Dirty Neurosurgery for the Doctor on the Go."

Geezuz.

Re:RAPID J2EE?! (1)

Tablizer (95088) | more than 8 years ago | (#12296775)

wait for the next book in the series: "Quick-and-Dirty Neurosurgery for the Doctor on the Go."

1. Get project
2. Offshore work to Indian doctor [washingtonpost.com] for $4/hr
3. Profit!

Re:RAPID J2EE?! (1)

MikeMacK (788889) | more than 8 years ago | (#12296832)

Yeah, the first thing I thought when I saw the title "Rapid J2EE Development" was: hey, what a cool oxymoron.

Re:Rapid is a a bit of a misnomer innit (0)

Anonymous Coward | more than 8 years ago | (#12297022)

Enterprise Java is supposed to be big, complex and time consuming, that why its enterprise level where there are very few shortcuts worth taking.

"Enterprise" means it is a big expensive pile of bloated, indirection-happy PHB crap. If you want to scale web apps, then simply buy a big-ass Oracle system and use the database for persistence and concurrency, not objects.

Jess is not open source (3, Informative)

bacchu_anjan (100466) | more than 8 years ago | (#12296450)

Hi There,

Even though Jess costs less, it is not open source and I'm not sure even if the source is available for the user.

I've used Jess and it's good but if you're looking for open source rule engine, the only real credible rule engine for Java is drools [drools.org]. I don't think that drools is anywhere near Jess (since Jess has been around a while and jess is compatible with CLIPS) but drools is the most promising one.

BR,
~A

Re:Jess is not open source (1)

mikew (22834) | more than 8 years ago | (#12296650)

Jess is most definitely not open source and must be commercially licensed even for use by an individual http://herzberg.ca.sandia.gov/jess/download.shtml [sandia.gov]:

"Note: Jess is not licensed under the GPL, the LPGL, the BSD license, or any other free software or open source license. Redistribution of the Jess source code under any free software or open source license is prohibited under this agreement."

Bees (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#12296475)

I hate bees. A bee bit me once, and it pains a lot. Trust me. Never go near a bee hive.
Noise. I hate noise. Fuck the noise.
I want to die. Life sucks.

Re:Bees (0)

Anonymous Coward | more than 8 years ago | (#12298016)


Put a bee in each ear, allow your ear canals to swell shut from the stings, and presto one-half of your problems are solved!

right tool for right job (0)

Anonymous Coward | more than 8 years ago | (#12296509)

And windows gives Microsoft money.

JAVA. DEVELOP FAST RUN SLOW (-1, Troll)

Anonymous Coward | more than 8 years ago | (#12296531)

Java == SLOW unless you have one of these [theregister.com]

Nothing new in here (1)

cowboy76Spain (815442) | more than 8 years ago | (#12296561)

5 years ago, when I was starting to work, some "big head" at my company read that the J2EE modularity meant that changes were easy to perform. Only that he did understood that that meant that no design was needed, because we just needed some quick code and if something did not work as expected, we could fix it later...

Right now I am the only one from the development team that has not left the company and the only one who dares to enter that damned project.....

Re:Nothing new in here (0)

Anonymous Coward | more than 8 years ago | (#12298781)

Only that he did understood that that meant that no design

What that fuck were you trying to say that?

Stiff little Fingers (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#12296570)

Stiff little fingers o\/\/nz J00 N33bs!

ColdFusion? (5, Interesting)

gik (256327) | more than 8 years ago | (#12296579)

I'm seriously not trying to start a flame war here, but I thought I'd recommend ColdFusion for anyone wanting to do quick J2EE stuff. Taking into Account that ColdFusion might not be some developers' favourite choice (due to cost, it not really being Java, fear, penis envy, etc), I think it's important to understand its strengths.

Using CF, you can develop quick & dirty web apps & webservices, talk directly to Java objects, and (starting in CF7) make your own EAR package and deploy it under any J2EE compliant server.

CF can run under most J2EE servers and as such supports advanced clustering, load balancing and the like.

Again, i know CF isn't for everyone, but I've found a real use for it at our shop. It's possible to deploy quickly, perform quick maintenance, etc.

NO, I do not work for Macromedia nor am I a fanboy. I'm just touting. :)

Gentlemen, start your flame engines.

Re:ColdFusion? (5, Funny)

Soko (17987) | more than 8 years ago | (#12296676)

I'm seriously not trying to start a flame war here, but I thought I'd recommend ColdFusion for anyone wanting to do quick J2EE stuff.

Suuuure, if we want closed, bloated technology that's controlled at the whims of a single company, as opposed to Java which... is....

Nevermind.

Soko

Re:ColdFusion? (0)

Anonymous Coward | more than 8 years ago | (#12297275)

I'm seriously not trying to start a flame war here, but why don't i just use mono?

Re:ColdFusion? (2, Interesting)

gik (256327) | more than 8 years ago | (#12297364)

go ahead and explain to me how exactly you plan on clustering a mono deployment.

try.

please.

Re:ColdFusion? (1)

pete6677 (681676) | more than 8 years ago | (#12296710)

ColdFusion would be a great development platform if only it weren't so damn expensive to (legally) run. It is very easy to use to develop great web applications, but the licensing cost is prohibitive in most cases.

Re:ColdFusion? (1)

gik (256327) | more than 8 years ago | (#12296753)

I agree with you 100%. The cost does suck. hard. However, you can develop for free to get acquainted to it.

It's great when my company pays for the licence.

In all seriousness, my company feels as though the time saved on actual coding is the driving benefit. This offsets the cost of additional developers and as such, the initially high price is cushioned.

It'd be great if someone wrote a CF -> PHP compatibility layer so that firms can migrate from the expensive CF servers. (actually an open CF server running on J2EE would be better, since it would support clustering properly... as php+clustering sucks ass).

Re:ColdFusion? (3, Informative)

orionware (575549) | more than 8 years ago | (#12297023)

Coldfusion will run on Windows, Sun, Linux, WebSphere. Code portability. When we cost out a project we will often cost it out in several platforms to ensure the best fit. There are different groups that define those costs. The coldfusion group is always about 50-75% of the cost of the .net/asp and always less than half of the js22/jsp folks (which only sometimes get the rfp).

Coldfusion is quick to develop in and as capable as anything else on the market today. Have the Java coders do some heavy lifting and the cf developers use those wars/jars in the cf app.

For those of you who haven't looked at coldfusion in several versions, it's quite different than it was 3-4 years ago.

Being more expensive?!

runs on linux = free
the standard license is $1200 bucks. The savings in development is often several times that cost.

Re:ColdFusion? (1)

aled (228417) | more than 8 years ago | (#12297318)

Interesting to note that Coldfusion is made on Java. From the Coldfusion FAQ:

"How does ColdFusion MX 7 run on other J2EE application servers?
The ColdFusion MX runtime environment is a Java application that takes advantage of the many powerful services in the J2EE platform to connect to databases, manage security, and process application requests. When ColdFusion MX 7 Enterprise Edition is installed in the J2EE configuration on top of a Java application server, it uses that server's J2EE infrastructure to execute ColdFusion applications as pure Java bytecode. Developers can then continue to develop and deploy ColdFusion pages while easily managing ColdFusion MX server settings using the ColdFusion Administrator."

Re:ColdFusion? (1)

mosabua (534503) | more than 8 years ago | (#12296760)

No flame.. just an interested question to an insider. How much longer do you think CF will be around after Adobe bought out Macromedia?

Re:ColdFusion? (1)

gik (256327) | more than 8 years ago | (#12296814)

I'm actually kinda scared... but CF is big, and it's quite old. It was kinda popular even 10 years ago (among lazy web coders, hehe).

Now that many CMS people and others wanting RAD are using it more and more, Adobe won't mess with it (If they know what's good for em).

Also, CF7 has some wicked pdf exporting & reporting support. I can only hope this will improve once Adobe gets their shitty fingers all over it.

My gut instince is that the biggest victim will be Dreamweaver here. I used to develop with Homesite back in the day. It's only disadvantage was its lack of a Mac port..hehe. Anyway, When Allaire (the guys who put out ColdFusion initially) got bought by Macromedia and Homesite was but on the backburner in favour of Dreamweaver, there was period of instability for CF developers who were told to use the new buggy CF features in DW. Even though DW is improving its CF support, I don't want this to happen again.

Re:ColdFusion? (1)

The Grey Clone (770110) | more than 8 years ago | (#12296815)

Does ColdFusion actively compete with an Adobe product? I don't believe it does, so it seems to me it'd be in their best interest to keep ColdFusion around, even if it's isn't THAT popular.

Re:ColdFusion? (1)

gik (256327) | more than 8 years ago | (#12296834)

I agree. Adobe has nothing to offer in terms of a server side application development environment.

yet.

Re:ColdFusion? (3, Informative)

MexicanMenace (673792) | more than 8 years ago | (#12296848)

FWIW, CFMX has been able to deploy EAR/WAR files since version 6.0.

Also, ColdfusionMX _IS_ Java. At version 6, they ditched the old C-based engine and built the new one in Java. You could say it's basically a custom tag library at this point.

Actually, you could say it's the BEST custom tag library for Java on the market right now.

I don't work for MM either, but when you can build a project in 150 hours using CF that was originally estimated at 1500 hours using another language, you tend to be a bit of a fanboy. :P

Re:ColdFusion? (1)

KenBot_314 (744719) | more than 8 years ago | (#12296948)

On your point of ColdFusion now being basically a custom tag library for Java, is anyone aware of any project to try to implement a free version of the coldfusion language?

would this even be possible, or would MM be able to stop it?

Re:ColdFusion? (1)

gik (256327) | more than 8 years ago | (#12296990)

It's a good question. I've thought about it alot. In essence, you could write an abstraction layer that does most of the stuff through PHP... That task wouldn't be EASY, but it could happen in a relatively short amount of time.

As for a Java implementation... One of the strengths of CF is its awesome Java support... very cross-platform, very clusterable, very standard, very extensible. This would all have to happen before anyone could take it seriously.

to answer your question... err... i dunno.
ha

Re:ColdFusion? (1)

fabu10u$ (839423) | more than 8 years ago | (#12297668)

I work in an all-ColdFusion shop and while it is great for small applications, once an application reaches a size where Model-View-Controller becomes a necessity, you're pretty much screwed. I'm trying to use their ColdFusion Components to implement an MVC app because the boss won't allow another language in our environment. Debugging is hell because there is no ColdFusion interactive debugger, so you either print a bunch of debug output on your page or step through their zillions of layers of indirection in a Java debugger.

Re:ColdFusion? (4, Informative)

tonejava (772709) | more than 8 years ago | (#12297753)

Coldfusion was rewritten to a set of Java tag libraries by Allaire (or was it macromedia?). So anyone using ColdFusion is using Java.

The only way cold fusion exists today is it's syntax - ultimately your programming JSP's.

Also considreing you can buy the CF syntax T-Shirt which has every tag on the front of the shirt upside down so you can just look down and find what you want. ;-)

Re:ColdFusion? (0)

Anonymous Coward | more than 8 years ago | (#12298055)


And with most slashdotter's bellies, the tag reference would already be conveniently spread out in front of them! A t-shirt for programmers, what a brilliant idea!

Read this book last year for Sun cert....my $0.02: (-1, Troll)

klipsch_gmx (737375) | more than 8 years ago | (#12296598)

This book has a lot of great material in it. The author really shows his experience in the subject matter. The content is excellent. The author provides a good survey of the technologies and approaches for rapid development in the J2EE arena. He touches on all areas that should be of interest to a reader, from design through testing. He illustrates the different phases of rapid development by going into several technologies in depth, and he also lists or otherwise mentions other available technologies. I would recommend this book to anyone looking to get started with developing J2EE applications.

I think the book does a good job of presenting a set of processes and technologies that enable rapid development. The author skillfully presents a collection of tools, technologies and processes that facilitate rapid development of J2EE applications. I see this book as a valuable addition to any company bookshelf, especially given its broad application across the software lifecycle. It's also quite amazing that a Google search does not reveal any existing publications with this title. This book should neatly fill that hole.

If you ever needed to put some polish to your J2EE development understanding or would like to move into the role of Senior J2EE Developer, then this is the book for you. The author covers everything you need to take you from design to coding to build process. Along the way he introduces some new valuable 'leading-edge' technologies. All this will leave you with good capabilities to tackle most J2EE projects confidently.

/., den of thieves (3, Informative)

Anonymous Coward | more than 8 years ago | (#12296752)

link [amazon.com]

"This book has a lot of great material in it. The author really shows his experience in the subject matter. The content is excellent. I haven't seen another book that is as comprehensive or contains as many real-world lessons learned."

--Madhu Siddalingaiah, Consultant, SEA Corporation

"I think the book does a good job of presenting a set of processes and technologies that enable rapid development. I think this is an extremely useful book, and I would recommend it to others."

--Satadip Dutta, Software Engineer, HP

"The author skillfully presents a collection of tools, technologies and processes that facilitate rapid development of J2EE applications. I see this book as a valuable addition to any company bookshelf, especially given its broad application across the software lifecycle. It's also quite amazing that a Google search does not reveal any existing publications with this title. This book should neatly fill that hole."

--Martin Westacott, Director and Senior Consultant, Solstice Software Limited, U.K.

"If you ever needed to put some polish to your J2EE development understanding or would like to move into the role of Senior J2EE Developer, then this is the book for you. The author covers everything you need to take you from design to coding to build process. Along the way he introduces some new valuable 'leading-edge' technologies. All this will leave you with good capabilities to tackle most J2EE projects confidently."

--Shane Griggs, J2EE Architect

That explains all my drooling (-1)

Anonymous Coward | more than 8 years ago | (#12296626)

I've been using a Philips head in my nose to scratch my brain. Note to self...

Lawsuit pending (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#12296689)

I fucked your dad.

Re:Lawsuit pending (0)

Anonymous Coward | more than 8 years ago | (#12298067)

That wasn't my dad, you idiot, that was my toaster!

Rapid for J2EE (3, Funny)

null etc. (524767) | more than 8 years ago | (#12296691)

Keep in mind that time is relative.

A "rapid" J2EE project is probably about 8 months long.

A "rabid" J2EE project, on the other hand...

Methodology Schmethodolgy (5, Insightful)

micromuncher (171881) | more than 8 years ago | (#12296721)

/rant on
Why why why why why to books on rapid enterprise development cover methodologies rife with process and reading-knowledge experts?

Once upon a time we did something called "rapid prototyping". It worked for most enterprise apps where clients and analysts didn't know their a-holes from their L-bows. Then we were told that "iterative software development is programming by trial and error ... define a process". So some attempts at introducing order to chaos comes up with mounds of formal methodologies that somehow become RUP.

Then there is a total rebellion by the artists and untrained IT masses, who instead of blaming middle managers with NO expertise architecting, designing, requirement gathering, that instigate zillions of Death Marches - we get peer programming - that pushes back-seat-driver development coupled with accountability (decrease in hours playing Solitaire.)

Somehow more unrest leads to test driven development where you don't try specify every little detail but have a big picture and manage risk (Agile).

Guess what. We're right back to iterative development! But now we got all kinds of fancy labels to attach and heroes to worship.

Common sense and been-there-done-that became Design Patterns.

CR became Programming by Contract.

And all this while the big companies we work for are hell bent on outsourcing us all because "You IT/IS types consistently screwed up projects for years... so we'll give it to someone who knows better [in 3rd world country of choice.]"

The point of my rant?

The best rapid development process is done by experienced people, not by process.

Process doesn't write programs. People write programs. /rant off

Re:Methodology Schmethodolgy (1)

mccalli (323026) | more than 8 years ago | (#12297113)

Standing ovation from me at least. But then what do I know, I've only been doing this stuff for fifteen years...

Cheers,
Ian

Re:Methodology Schmethodolgy (1)

Retric (704075) | more than 8 years ago | (#12298168)

As I see it.

To get stuff done projects need Good People. Good People cost lot's money and are in short supply. But, instead of limiting the projects scope and using "Good People" companies try to find ways to use / manage less knowledgeable people. This seems to work for a while until projects stall as the amount of manpower it takes to get anything done increases exponentially. At which point the project either fails, or act's as a somewhat working demo for the next project. See Windows ME > Windows XP ect ect.

How does Windows XP even get written (1)

Latent Heat (558884) | more than 8 years ago | (#12298403)

How does a piece of bloatware like Windows XP even get written (disclaimer -- I am generally comfortable with Windows and not a flaming anti-MS person, but a person has to admit that XP is, well, pretty big)?

I don't mean from a process standpoint and PERT charts and waterfall diagrams and all of that. And I can understand things that at least started out as one-man operations for gifted persons (Cray computers, Linus and Linux, etc). But even if there is a head XP guy who has a roadmap, the dude has to farm out much of the coding to a vast army. How is that army organized?

Or maybe I have it all wrong -- maybe the Windows kernel is pretty compact and that much of Windows is built up out of apps -- you are responsible for this app, you are responsible for this other one. Even if the coders all work from detailed specifications, someone has to write the specifications, and I don't know if the specifications for that much code can fit within the span-of-control of one person let alone a small committee.

I will concede that Windows is a POS, but how does such a POS even boot?

XDoclet? (4, Informative)

EricTheGreen (223110) | more than 8 years ago | (#12296731)

Not that any book can cover every useful J2EE tool out there...but leaving XDoclet out, particularly in a book aimed at improving J2EE development time, would be a baffling omission.

I've worked with most of the other tools mentioned in the review and they're all good. But nothing helped speed my own J2EE work more than XDoclet, particularly with EJB's and all their interface definitions, configuration files and container-specific instruction files.

Re:XDoclet? (0)

Anonymous Coward | more than 8 years ago | (#12298804)

but leaving XDoclet out

Except the only book I know about, XDoclet in Action, blow chunks. Its just a reprint of the online docs with very few examples. That's what I buy the book for, so that the authors can walk me through a well thought out example and show me each individual step.

Its the worst of the In Action books, all of the rest of them are pretty good.

keep the basics (1)

Mariani (700617) | more than 8 years ago | (#12296741)

Don't focus too much on tools when it comes to planning the development of a J2EE application. I learned some lessons about this the hard way.

A well setup environment is a must in this kind of development and tools like the ones this book evolves around can put the pedal to the metal when it comes to accomplishing your goals.

BUT bear in mind that you ALWAYS need to keep a close eye on the basic structural requirements, especially the services used in the process of the application you're developing.

For instance, choosing persistence framework X because it worked wonders for everybody making a similar app and had plugins for IDE Y and would speed up development will cost you much more time than you saved if the queries it generates for your(!) needs in your(!) situation suddenly drown the database.

System engineers know all about those projects, if you knonw what I mean.

J2EE has got it all wrong. (0)

master_p (608214) | more than 8 years ago | (#12296748)

I thought I was the only person complaining about J2EE, but I have recently discussed it with a colleague of mine, and he held the same opinion:

1) J2EE is JSP tag/XML hell.
2) most frameworks are only bareable from a software engineering point of view.

So we sut down and made our own Web Application Toolkit (TM), that has the following capabilities:

1) the GUI is written as Java classes, ala Swing. The classes render themselves into HTML. We used the HTML XML schema to automatically convert the the HTML protocol into Java classes. The next iteration will also have programmable Javascript with Java (in other words, Java classes will be used for making Javascript code that interacts with the client).

2) the GUI is fully Model-View-Controller. Unlike what you have heard, J2EE (i.e. Struts) is not MVC. MVC implies a view which renders a model and the model changes automatically. Views must be observers of models. In our toolkit, a submitted page automatically fills the view that created it, and then the view automatically fills the model. Then the model updates its observers. Each page consists of a triad of classes: a model, a view (the actual page) and a controller (the business logic). The toolkit makes sure every user gets one instance of each page, i.e. one instance of each part of the triad of model-view-controller. The instances are created on demand (i.e. when the request is done), and removed after inactivity for a user-defined amount of time. A Controller class controls routing to the next page according to business logic. Command buttons are used to invoke events in the server instances, which are connected to controllers.

3) the toolkit makes sure that an HTTPS request is indeed an HTTPS request. When an HTTP request is done with a URL that has been installed as an HTTPS, redirection to HTTPS is automatic.

4) static parts of pages can be shared by all classes through a static view instance. After all, the HTML is simply a string concatenation provided by the 'toString()' method for each GUI class.

5) a main servlet class does all the routing. The programmer must have to subclass the server class, then register all pages (i.e. MVC triads) with URLs inside the constructor; then the servlet automatically handles the browsing and navigation.

6) on the design front, we have made an XML script that converts an HTML 4.0 page to a View-derived class ready for being used in our application, therefore allowing the designers to work independently. Then the programmers can subclass the view class and connect it to the model. In this way, design of the page and its programming have become completely indepentent.

With all the above, we have minimized Web application development by 90%. Before this, web applications took days to be written. After this, all our programmers see JSP/XML and start running.

(and since the toolkit is about to become a product, forget it being open source; sorry!!! :-) ).

Re:J2EE has got it all wrong. (5, Informative)

Anonymous Coward | more than 8 years ago | (#12296769)

Congratulations, you've invented Java Server Faces.

Re:J2EE has got it all wrong. (1, Informative)

Jason Hood (721277) | more than 8 years ago | (#12296858)


Unlike what you have heard, J2EE (i.e. Struts) is not MVC

That doesnt make any sense, Struts has nothing to do with J2EE or MVC. J2EE is a spec. Struts is an implementation.

Pardon my ignorance.... (0)

Anonymous Coward | more than 8 years ago | (#12296974)

But if a specification and an implementation are unrelated, wouldn't that be something of a problem?

Re:Pardon my ignorance.... (3, Insightful)

BigGerman (541312) | more than 8 years ago | (#12297366)

Poster you, mr. Coward, replying to was not correct: Struts is NOT an implementation of anything J2EE. Struts is how-its-developer-saw-it implementation of MVC pattern/principle.

Re:Pardon my ignorance.... (1)

tonejava (772709) | more than 8 years ago | (#12297812)

Ummm.. it extends on the servlet API, adds JDBC connection pooling, uses JNDI, ... so I do think it rightly implements J2EE.

Re:Pardon my ignorance.... (1)

BigGerman (541312) | more than 8 years ago | (#12298038)

no, as OP said J2EE is a spec. It describes how things should behaive to be considered J2EE: servlets, JSPs, EJBs, JMS, ...
J2EE "container" (application server) implements J2EE spec fully or partially. Struts does not implement any portion of J2EE spec.

Re:Huh? (0)

Anonymous Coward | more than 8 years ago | (#12296872)

J2EE

"You keep using that word. I do not think it means what you think it means."

Re:J2EE has got it all wrong. (0)

Anonymous Coward | more than 8 years ago | (#12297201)

Hell, that sounds like Swing developper band coming in in the Web/J2EE space.
J2EE itself does not define how you should write it, and JSP can makes wonder, if used correctly...
First, split all your pages in 2 (the first including the second).
The first pages will be our controler. It's only scriplet and does nothing but interact with your 2nd-tier application stuff, set data within session/request, and controls your application flow (redirection). It also includes the second one. That is your controler.
The second one is the html, salted with jstl (jstl is will work for 95% of your data displaying needs)
That is your view.
Now, you got a MVC. the controler and the view are jsp, which means you can change them and see result without restarting your server (_THAT_ is valuable)
You can even write your controler as a java class and use some scripting language to transform them into a valid jsp controler. (So that the code you write can be checked within your IDE -eclipse anyone ?- before being compiled by your j2EE container (jsp syntax errors are pain to check out : lines always wrong, etc...)

But anyway, as one said in a comment on that article, it's not method or tools that makes you efficient, it's experience. And if you feel like home within your framework, just stick with it...

Enterprise Java has already been (1)

WillAffleck (42386) | more than 8 years ago | (#12297045)

cancelled and relocated to film production in Canada, where they brew it dark and hot.

To hell with J2EE (5, Interesting)

Anonymous Coward | more than 8 years ago | (#12297387)

To hell with J2EE, it introduces more problems than it solves.

Let's look at persistence:

Once upon a time there was EJB 1.0 and 1.1, and every change required touching about a dozen files. Along came EJBDoclet (later XDoclet). EJBDoclet helped the world deal with EJBs, reducing the number of files you had to touch to 1. As such, the tool was invaluable. It also teaches a lesson: anytime you come up with an API that requires a new tool to make using that API bearable, your API sucks.

Sun saw that EJB 1.1 sucked rocks. Along comes EJB 2.0, in which they don't fix the configuration nightmare and introduce a half-assed query language to supplement the collosal folly that was the ejb finder method. With 2.0, EJBs were still fucking slow, CMP still didn't work right, and peopl had had enough. It didn't help that EJB 2.0 was about 2 years late.

New persistence tools started to gain traction, such as JDO and Hibernate. JDO was a bit too close to home for Sun though, and it got shit on. Miraculously, Hibernate held on and became bearable.

Now the best-practice persistence mechanism isn't part of the J2EE spec. So much for EJB and JDO. Some crazies (me) still argue that filling out reams of XML config files to create your O/R mapping is bloddy stupid and almost as bad as writing SQL to do the work, and therefore something should come along that hides the entire fucking database from the developer, bullshit or mapping files and all. But that's just me. (Yes, that's not always feasible for attaching to legacy databases. Eat a dick).

Ok, so we're satisfied that the J2EE persistence story is a fucking mess. Next up: UIs.

JSP. Let's embed Java into the HTML. Now the developers and the web weenies can shit all over each other's work. While we're at it, let's not include any way to do common things like pagination, alternating background colors in table rows, etc.

Enter taglibs, which attempt to solve these problems at the cost of having to write zillions of little snippets, put them some place, compile them into the JSP at runtime, and hope your web developer didn't fuck over the page again. Hmmm, no go. Did I mention JSP is slow?

Approximately 92 million tools of one sort of another sprang up to supplement or replace JSP. Most of them sucked, and some of the worst (I'm talking about YOU, Struts) rose to the top to become de-facto standards. So now we have servlets - which work pretty well, thankyouverymuch - mutated into some sort of bastard offspring of Swing that try to and succeed in getting in your way whenever possible. Now the best practice is - no joke - to do everything in servlets, which is the way it should have been done in the first place.

So that's the UI side of things. Notice there's no J2EE solution for thick clients, because God forbid someone want to cache something on the client. Plus Sun knows what a fucking piece of shit Swing is. And I'm not going to mention portlets.

That leaves us with JMS, which works primarily because the architecture + implementation were copied from existing messaging systems. JNDI, which annoys everyone anytime they go near it. JCA, which kind of works assuming the AS/400 is in a good mood that day. Probably a few other minor bits + pieces too. The core of J2EE was EJB though, and that was the fuckup to end all fuckups. You're much better off doing shit on your own, and not listening to Sun.

Why is there a chapter on UML? (4, Insightful)

wheelbarrow (811145) | more than 8 years ago | (#12297514)

Does anyone on Slashdot really use UML to document a design? For those of you that do, how many of those pretty UML diagrams were blessed by a comittee, filed, and then forgotten?

Re:Why is there a chapter on UML? (5, Informative)

tonejava (772709) | more than 8 years ago | (#12297855)

We used UML to design our last 2 projects with the model put up on the wall for reference.

How does this object relate to that object? Have a look at the model.

What tables are affected by changes to this class? Have a look at the model.

Which classes are affected by changes to this table? Have a look at the model.

From the model we generated Java source code, Hibernate mappings, SQL DDL's for tables and used it in correspondence with an overseas branch for clarifications on process flow.

The only committee that the model was blessed by was the development team. Higher business has no understanding of UML so why should they have anything to do with it? Any flow/model diagrams used in requirements gathering should be basic and understandable NOT technical.

So no, our model was not forgotten and we are still updating it today as required for new projects.

Re:Why is there a chapter on UML? (1)

wheelbarrow (811145) | more than 8 years ago | (#12297990)

That is an interesting response. How many times per year do you release your changes for deployment to your customers?

Re:Why is there a chapter on UML? (1)

tonejava (772709) | more than 8 years ago | (#12298656)

Our update deployments happen probably once every 5 months as new features are added.

The core model applies to most if not all our projects as it defines the core requirements of the business.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...