Follow Slashdot stories on Twitter


Forgot your password?
Programming Books Media Book Reviews IT Technology

Server-Based Java Programming 48

Craig Pfeifer wrote this review of Server-Based Java Programming, and in a world of books loaded with buzzwords, and sometimes volume at the expense of clarity, he claims that this volume suffers neither fault. (Even if you're sick of the word "Enterprise.")

Server-Based Java Programming
author Ted Neward
pages 556
publisher Manning
rating 10
reviewer Craig Pfeifer
ISBN 1884777716
summary From designing and building the nuts and bolts of your own java application server, to understanding and integrating common middleware technologies and patterns, this book covers it all.

The Scenario

Whether you're building your own Java application server, or evaluating your options when it comes to building an enterprise class application, there's an awful lot to consider. Everyone likes to throw around the adjective 'enterprise'; 'enterprise class,' 'enterprise information system,' 'enterprise solution' but what does this mean? What is an enterprise solution? And more importantly how do you build one? This book cuts through the J2EE hype and gives you the straight dope on desiging/implementing realistic java based distributed systems.

What's Bad?

If you are looking for a Java2 Enterprise Edition (J2EE) overview (Enterprise Java Beans (EJB), Servlets, Java Server Pages (JSP)...) or an intro to Java fundamentals, this book is not for you. This book covers some fundamentals of threads, classloaders and sockets, but the bulk of the text is the application of these concepts. If you aren't already familliar with how these features are commonly used, you might find yourself doing a little prerequisite work to get the full value out of the material in these chapters.

Additionally, several code samples span multiple pages and it can be tough to keep this sample (along with all of the previous samples, as they build on each other) in your head when you read it in more than one sitting. This could be remedied by presenting a series of UML diagrams to show how the current example extends or interfaces with the previous examples, and the existing classes in the Java SDK.

What's Good?

This book goes from narrow to broad in it's coverage of different aspects of enterprise systems. Ted starts off chapter 1 with a wonderful overview of what characterizes 'enterprise development,' and 'enterprise systems.' According to Ted, enterprise development projects:

  • get less QA time
  • have shorted development cycles
  • typically require expert administration
  • must work within an existing architecture

From here, he goes into a discussion of key build vs. buy decision criteria and a justification/defense of using Java on the server side. This first chapter should be torn out and given to every development manager in every internal IT department in every company everywhere. Many managers feel that any project dealing with 'enterprise' and 'java' require a product like IBM's webSphere or BEA's webLogic, but this is simply not the case. These are excellent products, but for most of the projects out there, basing a solution around a full blown J2EE appserver only makes building, deploying and maintaining the system more far more complicated and expensive that it really needs to be.

Just as I started to worry that this book would be all talk and hand-waving, the next two chapters (approx 60 pages) were a gloves-off, down and dirty discussion of Java's classloader functionality. Many developers take the classloader for granted (including myself), and don't fully understand/exploit its power. Ted shows all of the rules that a Java classloader must follow, and the role it plays in the application lifecycle. He builds sample classloaders that can load classes from an HTTP server, an FTP server and even from an internal hashtable. The most impressive part of these two chapters is Ted's explanation of how the differences between the Java 1.1 and the Java2 classloader. This illustrates Ted's depth of the Java platform, and is just one example of the knowledge (not just information) that this book is chock full of. Ted's sample classloaders are the foundation of the Generic Java Application Server (GJAS) that you build as you progress through the book.

In the next few chapters Ted takes on his two other major topics for the book: threading, and sockets. These topics are worthy of entire books on their own, but Ted keeps it focused and talks primarily about how they are applied in the context of an enterprise application server. He doesn't just rehash the threading and sockets APIs, but provides common usage patterns for each and even provides implementations for useful new primitives. Some of these primitives include an implementation of a PollingThread, a ScheduledThread, an HTTPSocket and a SocketServer. For all of the examples in the book, Ted lets you in on his design process as the GJAS evolves. He lays out the alternatives, makes a selection, and then justifies it. When he applies design patterns from the Gang of Four (GoF), he tells you why he is applying that particular pattern, and how it solves the problem at hand. This is the core of this book, and it's strong point.

Interspersed in the threading and sockets chapters are about server configuration and control structures for services that get executed on the server. Ted discusses different implementations of user services running in their own thread (so as not to interrupt other processes on the server), and in doing so makes use of the thread primitives he laid out in a previous chapter.

The later chapters are typical server programming fare: business objects, business object models, persistance and middleware. However, Ted covers them in a style consistant with the rest of the book: copious code examples, design justifications, and years of valuable on the job experience communicated in a scant 160 pasges.

So What's In It For Me?

As a Sun Certified Java 2 Developer, I've read more than my fare share of bad java books. The good thing is that they are very easy to spot: they are typically extremely thick books with trivial examples and a huge API reference (that you can download from Sun's Java Developer Connection) for filler. This book is a voice of reason in Sun's flood of J2EE (especially EJB) hype. It's a wholly remarkable Java book. Ted Neward should be rewarded and congratualted for this book, it sets a new standard in content quality for Java books.

Based on this book, and the review of the Manning Swing Book, Manning now ranks right up there w/O'Reilly in my list of top-quality technical book publishers.

Table of Contents

  1. Enterprise Java
  2. ClassLoaders
  3. Custom ClassLoaders
  4. Extensions
  5. Threads
  6. Threading Issues
  7. Control
  8. Remote Control
  9. Configuration
  10. Sockets
  11. Servlets
  12. Persistance
  13. Business Objects
  14. Business Object Models
  15. Middleware
  16. Java Native Interface
  17. Monitoring

You can purchase this book at Fatbrain.

This discussion has been archived. No new comments can be posted.

Server-Based Java Programming

Comments Filter:
  • by Anonymous Coward
    Java isn't slow, it's the JVMs that are. A PhD student before me wrote a java compiler for native SPARC code, most programs where a lot faster when compiled with his Java compiler than what GCC managed to produce with plain C/C++. Maybe it's just GCC that sucks, i dunno.
  • Even if it looks like to wrong choice to me sometimes, I trust them, because they know a lot more about that stuff than I do.

    I worked for

  • by djweis ( 4792 ) on Thursday May 03, 2001 @07:20AM (#248456) Homepage
    No, it's not JSP for dummies, but it gets into just about all of the complicated topics that no other book so far covers. It was a bit pricy ($49.95) but definitely worth it. The chapter on Modeling is also useful and is something that is missing from the other Java books I have.

    I also liked Java Enterprise in a Nutshell from O'Reilly. Previously, there wasn't anything about the more complicated server-side Java topics, just how to use awt/swing/applets. Between these two books, you can learn a lot.

  • by perle ( 5354 ) on Thursday May 03, 2001 @07:03AM (#248457)
    You don't have to license anything to build a JVM
    or a Java compiler or a J2EE server or servlet
    container or EJB container or Jwhathaveyou.

    There is an open spec. Now run along and implement.
  • I guess it's a good thing FatBrain [] has it for the same price then...
  • There's only one thing you realy need to know aboutr JSPs:

    don't use them!

    Trust me on this one. Servlets good, JSPs bad.
  • I take it you don't work much with designers then?

    I do. But JSPs don't make that any easier.

    I thought jsps just compiled to servlets anyway- what is the problem there?

    I've sure one could write a befunge to Java compiler too, but you probably don't want to write your servlets in befunge.

    I would love to trust you on this one, but you haven't supported your argument very comprehensively here.

    Hmmm, if I told you it was bad to stick a pencil in your eye would you be so skeptical...? :-)

    JSPs have numerous problems, but what it boils down to is this: they're a maintenance nightmare. They don't support any real modularization (beyond include), you can't compile them at build time (if anyone knows otherwise, let me know), they remove the ability to do certain things (like sent the output encoding dynamically), they suck rocks for trying to do i18n, and they make it way too easy for people to insert actual Java code that should be in Java files, not JSPs.

    If you don't believe me, go ahead and use them for a large project. But don't say I didn't warn you.
  • by ch-chuck ( 9622 ) on Thursday May 03, 2001 @07:16AM (#248461) Homepage
    I run ours, and fill it up with 3 heaping scoops of Kirkland 100% Columbian supremo bean dark roast fine grind, 10 cups of water, and program the timer every night.
  • by MSG ( 12810 ) on Thursday May 03, 2001 @10:16AM (#248462)
    volume at the expense of clarity, he claims that this volume suffers neither fault.

    It's early, and when I read this, I thought he meant that the book had neither volume nor clarity.
  • by Manes ( 17325 ) on Thursday May 03, 2001 @07:39AM (#248463)
    Amazon [] got it listed for $39.96 now
  • by rw2 ( 17419 ) on Thursday May 03, 2001 @06:54AM (#248464) Homepage
    I've been a pro for better than a decade and an amateur for another decade before that. Let me tell you that the biggest problem in corporate development today isn't whether or not people understand J2EE, but whether they understand distributed idioms and business.

    I can't tell you the number of times that I've had to help folks who had memorized the spec and read books like this, but didn't understand why the spec contained the features it does, nor why going distributed was the way to go (hint, $).

    So, read this book. Learn everything it contains. But don't skip the more academic architectural tomes nor the business aisle the next time you're at Borders...

    Poliglut []

  • by rw2 ( 17419 ) on Thursday May 03, 2001 @07:21AM (#248465) Homepage
    I don't care *why* management chose to go down a certain path. Even if it looks like to wrong choice to me sometimes, I trust them, because they know a lot more about that stuff than I do.

    I'm not saying that you should not trust them. I'm saying that you will be better at *your* job if you understand them.

    Nor am I saying, as you mention, that you shouldn't focus on the specs. Just that you shouldn't focus on them to the exclusion of other, admittedly less interesting, subjects.

    How many times have things needed to be re-worked in projects that you have worked on because of miscommunication? In many cases that can be eliminated because you better understand the business perspective and can ask better questions. And, frankly, that seems a lot more likely than that we'll convince the business types to learn enough about what we do to give better instructions.

    Poliglut []

  • Now why would I want to rewrite sprintf() in Java when I have something way more powerful like NumberFormat or MessageFormat? sprintf() was great when I was about 8 years old... Nowadays my message formatting needs qre quite a lot grander.

    Also, I can't really see where you have a problem with using StringTokenizer() instead of split().

    I find the docs have quite a few good working examples for the tricky things (moreso than man pages for C functions). And if the docs do fall short, in about four seconds of web searching you can find so much example code you would be amazed. In fact the problem is an embarassment of riches, or perhaps just an embarassment depending on what code you find. But, at least it's an eample!
  • Yes, longer. For common things I have abbrevs set in Emacs, for instance I could type "split" and have that replaced with StringTokenizer().

    Personally though my style is to writePrettyVerbosley. I tend to copy a lot of text and use registers in Emacs for common things, so the length doesn't get in the way - and it makes it a lot more readable.

    I'll agree with you on the not nessicarily better or worse, I just prefer a little more verbosity and find that you get used to it and the extra length does not really matter... Since you can sometimes spend hours reducing something you are doing to a single line of code, why bother trying to shorten the characters used in that line? That's what I think coding is really all about, getting rid of code you have rather than worryng about how many characters are there to start with. It's just as easy to delete StringTokenizer() as split().

    It's all about writing a boulder and then carving a fine statue - and even if you just set out write a statue you always find you end up with a boulder anyway!

  • For the first thing:

    List aList = new ArrayList();
    StringTokenizer st = new StringTokenizer(delimitedText,",A");
    while( st.hasMoreTokens() )
    aList.add( st.nextToken() );

    Of course, you could write that into some kind of static string helper class and then just say:

    List aList = StringHelper.tokenizeString( delimitedText, ",A" );

    which is what you'd do if you were having to use StringTokenizer often.

    A side note is that StringTokenizer also offers somewhat more flexibility than split() as it can change the delimiters on the fly for each token (though I'll have to admit I can't think of a good case where I would use that!).

    I am aware of the 10 billion Java sprintf() implementations. I think there are two reasons - the first is that C programmers new to Java don't yet have the idea down of browsing the Java libraries to look for features they need, the other is that some might be trying to port old C code and to make that easier you might well want a good Java sprintf(). I myself have had no need or desire for sprintf() in Java.

    Ruby looks interesting, but for the moment I find Java a lot easier to use than just about anything. It's really a matter of knowing the libraries pretty well, then just about anything you want to do is easy.
  • Hey hey.. wait a minute!! I didn't diss Perl, nor did I mock it or any of the uses for it. I was just questioning the original authors statement about how Perl is/has been an example for other languages (a model for them). Personally, I can't think of any language that would have been influenced heavily by Perl.

    In a completely separate point, I was asking if my feelings about Perl actually being used less now than it was used 3 years ago are correct. What I mean is, rather than being a great example that everyone is following, Perl is actually slowly fading away from the position it once had.. I could be wrong, but that's the feeling I get..
  • by macpeep ( 36699 ) on Thursday May 03, 2001 @07:38AM (#248470)
    There's a reason why there are so many Java books in the bookstores. The reason is that Java is extremely popular right now for server side programming and there is a demand for those books. The people on Slashdot that say that Java sucks have mostly little or no real experience with JDBC, EJB, JSP, RMI etc. and are just basing their view on Java applets coded by some "programmer" at a web concultancy, holding "Teach Yourself Java In 21 Days" in his left hand. Yes, those suck. Yes, those are slow. The fact of the matter is that Java is clearly fast enough for what it's being used for - that's why it's so popular. Java is in the same ballpark with Perl when it comes to speed (there are lots of benchmarks proving the superriority of either of these, and most of these benchmarks are ridiculously flawed and one-sided) and obviously, Perl is also "fast enough"; case in point, Slashdot.

    As far as "easy" vs. "hard" goes, I don't think that Java being hard is a point against Java - quit the opposite, Java is usually perceived as being a relatively easy language, mostly thanks to garbage collection and all objects being passed by reference (contrary to what you often hear on Slashdot about Java not having pointers - it has nothing BUT pointers, except for primitives). Too much like C++? C++ with an option for garbage collection and a strong and balanced standard library would be - to me - an ideal language so I'm not sure I understand your point there..
  • by macpeep ( 36699 ) on Thursday May 03, 2001 @07:11AM (#248471)
    Java and Perl will be the basis of most programming languages? Java maybe - C# proved that, but Perl? I may be wrong but the only place that Perl has really ever been REALLY strong (yes, it's used for scripting stuff by system admins but I'm talking *REALLY* widespread and serious mission critial use) is for CGI on web servers. There, Perl has traditionally been extremely strong but it seems to me that lately, ASP, PHP and especially Java servlets and JSP is eating up that advantage. If anything, it seems that Perl is losing "market share". Does anyone have any stats to show if my feelings are right/wrong?

  • I've tested gcj as native compiler for Linux, not only did the app run faster, but the resource usage was remarkably lower as well. What I'd like was ability to manually tweak parameters for hotsport enabled JVMs. They compile to native code runtime, but only as far as their internal logic allows them.

  • by selectspec ( 74651 ) on Thursday May 03, 2001 @07:38AM (#248473)
    attention brave soul (or fool):

    Write a book that covers all web-middle-tier-to-database application arcitectures in detail. Include everything from mod_perl, python, java servlets, EJB, jsp, asp, COM+, C/C++. Tackle ODBC, JDBC, OCI, etc. Give a pro/con on all of the above in detail, and get it out the door in 6 months before it all changes.
  • Sun One. (No, really that's the name of the Sun initiative to stop .Net)
  • I thought we were boycotting [] Amazon ;)
  • free market and all that

    Interesting argument, considering that the reason for the boycott was that Amazon is impairing the free market ;)
  • by holzp ( 87423 ) on Thursday May 03, 2001 @07:10AM (#248477)
    were they trade schools? if you are looking to get a degree in the Science of Computers, you should be asking if they have an "Operating Systems" course or "Networking Theory." If they teach you a language (as opposed to language design) you would be lucky. If you want a degree on how to apply the theory go to ITT Tech or spend your nights hacking in your dorm. Colleges and Universities for the most part teach Theory. Esp as an undergrad.
  • I run ours, and fill it up with 3 heaping scoops of Kirkland 100% Columbian supremo bean dark roast fine grind, 10 cups of water, and program the timer every night.

    Coffee/Java jokes are SO 1997.

  • Not Enterprise Coffee ye Troll! ;)


  • I agree. It's almost like the language wasn't designed to be used. For display and dry discussion only.

    Whereas python is for display and use. And perl is for use and abuse :).

    As I type there are probably thousands of java programmers implementing their own versions of messiness like "split" or sprintf - StringTokenise blahblahblah.

    Also have you ever taken a look at Sun's Java documentation? It looks like a blooming academic textbook. Or an Oracle Installation Manual. Hands up how many of you actually used a 3rd party Oracle Install HOWTO instead?

    The docs also have very few useful working examples.

    Working examples are important so that you can more easily tell whether the language implementation screwed up (or just changed with rev X), or you did. That's real world for you.

  • How would you do the following in Java:

    As for sprintf. Well I dunno why, but many people are doing it in Java, so somehow there must be a need, or there was a need in the past (the out of date Java FAQ has at least one reason)? f

    Personally I see my colleagues doing Java and there seems just too much pain and trouble for me to bother.

    Basically I'm just waiting for it to get easier. Unfortunately the signs aren't promising.

    Meanwhile I might just go learn Ruby if I've got the time - the language even has standard methods to escape html or urls. Cool!

    Pity mod_ruby/FCGI, RDBC, Ruby/DBI stuff are not production ready yet. But once they've got that, I think the party will really start :).

  • That stringtokenizer code snippet supports what the original poster said: Java is verbose.

    Too often in Java you have to be more verbose just to do the _common_ case. I don't mind being verbose to do the uncommon case, but for the common case isn't that bad?

    With perl (and probably the others) I can do "change delimiters on the fly" with split (or something else) as well. This time it'll probably take about the same number of lines as StringTokeniser code to do the same thing.

    Another example, getting the number of rows in a SELECT. Many of my colleagues have gone through the pain of going "Doh! You mean there's no built-in attribute? You mean I have to get the result set, go to the end of the result set and fetch the current row number? What the ...?". BTW if this has changed recently please let my colleagues know - I'm sure they'll love it.

    That's the sort of thing I don't like about Java.

    I wish the Java creators actually bothered to sit down and use their own language for common real world situations. Well maybe they do, and they're the sort who don't mind doing 2 to 3 times more work just to do simple things. If they change that I might consider Java.

    Being verbose for the common case is bad because when you have to spread the common concept/idea/action over many lines, it can get lost amongst other lines. And then when you also have the uncommon case, you could confuse the two.

    Yeah I can probably build my own split in Java. But if I'm going to build all my stuff from molecules it might just be better to use LISP right?

    Also, if I build my own split, people looking at my code have to find out how my split actually behaves, and I might have to write documentation for it as well.

    Larry Wall's "Make easy things easy and hard things possible" sounds like a good idea to me.

    I find compression very analogous to programming.

    I prefer: compress very well for the common target data, compress ok for most unusual cases. Slight expansion for those rare pathological cases.

  • I've been using Hall's Core Servlets book as a learning tool and reference for the last few months now and have been very pleased with its clarity and examples. However, I thought it was a bit lacking in the JSP section, so I recently picked up the O'Reilly Java Server Pages book. I haven't read the whole thing, but I'm tempted to say this is the best JSP book that I've seen. Highly recommended... A42
  • Personally, I've never run an entire company by myself. I don't feel the need to study accounting so that I can figure out my own paycheck, so why should I study business? I don't care *why* management chose to go down a certain path. Even if it looks like to wrong choice to me sometimes, I trust them, because they know a lot more about that stuff than I do.

    I am an engineer, so I focus on the engineering. They tell me they want an enterprise solution, and I tell them what it's going to take to put in place. While I certainly care about the outcome of the project, and the future of the company, it's not my place to worry about it.

    You go ahead and read your "business aisle" books, and I'll focus on the specs. Together, we can build something that really works.

  • I'm a newbie to Java, but not interested in Applets. Servlets is where it's at, right BAY-BEE? Does anybody have any opinions on Marty Hall's book []? I'd be interested in hearing the good/bad/indifferent (or alternative titles if you think there is a better one for where I am now. (Have Resin running on a Mac LinuxPPC beige G3). Reader reviews on Amazon seem to like it.

    Curious George
    A.D.D. means never having to feel off-topic.

  • I may be wrong but the only place that Perl has really ever been REALLY strong (yes, it's used for scripting stuff by system admins but I'm talking *REALLY* widespread and serious mission critial use) is for CGI on web servers.
    You dismiss the primary market for a tool, then mock it? Do you kick a man when he's down, too?!?

    Secondly, how do you define 'serious mission critical'? CGI has *never* been in that category, but the assortment of crucial tools running on Unices, many written in Perl but short-tempered sysadmins, often are (as they keep the system ALIVE).

    Thirdly, although the original poster could have phrased it differently, he did have a point - namely, 2 of the largest areas of biz computing will be dominated by Java (large static systems engineered by hordes of cubicle drones) and Perl (continuing to keep IT running around the world; interfacing whatever junk apps the suits keep buying). It's a familiar dichotomy, and a persistent one at that.

    To repeat myself: Java and Perl are the primary representatives of two areas of biz computing, and they and their semantic derivatives will remain dominant in their respective spaces.

  • In a completely separate point, I was asking if my feelings about Perl actually being used less now than it was used 3 years ago are correct. What I mean is, rather than being a great example that everyone is following, Perl is actually slowly fading away from the position it once had.. I could be wrong, but that's the feeling I get..
    I think you're right; Perl is fading from the position it held 2-3 years ago. But remember what a wild ride the last 3 years were. Really - stop and think about it. Remember the religious devotion to C++ type tools before then? Remember before Linux started appearing in the Wall Street Journal regularly? Man, things are different.

    So what is this position it is fading from? Advocacy. I think Perl, used on the web, really validated scripting languages and prototyping for a huge swath of computing. Even the concept of TMTOWTDI: ignored, mocked, fought, and won. Now that the space has been validated, it is competing with Python, Ruby, Tcl, etc. I think Perl is still being used as much as it was then, and I have no predictions for its future, but it would be an odd thing if Perl were to regain the amount of buzz and mental energy exerted evaluating it like it had in the recent past. It's become a widely accepted workhorse, and we won't hear as much except the truly revolutionary events. Natural order of revolutions.

  • by nullnvoid ( 177438 ) on Thursday May 03, 2001 @07:23AM (#248488)

    Sounds like this book contains some of the nitty gritty that I've been missing in other volumes I've picked up. It's definitely on my buy-list now.

    I'm a little disappointed in some of the flamebait posted in response to this review, though. I thought trolls like that hung around the Java advocacy newsgroups all day.

    People who like to talk about the "failure" of Java apparently have very little exposure to the real world of Enterprise applications... EJBs, servlets, and JSPs are being deployed on many custom applications developed by and for Fortune 500 companies.

    Some of the more popular middleware is also either Java-based, or, at the very least, is exposed to developers through a handy Java API.

    In my experience, Java programming is one of the absolutely essential skills needed if one plans to develop these Internet and Intranet applications (and, no, I'm not talking about applets).

  • Let me tell you that the biggest problem in corporate development today isn't whether or not people understand J2EE, but whether they understand distributed idioms and business.

    I agree. The biggest problem is programmers who have NO understand on business. Programmers who also have extensive business /accounting/etc expertise are as rare as hen's teeth. (But I do know a couple). They are also way undervalued.

    This gets to be the equivalent of a non-coder technology manager who has picked up a book on javascript, and has written something simple in a afternoon. Who then says that there is nothing to javascript, and way can't you use javascript to create this intricate ssetup for me?

    A comprehensive understanding of the programming problem is vital to the development of a competent programming solution. To the extent that you do not have the the problem well defined, the more time you will spend debugging, etc.

    this is well illustrated by this webpage [], which tells the story of a guy who wrote a memory management tool. the only bugs in the program were a handful of typos. It was literally perfection otherwise. He obviously had done all of his debugging on papaer in the first place.

    The flip side on this is in large corporate enviroments where people asking for reports, etc do not understand the nature of the data in the first place, and so as for simple things that are hideously difficult, or which are confused in the first place.

    Check out the Vinny the Vampire [] comic strip

  • I like it when the book reviews have a picture of the book cover. Allows me to put a face with a name. ;-) Here [] is the page with the picture on it.
  • Perl is also "fast enough"; case in point, Slashdot

    I had a really good argument as to why that's not true, but during the 72 seconds I waited for this form to come up after I clicked "Reply to This", I forgot what my argument was.

    P.S. I have a fast connection and image loading turned off.

  • by timwynne ( 240808 ) on Thursday May 03, 2001 @07:06AM (#248492) Homepage
    .. should probably know that the second edition of Jason Hunter's excellent O'Reilly book on Servlet Programming is now available. Very good book, if you want an intro to java server-side dev Timo
  • by Rosonowski ( 250492 ) <> on Thursday May 03, 2001 @06:51AM (#248493)
    They had a 'college fair' at my local high-school, and I was bored. So, I went to some of the schools that I don't want to go to, and asked them-

    "do you have a distrubited network applications class?"

    Or advanced finite method elements?

    What about perl?

    Oddly, none of them could answer.

    Although I do enjoy java. My stepdad works for HiddenMind [], and they do some really cool stuff with java.

  • There are too many stupid "see spot do Java" books out there which reprint the entire stupid API, show you how to build some applets and have a chapter on "advanced topics" where they mention server-side java like it's the sacred cow.

    It's good to see a book that talks about server side java in a realistic manner. There are too many java programmers that think that dynamically creating HTML from your servlets is really cool stuff.
  • You may be right on the Perl side,
    But..surely, Java still has some barriers to overcome, like those people, who post on /. saying java sucks, with good reason, (being slow, too much like C++)
    But it is a easy language compared to the others and is as good as C++ or in this case C#
  • A book like this would be a great help to someone that knows the language but would like to start using it for the Internet. Like myself, I just started learning RMI and this book would be something that I would buy.
    You may not realize it, but since C# is basically a sellout to MS, Java and Perl are going to be the basis of most programming languages. Of course, C# will be used, but watch out for Java and Perl
  • I definitely think people undestimate the utility of planning/design. Oftentimes the corporate world is a tradeoff between designing and just typing something so you have something tangible to show people, even if it's just lines of code.
  • boycott or not, money is money. and you can get this book for $10 less from Amazon. free market and all that.
  • I have to agree with the reviewer on the general quality of Manning books. I have "Web Devlopment with JavaServer Pages' by Fields and Kolb, and it is excellent, better than anything from Wrox, or Addison-Wellesley.
    The other nice thing about Manning is you can buy a PDF copy of a book from their website [] for $13.50 plus 3.50 "processing fee" and apply the $13.50 as a credit to the hardcopy if you want to buy that later. Nice if you want to check it out before buying, or to keep a reference copy on your development box.
  • not to offend, but your post suffers from many of the phrasings uttered by the java marketing force .. i mean "EJBs, servlets, and JSPs are being deployed on many custom applications developed by and for Fortune 500 companies. " sounds like the tagline from the Sun developer connection pages.

    i'd like to dispute some points. first, most popular, mission critical middleware is still written in C and C++. most of course will create a Java API by putting lightweight wrapper classes around JNI calls to their code, but important software necessitates the level of control that C/C++ afford the developer.

    Second, I dispute that Java programming is absolutely necessary to develop inter/intra (why you make the distinction here is lost on me...)net apps. Knowledge of sockets and wire protocols are the keys to being a competent network programmer. remember, java sockets are native socket calls (and therefore, once again, written in c/c++ or assembly).

    now, that being said... I think java is better language to write most programs in. it is easier to write bug free code - both by design of the language IMHO and by ignoring portability concerns. No need to worry if an int is 16, 19, 3, or B bits, in java, just trust the VM that an int primitive is a signed 32 bit data type... Nobody's going to leave dangling pointers or forget to free buffers. It's good for very rapid development that requires very good reliability and good performance. It's also easier to read 'legacy code' since there's no really tricky code you can write for better or worse...

    but in the end, it's another turing equivalent language.. you can do the same thing in PERL, C++, VB, blah, blah, blah. it's all a matter of taste and convenience.
  • by redcup ( 441955 ) on Thursday May 03, 2001 @07:12AM (#248501)

    I take it this book is write once, read anywhere??

    Seriously, though - what you get out of a book is what you put into it. No book is a complete reference and doing the "extra leg-work" to fill in the gaps is the difference between reading a book because you love what you do, and reading a book because your boss told you to.


"You must have an IQ of at least half a million." -- Popeye