Slashdot Mirror
Rapid J2EE Development
"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.
Is it.... Yes, it's all the buzzwords! A giant swarm of them!
Spring is a must-know-about thing for potential readers of this book, IMHO
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?)
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.
Enterprise Java is supposed to be big, complex and time consuming, that why its enterprise level where there are very few shortcuts worth taking.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
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. 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
And windows gives Microsoft money.
Moderators? Yup, we hear you. oh wait...
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.....
Why can't
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.
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.
ZERO
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.
/\/\icro/\/\uncher
Since we're talking about hammers and screwdrivers, I would think this comic would be appropriate. :)
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
A "rapid" J2EE project is probably about 8 months long.
A "rabid" J2EE project, on the other hand...
Null Pointer Exception in books.java.javacompilerissatan.viewbookcover.java
The Peanut Gallery, Ubergeek, Biblically Sober
NCAAbbs.com: Thousands of fans, Hundreds of teams, Just one place
/rant on
... define a process". So some attempts at introducing order to chaos comes up with mounds of formal methodologies that somehow become RUP.
/rant off
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
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.
/\/\icro/\/\uncher
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.
Wait for the next book in the series: "Quick-and-Dirty Neurosurgery for the Doctor on the Go."
Geezuz.
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.
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!!!
link
"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
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.
J2EE
"You keep using that word. I do not think it means what you think it means."
But if a specification and an implementation are unrelated, wouldn't that be something of a problem?
It's the one of those that makes me seem most intelligible.
cancelled and relocated to film production in Canada, where they brew it dark and hot.
Will in Seattle
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.
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?
I have never seen anybody use the "F-Word" so many times in just three sentences.
My favorite part was the poster's decision to censor the word "ass."
It's funny because it's true! HAHAHA!
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!
Many J2EE teams use eXtreme Programming. What are you confused about?
That wasn't my dad, you idiot, that was my toaster!
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?
kthnxbye
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
...and PHP does both even better.
dry water, hot ice cubes, quick snails and miniscule skyscrapers.
think .NET its far superior, spam away.
Ouch, that was cynical. The truth hurts...
"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."
;-)
Actually, it applies to all tool use.
Getting to a VAR Agreement with NewAtlanta, they licence you BlueDragon J2EE server for 20% of your list product price.
So if you are selling your product/development for $5000 you can have a BlueDragon J2EE server for $1000, develop in cfml at the speed of light and deploy using EAR/WAR.
Also, you can go for the free version [ bottom of the page ] non J2EE server.
There are also more companies making cfml engines.
We use Enterprise Architect - and even though we are too cheap to buy the full featured version - it gets the job done and we access it daily.
We point others (PM's and other dev groups) to it and they seem to have no problem interpreting it.
And we dont' have any committee's blessing it - it is written by development for the development process.
What it does need, is better tools. Then again, my company is too cheap to buy Rational or some other integration tool. A EA -> Eclipse plugin would be ideal.
I also suppose that the best model for software reuse to date is where features are part of a language or a standard library (STL lists, Python hashlists) rather than some dude in the Visual C++ parser team developing a regular expression tool and supporting its use across Microsoft.
Model-Glue: MVC for Object Oriented CFMX
MVC with Fusebox
MVC with Mach-II
And if you're using CFMX J2EE: Streamlining Application Development Using Struts in ColdFusionMX
What kind of problems are you having?Re MVC and ColdFusion there are two popular OS CF frameworks out there that are based on the MVC pattern: http://www.fusebox.org/ for an approachable non-OO that provides IOC and some separation of business logic and views. http://www.mach-ii.com/ for a more oo implicit invocation events and listeners take on MVC. Cheers.
Back in 2001, a friend of mine undertook replicating Coldfusion tags in Java. He had a good start, but due to a PHB, we were instructed to NOT use tag libraries in the J2EE product we were developing.
.NET, which co-operates with .NET components the way the J2EE version co-operates with pure Java components.
.NET version is something MM most likely won't attempt.
Thankfully that decision was overturned 8 months later, but by then an Open Source CFML engine was well underway and Struts, the JSTL & their like were proving their worth.
That Open Source CFML engine later became New Atlanta Software's BlueDragon.
They have 4 versions:
Server - free even for produciton, but not for redistribution
JX which is equivalant to Macromedia's Pro version.
J2EE ~ MM J2EE
and
However, their version does not 100% match Macromedia's feature for feature, but the majority of the core functionality is there and they're constantly adding to their offerings. And the
So it's possible and they can't stop it. There's even yet another CFML engine out there. I just don't know of anyone using it.
ColdFusion Adobe, sound like a cold excrement! What kind of genius would pay $3Bill for a Flash and ColdFusion.
Flash is good for building bloated dotcom websites and clogging it with bs grafix. As far as ColdFusion...
wake up guys... you can get a ColdFusion clone for free (http://ignitefusion.com/).
Meantime I'm watching by Adobe stock take a dump...
duh...