Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Java Books Media Programming Software Book Reviews IT Technology

Hardcore Java 197

Alex Garrett writes "First, a quibble. Hardcore Java is not hardcore. Hardcore is implementing coroutines in assembly language or creating a full-fledged OO system in 6K. But if you ignore the title and judge the book solely on its merits you'll find that a Java novice will find a good selection of interesting topics and even an expert will learn a few things. The expert will also find plenty of things to disagree with -- some matters of opinion and others of fact." With that start, read on for the rest of Garrett's review of Hardcore Java, a book in which he finds slightly more worth for Java novices than experts.
Hardcore Java
author Robert Simmons, Jr.
pages 400
publisher O'Reilly
rating Experts: 4/10; Novices: 6/10
reviewer Alex Garrett
ISBN 0596005687
summary The path to Java guru-hood

The two fatal flaws with this book are that it suffers from a lack of cohesion and focus on its audience and that it doesn't present anything new. That the book doesn't present anything new isn't bad if its goal is to summarize, clarify, and educate the novice. But this book doesn't even work for novices because the author has misidentified his audience. At times he writes for the intermediate programmer, at other times he writes for beginners. The confusion over the audience causes the book to leave novices and experts unsatisfied in equal parts.

Detailed Review
Simmons goal is to write a book that helps "transform a [Java] developer from the intermediate level to a true guru." It is his contention that there is a distinct lack of books that target the intermediate to advanced programmer -- his shining exception is the book Secrets of the C++ Masters by Jeff Alger. While I tend to agree with his assessment, I think that he fails for the following reasons: he doesn't stay true to the audience he has chosen and he doesn't say anything particularly new about the topics he covers.

Rather than provide a review of the book as a whole, I'm going to focus on a few chapters and describe what I thought worked and what I thought didn't work. I chose chapters where I thought the author really had an opportunity to distinguish this book from other similar books. At the end of the chapter reviews I provide an overview of the book.

Chapter 1: Java in Review
In this chapter the author sets the stage for the following chapters by providing an overview of the Java concepts that the reader is expected to be familiar with.

The Good:
Assertions are one of the things that a good software engineer should understand and use. It shows good judgement on the author's part to put them at the beginning of the book so the reader can benefit from the author's impressions. I also found his discussion of initialization to be insightful and interesting. I thought I had a pretty solid understanding of the subject but I was surprised to learn that a field can be initialized by what amounts to an inline method. The author cautions that this technique shouldn't be used often, but he gives a compelling example of when it can be used. It's definitely a trick I'm going to keep in my toolkit.

The Bad:
The first problem is that none of the material in this chapter is necessary for understanding the other parts of the book. Most of it could be reduced to footnotes or sidebars if the author felt it necessary to clarify subsequent topics, but to spend time explaining the importance of the default clause in a conditional is a waste of the reader's time. There's an old saying, "Tell me and I'll forget, show me and I may remember, involve me and I'll understand." The author of a technical book needs to make a significant effort to involve the reader. If involving the reader isn't possible for some reason, the author should, at the very least, show the reader rather than simply enumerating principles divorced from a learning context. Simmons should show us how to use assertions by using them. He does a great job of this with his ubiquitious use of final. I'm less certain of how well he does with his other core concepts. I could go back to the book and look it up, but if I need to do that, it means he's already failed.

The other problem with this chapter is that the author assumes the stance that the reader is a C++ programmer approaching Java. He asserts, "To understand the advanced concepts of the Java language, there are a few core concepts that you must have firmly in mind. Without these concepts, much of this book will not make a lot of sense. The concepts of pointers in Java, its class hierarchy, and RTTI (runtime type identification) are three of the most important on this list." This list might be important for a C or C++ programmer moving to Java (which is a position I'll hazard a guess that the author found himself) but it's marginally useful for anyone else. Allow me to summarize: Java has no pointers, all objects inherit from java.lang.Object, and you can interrogate an object to determine its type at runtime. 'Nuff said.

Unfortunately, this is a theme that runs throughout the book. The author seems to assume that his audience has a C++ background and he either differentiates between the things that Java has that C++ doesn't (e.g., pointers) or he introduces bits from his C++ background that are also in Java (e.g., the ternary operator). The reason for this, I believe, is that the author has failed to separate himself sufficiently from his audience. That's to say, he's writing the book that he would have liked to have read when he was starting his Java career. This isn't a bad thing if you're sufficiently like Robert Simmons, Jr. to warrant that kind of advice, but if you're not, his exposition is going to be hit or miss.

Chapter 5: Exceptional Code
This chapter covers the use and misuse of exceptions in Java. It provides a summary of the different types of exceptions and provides some guidelines for good coding practices.

The Good:
Exceptions are an important part of Java and are misunderstood by a fair chunk of Java developers. The author recognizes this and attempts to provide an introduction to exceptions and show some of the common exception anti-idioms. His discussion on the necessity of the atomicity of transactions was valuable and clear. He shows what happens in the rare instances when a transaction fails midstream and isn't rolled back. He then provides good advice on how to write code to prevent this sort of thing from happening.

The Bad:
This is a short chapter and that's unfortunate because the topic of exceptions is rich and worth much investigation. This chapter provided an excellent opportunity for Simmons to display some virtuosity and say something significant about the subject. If nothing else, he could have elaborated on the relative merits of checked exceptions vs. unchecked exceptions; a topic that has been the subject of Holy Wars in the Java/C# community. Unfortunately, all he really mustered was an, "unchecked exceptions are Java's way of not cluttering up your code with too many 'throws' clauses." (paraphrased, but see the end of section 5.1.1)

The author seems to have some good intuitions around the use and misuse of exceptions, but rather than clearly delineating the issues and sharing his insight with the reader, he sets up a couple of toy examples that show the syntax of exception handling and waffles around the issue of when to use checked exceptions and when to use unchecked exceptions. There is little enough spoken about exception handling that this might be sufficient if Joshua Bloch hadn't already provided a solid grounding in exceptions with Effective Java. But since he has, I had hoped for some new insights, which Simmons failed to provide.

Chapters 9 & 10: Practical Reflection and Proxies
These chapters provide an introduction to Java's capabilities for introspection of types and objects, as well as describing the new JDK 1.4 DynamicProxy class. Simmons also gives some examples of how to write proxies--dynamic and static.

The Good:
In choosing to cover Java's introspection facilities, the author demonstrates that he recognizes the importance of metaprogramming as a qualification of Java expertise. It's on par with things like writing classloaders or grokking bytecode and it separates the gurus from the merely competent. If nothing else, it gives Java programmers the opportunity to do the things that smug lisp weenies are always nattering on about.

The author gives a good overview of how reflection works in Java as well as providing some examples. He also distinguishes between static proxies (like the Proxy pattern in Design Patterns) and the nifty dynamic proxy part of JDK 1.4 and shows how to use these proxies and provides some demonstrations of how they can be used.

The Bad:
As with much of the book, the examples aren't particularly compelling and Simmons doesn't take the opportunity to take the reader to the next level and show him some sweet metaprogramming. Reflection and proxies aren't complicated conceptually, and the syntax is fairly straightforward. He could have gotten the implementation details out of the way and then provided examples from the field. The JMock guys are doing some nice work in generating mock objects for unit testing with dynamic proxy and the Nanning guys have a nice aspect-oriented programming framework that uses reflection and proxies. This is the kind of work that's being done with metaprogramming and confining the discussion to toy examples is discouraging.

Overall:
The Good:
The author has a good conversational style and seems like the kind of guy that you'd enjoy working with--friendly, knowledgable, and genuinely enthusiastic about his subject. The book has plenty of interesting material. The use of final is a great way of turning logic errors into compiler errors. A knowledge of metaprogramming is becoming more important every day, and bringing metaprogramming to test-driven development is an idea with considerable merit. Someone new to Java could use this book as a sampler of some important ideas in the practice of Java programming and explore the topics in greater depth at a later point.

The Bad:
This book suffers because the author identified his audience and stated his goal and then didn't follow the path he laid out. As a result, the author winds up disappointing all readers. The novice will find that the author glosses over topics that are clearly over their heads, while the expert will be bored by the level of detail that the author devotes to relatively simple topics.

Additionally, the examples are so simple that a newcomer to Java will not have trouble following them, but someone who has used Java for more than half-a-dozen months will find them uninteresting and unchallenging. The author should have taken the opportunity to really explore the space.

Conclusion:
While this book covered some interesting and high level java topics, it covered them shallowly and its content was presented inconsistently to readers of varying levels of expertise. The author needed to stick with his audience, choose topics that fit well together, and challenge the reader. That said, I don't lay the blame entirely on the author. His editor should have made the book tighter, more compelling, and more focused on its central thesis: helping intermediate Java programmers become expert Java programmers. The technical reviewers, who are presumably experts, should have provided the feedback that Simmons needed to raise the bar.

The book would be more appropriately titled, Robert Simmons, Jr. Shares Some Cool Things from Projects He Has Worked On. I think the best thing for this book would have been for the author to cull each chapter down to one quarter of its existing size and then publish them separately as magazine articles.

Alternate Sources:
The Java Programming Language, 3ed and Effective Java together cover nearly everything in this book in much greater detail and with better authority. Ken Arnold and James Gosling are two of three authors for the first book, and Joshua Bloch, author of the java.util.Collections classes is the author of the second. If you've mastered the material in these two books, you're an expert, full stop. Unfortunately, these books don't really cover reflection and proxies. If you're an intermediate java programmer and you want a good overview of proxies and metaprogramming in Java, I recommend the source code for Nanning, a lightweight aspect-oriented programming framework for Java.


Alex Garrett is a contract programmer who mostly works with Java. For a while, he was the acquisitions editor for Manning Publications, which inclines him to be a smug publishing weenie. You can purchase Hardcore Java from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.

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

Hardcore Java

Comments Filter:
  • Hardcore (Score:3, Insightful)

    by eln ( 21727 ) on Tuesday May 25, 2004 @03:02PM (#9251915)
    Anything that people feel the need to go out of their way to label "hardcore" isn't.
    • Re:Hardcore (Score:4, Funny)

      by Anonymous Coward on Tuesday May 25, 2004 @03:04PM (#9251956)
      mmmm....welll...I dunno about that. You must be severely desensitized from extended pr0n-viewing sessions to make that kind of statement ;)
  • by Stevyn ( 691306 ) on Tuesday May 25, 2004 @03:02PM (#9251924)
    It was in an ad for Starbucks. I didn't believe it then either.

    Once computers become easy to use and fast, we won't need to resort to java.

    By that I mean coffee.
    • "It was in an ad for Starbucks."

      Ugh. Something Janet Jackson said a couple of years ago twisted my perception of what this ad was about. To those who don't get the reference, consider yourself lucky, and don't search for Janet Jackson coffee.
      • This? (Score:2, Funny)

        by Anonymous Coward
        Enter the coffee cure. "With the enema you can bring out the sad cells or--whatever it is--even stronger." At one point, Jackson says she needed an enema two days in a row to cleanse some particularly pesky sad cells. - e!online [eonline.com]
      • That's like saying "Don't look down"
  • ...on OnJava [onjava.com] - they're excerpts from the book.

    These excerpts are pretty good - he talks thru some scoping issues that can be tricky. OuterClass.this.foo and all that sort of thing.
    • Actually, I think his comments on anonymous inner classes are pretty awful. In particular he makes two pretty bad points.

      First he claims that anonymous inner classes are not 'mainstream Java syntax'. Huh? He's got a fairly awkward definition of mainstream if that's the case.

      Second he rejects anonymous inner classes for GUI event handling, instead recommending making the the containing class implement XXXListener. I'll accept that they're two competing idioms, but his only argument is that his way is

      • > definition of mainstream

        Hm, maybe. I don't know. They look cluttered to me, especially in a language where blocks aren't the done thing. In Ruby, it's common to see blocks being invoked:

        some_array.each {|x| put x }

        but to see an anonymous inner class created in Java looks sort-of-blockish-but-not-really.

        > keep the event handling code
        > close to the control code.

        I don't know. Almost every time I make an anonymous inner class for a JButton I end up extracting it to a nested class so I can al

  • Nonono (Score:5, Funny)

    by Uma Thurman ( 623807 ) on Tuesday May 25, 2004 @03:03PM (#9251944) Homepage Journal
    Hardcore java is when you bomb the Microsoft headquarters for inventing C#.
    • Re:Nonono (Score:5, Funny)

      by Anonymous Coward on Tuesday May 25, 2004 @03:07PM (#9251997)
      No way. Harcord Java is when two threads are going at it while their parents are sleeping.
    • Re:Nonono (Score:4, Funny)

      by CodeMonkey4Hire ( 773870 ) on Tuesday May 25, 2004 @03:13PM (#9252068)
      Hardcore java is when you bomb the Microsoft headquarters for inventing C#.

      Invent [m-w.com]: to produce (as something useful) for the first time through the use of the imagination or of ingenious thinking and experiment

      While many /.ers would jump on the first bit, I was thinking more along the lines of C# being MS's clone of Java. Don't get me wrong, I like them both. I would never pay for C#, but if my boss gives it to me and tells me to use it, I'll count my blessings that it wasn't VB.
      • by brunes69 ( 86786 ) <slashdot@keir[ ]ad.org ['ste' in gap]> on Tuesday May 25, 2004 @03:38PM (#9252349)

        Mono [go-mono.com] is free and open source. So is DotGNU [dotgnu.org]. Rotor [microsoft.com] is made by MS themselves, free and "shared source". And the Microsoft Official .Net SDK [microsoft.com] is free as in beer as well, and free to distribute with any programs you make with it.

        With all these free implementations, and Lots of [icsharpcode.net] free Open Source [monodevelop.com] IDEs out there for it, implying that C# development costs money is pretty much the dumbest argument you can make against it.

        • Really, there's no need to flame me over this. I actually prefer C# over Java because of the .NET IDE. I haven't tried any of the free IDEs or compilers yet, but I am glad that they exist.

          Which IDE is the best? Does it have a compiler? If it is as easy to build forms in as .NET is, then I will finally uninstall VisualStudio 6.0. Is VB.NET supported too, or do I need to port over any of my VB.NET code to C# before trying to improve it in one of these? I have wanted to get .NET at home, but I didn't
        • And the Microsoft Official .Net SDK is free as in beer as well ...

          ... as long as you're running their non-free, proprietary operating system.
          • I gave 3 other examples of free C# compilers.
            • Re:So what? (Score:3, Insightful)

              by slagdogg ( 549983 )
              Mono and DotGNU as pure compilers are fine, but are "not there yet" as runtimes. Rotor is interesting but feature incomplete. I suppose we're talking about two different things here, I don't think C# has much value as just a language, so I was speaking of it in combination with the runtime (the real value, IMHO). The only production quality runtime at this time is the official Microsoft SDK.

              I like C#, don't get me wrong. But until Mono stabilizes (some areas have, yes, but much work is left) it's going to
        • uh, AFAIK, the windowing libraries (the GUI) are neither free nor cross platform. they are windows-only, ms-only.

          that that is what matters. ANSI c was cross platform, too. fine if you don't need a GUI.

          and, apart from technical details, there is the small matter of trusting the owner of this language - the company called microsoft - to keep it "open and free". HA HA HA. sigh.

          as soon as it poses any kind of business problem for MS, it's dead. c# development will not cost you money _right now_. but it will
      • Re:Nonono (Score:1, Insightful)

        by Anonymous Coward
        VB.NET actually isn't that bad. Fully OO, fairly intuitive language structure, and as fast as C#. There are worse things to be forced upon you.
  • Hardcore? (Score:5, Funny)

    by ayjay29 ( 144994 ) on Tuesday May 25, 2004 @03:06PM (#9251972)
    "Hardcore is implementing coroutines in assembly language or creating a full-fledged OO system in 6K."

    Didn't the word, or phrase originate from porn? Or was it in use before that? It certanly pre-dates assembly language.

    • Re:Hardcore? (Score:5, Insightful)

      by tfbastard ( 782237 ) on Tuesday May 25, 2004 @03:13PM (#9252065)
      The term hardcore is also applied on musical genres that are supposed to be harder and/or faster. First there was hardcore punk (think dead kennedys and black flag), 10 years later it was hardcore techno and "happy hardcore" (big, funny hat included).

      With that said, hardcore java is not an impossibility, since it's based on context.
      • by Anonymous Coward on Tuesday May 25, 2004 @03:35PM (#9252309)
        Right. Originally, it was hardcore Gregorian Chanting. It was pretty much like the regular chanting, except for all the cursing.
      • Re:Hardcore? (Score:3, Informative)

        by Otter ( 3800 )
        Interesting enough question to look up and...

        ...it seems [etymonline.com] that the word dates back to at least 1951, with its application to porn not coming until the 1970's. The pornography use definitely predates references to hardcore music, though.

    • It's long been said that there are real men and quiche eaters [wisc.edu].

      Legend has it the Seymour Cray actually toggled the first operating system for the CDC7600 in on the front panel from memory when it was first powered on. Needless to say, Seymour Cray is a Real Programmer.

      Assuming that "Real Men" and "Hardcore" are synonymous, and given that Java falls firmly in to the Quiche Eating category, can you really say you can have Hardcore Quiche?

      What's next: "AOL for Powerusers"?
      • My old departed friend and LGP-30 programmer once caught Cray filing down a resistor before soldering it back into the discrete circuitry. Something about tuning a pipeline cascade. Cray pretty much invented the instruction pipeline, and was known for tweaking his designs personally.
      • The operating system (the proper terminology would probably be "monitor") for the CDC 6x00 computers was manually disassembled into symbolic assembler from the octal code Cray and his team wrote for it. According to folklore [google.com], they had a strong dislike of anything to do with programming. Another thing I've recently learned about Cray is that he designed the Cray 1 and several subsequent models as a semicircle of cabinets because he liked to meditate in the alcove they formed. If nothing else, Seymour Cray wa
    • From WordNet (r) 2.0 [wn]:

      hardcore
      adj 1: stubbornly resistant to change or improvement; "hard-core
      addicts" [syn: {hard-core}]

      How prescient!
    • Re:Hardcore? (Score:3, Insightful)

      by sketerpot ( 454020 )
      The OO system in 6K isn't hardcore. It's cool, sure. Lots of things are cool. But it's just slightly mind-bending, since Scheme (the language used) really was designed for that sort of thing. It just takes messages in the form of symbols passed to a closure (a function with state) and looks up the corresponding member function, and does some various things for inheritance and such. I applaud the author of the OO system for making such a neat hack, but there's really nothing hardcore about using closures to
    • Re:Hardcore? (Score:3, Informative)

      by wass ( 72082 )
      Didn't the word, or phrase originate from porn? Or was it in use before that? It certanly pre-dates assembly language.

      I've heard it used in certain physics scattering models to refer to atoms with a hard core. Ie, scattering off of something with a 'soft' outer shell and a harder core. Rutherford may have used this term first w/ his gold foil experiment that determined the hard core nature of the atomic nucleus.

      Also used in some basic solid-state physics transort equations, like the Drude model. But

    • Didn't the word, or phrase originate from porn? Or was it in use before that? It certanly pre-dates assembly language.

      Here in the UK, "hardcore" originates in the construction industry where it refers to stones or rocks used as one of the foundation layers for roads and the like.

      I used to know this guy with buck teeth and a mullet and a bottle-opener style guitar who played something he called "hardcore" too.

  • by Retep Vosnul ( 663388 ) on Tuesday May 25, 2004 @03:06PM (#9251987) Homepage
    I'll just wait a couple of weeks and download the text from Limewire. I'll simply type "hardcore" in the searchbox and... ... ow.
  • by stratjakt ( 596332 ) on Tuesday May 25, 2004 @03:06PM (#9251989) Journal
    Hardcore is implementing coroutines in assembly language or creating a full-fledged OO system in 6K.

    No, hardcore is running another car into the ditch and killing the driver because they changed lanes without signalling.

    Or showing off your giant swastika tattoo to a black panthers meeting.

    Hardcore is doing coke off the blade of a knife while you make some chickenhead toss your salad as you cruise the strip in your dropped down caddy.

    That's hardcore, motherfucker.

    It has nothing to do with Java whatsoever.
    • by Dogun ( 7502 )
      Despite the obvious flame, the presence of the word 'swastika' I have to say that the parent is much more 'funny' than flamebait.
  • by ericspinder ( 146776 ) on Tuesday May 25, 2004 @03:09PM (#9252011) Journal
    I find this review to be interesting and well written, but I read parts of Hardcore Java and found it to be interesting. I disagree strongly with the reviewer on one thing...
    If you've mastered the material in these two books, you're an expert, full stop.
    NEVER, think that reading one or two books will make anyone an expert on anything, let alone on such a complex topic as programming. I personally never stop learning.

    The two books that he recomended look good on Amazon (they both reviewed well). I find it interesting the both of the books are from the same publisher. (note that I am not a amazon partner) The Java(TM) Programming Language (3rd Edition) [amazon.com]
    Effective Java Programming Language Guide [amazon.com]
    Nanning [codehaus.org]

    • Mastering the material in a book is different from merely reading a book...

      Concerning the editor, it really doesn't matter. Those books are good because they are from the authors of Java (and maybe because Sun has some good reviewers).

      Regards,
      David

      • That's true, mastering the material is very different than reading it. Heck, very recently I jumped on someone in this forum for taking my post incorrectly but, I don't believe that the author was recomending books as a index of the subjects to be learned, but as a definitive reading guide for the mastering of that subject. Just to be a little rude (but hopefully a little more funny),,,

        Master this subject and you will not need to learn anything thing else...

        • life

        Now pay me $39 (plus shipping)

        Even t

        • Master this subject and you will not need to learn anything thing else...

          What is this anything thing of which you speak? Sounds like Dr. Suess:

          It's the anything thing
          this thing that I bring.

          Use it for surfing
          use it to sing.

    • NEVER, think that reading one or two books will make anyone an expert on anything, let alone on such a complex topic as programming. I personally never stop learning.

      He didn't write "read", he wrote "mastered". There's a big difference. Since I haven't read the books, I can't comment on whether this is true, but in any case it's much different from what you're responding to.

    • NEVER, think that reading one or two books will make anyone an expert on anything, let alone on such a complex topic as programming. I personally never stop learning.

      That's only because the current crop of programming languages are so complex. Browsing my bookshelf got seven books on C++. Why? The language requires lots of details, C++ has a decent size library, and overall is rather complex.

      Then I scan my shelf for books on C and I only find one: the K&R book, 2nd edition. It's the only book

  • by Tsiangkun ( 746511 ) on Tuesday May 25, 2004 @03:14PM (#9252083) Homepage
    two fatal flaws with this book are that it suffers from a lack of cohesion and focus

    OK, a lot of tech books lack focus when trying to cover a lot of new material.

    it doesn't present anything new.

    oh.

    --Tsiangkun
  • by ShatteredDream ( 636520 ) on Tuesday May 25, 2004 @03:14PM (#9252096) Homepage
    Isn't that when your applet jumps out of its sandbox and gets all cozy and promiscuous with local apps?
  • by JessLeah ( 625838 ) * on Tuesday May 25, 2004 @03:15PM (#9252107)
    "Hardcore is implementing coroutines in assembly language or creating a full-fledged OO system in 6K."

    I can see it now. The scene: A dark alley, after dusk. A geek wearing scotch-taped glasses and with a Zaurus in his pocket confronts a group of large, scary men.

    Geek: "I'm hardcore, man! I implemented a fully-fledged object oriented system in six kilobytes of code! I even talked to a girl once!"

    Thug 1: "Let's beat Professor Einstein here up."

    Geek: "You can't touch me, knave! I'm hardcore!"

    (the beating commences...)

    Geek: "Ow! OWWW! Linus protect meeeee!"
    • Is implementing coroutines in assembly really that complicated? I never did it, but shouldn't it just be setting up several stacks and doing simple stack switching? Indeed, I guess implementing coroutines without assembly language would really be hardcore!

  • by spankalee ( 598232 ) on Tuesday May 25, 2004 @03:15PM (#9252109)
    Hardcore Java might not be as h4r6c0r3 as assembly, but that doesn't mean that the title should be ignored or that there is simply no such thing as "hardcore" java.

    Harcore Java to me means writing Class Loaders or Security Managers, bypassing encapsulation or field and method visibility with reflection, choosing the right garbage collector for high performance server-side applications, dissecting the binary class file format, creating post-compilation class "enhancers" like JDO uses, etc.

    These are things that are beyond your typical Java novice, and I would expect some mention of some of these level of topics in any java book labeled "hardcore".

    So far from ignoring the title, if this book is more for novices than experts, I'd say the title might be misleading. But if I ignore the first few sentences of your review I might find it less biased and more useful.
    • Hardcore? Or dumb? (Score:4, Insightful)

      by Joseph Vigneau ( 514 ) * on Tuesday May 25, 2004 @03:40PM (#9252364)
      Unless you have a really good reason (such as writing an IDE), don't do this:

      bypassing encapsulation or field and method visibility with reflection

      this:

      dissecting the binary class file format

      or this:

      creating post-compilation class "enhancers" like JDO uses

      Using the reflection libraries to get around visibility means you're just begging for a maintenance headache in the future.

      Dissecting the class file format to see how a particular compiler translated your code can be a useful technique, but you can't depend on the output being the same when you use different compilers on different platforms.

      Modifying class files after compilation is also a good way to give yourself a lot of headaches when things go wrong. It becomes very difficult to determine the cause of any problems. If you need to build classes like this, you should either generate Java code and compile that (like most JSP compilers), or use aspect-oriented programming tools like AspectJ [aspectj.org].
      • Well... I didn't say they were smart ideas, but hardcore has never meant prudent to me.

        Also, using assembly means you're just begging for a maintenance headache as well.

        It's all in why you're doing what you're doing. For some stuff you might need to get hardcore (oooh, how extreme :)

        When I was writing applets back in the 1.0 days I had to do some crazy hacks to get around Microsoft incompatibilities, or to implement double buffering or transparent widgets. Some of the hacks included changing Sun's source
        • spankalee says:

          "Well... I didn't say they were smart ideas, but hardcore has never meant prudent to me."

          Exactly. If you're hacking the formalism of a language and you're a reasonable practitioner of that language, my experience is that you're doing it because of some nasty constraint in the OS, the problem, or for some political reason.

          Back in the JDK1.2.2 days, I had to implement an web-based autoupdate system for a Java app that required the ability to update the JDK on the fly, and then restart the
      • by Doomdark ( 136619 )
        Uh? Where did he say "hardcore" equals "the right way"? I definitely think examples he mentions are pretty hard-core, as in doing things most developers aren't even aware can be done, and wouldn't dream of doing.

        My personal favourite of hard-core java things, though, is replacing default Object class that comes with JDK with your own. It was presented in the best java performance tuning available, and was rather interesting thing to do. Author just added bit more debugging, and overriding things in Object

    • Ever heard of C?

      Java was meant to shield the programmer from the hardcore stuff.

      Or of assembler?

      I want to read a book titled: Business reporting and web front-ends in Java for ASP programmers. That book will fly off the shelves.
    • What's wrong with "Advanced Java"?

    • Agreed, up to a point...

      When I read the title of the review, the first thing that came to my mind was "Server-based Java Programming", from Manning editorials.

      It's one of those really good books that have been sligthly, but unfortunately misnamed. Although the motivation IS server-side code, and there's enough material covering the topic (data layers, rmi, services, etc), its best material was on class loaders and funky ways of using and abusing them.

      It was very good at explaining the implications of lan
  • Judging by the review of his book, it sounds a heck of a lot like this one [amazon.com], only I happened to read that book and pick up a Java cert while the reviewed book probably didn't have that type of information.

    I'm probably being overly simplistic (I'm very interested in the examples of practical reflection and proxies, two features I've not found a use for yet and also were not on the exam), but that's my view in a nutshell.

  • No Pointers? (Score:1, Informative)

    by Anonymous Coward
    Allow me to summarize: Java has no pointers

    If Java has no pointers what's going on here:

    int[] array, array2;
    array = new int[1];

    array[0] = 5;
    array2 = array;
    array2[0] = 12;

    System.out.println("" + array[0]);
    • That's a reference :p
    • Re:No Pointers? (Score:5, Informative)

      by lightsaber1 ( 686686 ) on Tuesday May 25, 2004 @03:44PM (#9252412)
      Incidentally, Java is *all* pointers (except for a few primitives). They just abstract it away so you don't need to worry about it. The 'new' keyword should be a dead giveaway if nothing else (unless you've never used C++ I suppose).
      • Re:No Pointers? (Score:3, Informative)

        by Q Who ( 588741 )

        Yes, pointers without pointer arithmetic, without ability to point to arbitrary locations inside objects, without ability to put arbitrary data to the pointed location.

        Handlers are not pointers.

        I suggest you read a book about implementing programming languages.

        • Re:No Pointers? (Score:3, Informative)

          by lightsaber1 ( 686686 )
          I suggest you work on your terminology. What Java uses IS a pointer, albeit dumbed down to the extent where it is nothing more than an address. An explanation (the first one I found in a google search, albeit not the best I've seen) can be found here [8m.com].

          The definition of a pointer does NOT require arithmetic, arbitrary pointing, or arbitrary data writing. Dictionary.com defines it as "A variable that holds the address of a core storage location." Java just happens to ensure you can't do these things bec

    • Re:No Pointers? (Score:5, Informative)

      by pclminion ( 145572 ) on Tuesday May 25, 2004 @04:06PM (#9252683)
      If Java has no pointers what's going on here:

      Call it a handle, or a reference. It is superficially like a pointer, as your example demonstrates.

      However, it clearly is not a pointer, because you cannot do this:

      array2 = array + 1;

      You also cannot do this:

      array2[1] = 12;

      Because it would cause a bounds exception. In C, you can get away with writing outside an array, and you get all the wonderful side effects of that, including random crashes, data corruption, or in the worst possible scenario, no visible bug whatsoever.

      And don't even think of trying this in Java:

      double[] foo = new double[100];
      int[] bar;
      bar = (int[])foo;

      The above is an example of a pointer typecast as it would be expressed in Java (if it was allowed), but thankfully, the above code is utter nonsense. Anyway, the entities you manipulate in Java are quite assuredly not pointers. They are handles to objects.

      • Anyway, the entities you manipulate in Java are quite assuredly not pointers.

        If people defined their terms, there would be alot fewer arguments in the world.
        According to the Java specification [sun.com], Java references are pointers. What you are saying is that Java does not have C style pointers. There are definitions of "pointer" at different levels of granulairty. Java has pointers if using a more generic definition of "pointer".
    • reference != pointer (Score:5, Informative)

      by Theatetus ( 521747 ) * on Tuesday May 25, 2004 @06:02PM (#9253875) Journal

      A reference is not the same thing as a pointer. A pointer is one way to implement a reference, and judging by Java's error messages it's how most implementations have implemented them (it may be required in the spec for all I know).

      Then again, pointers aren't even in the original spec for C++, you were just supposed to use references. That never caught on among compiler writers, though.

  • by Anonymous Coward
    I see Sun have released Java runtimes for AMD64, and wonder what the performance is like compared to plain 32-bit intel, MHz for MHz.

    There should be a decent improvement running in 64-bit mode, both for the VM and the code it's running, or?
  • by account_deleted ( 4530225 ) on Tuesday May 25, 2004 @03:28PM (#9252247)
    Comment removed based on user account deletion
  • Effective Java (Score:5, Interesting)

    by ChiralSoftware ( 743411 ) <info@chiralsoftware.net> on Tuesday May 25, 2004 @03:36PM (#9252322) Homepage
    by Joshua Bloch is the best programming book I have ever read in any language. It goes into detail about exceptions and how to use them properly. It sounds like it covers everything which this book covers, but it's brilliant. It's also a thin book. It is the only computer science book I have ever read multiple times, and gotten something out of it every time I have read it. Anyone else who has read this book is invited to chime in here...

    -----------
    WAP software [chiralsoftware.net]

    • Re:Effective Java (Score:4, Informative)

      by radish ( 98371 ) on Tuesday May 25, 2004 @04:23PM (#9252885) Homepage
      It's the only one I recommend that everyone in my team borrows & reads, or better yet, has on their shelf. Java Thread Programming (Paul Hyde) is another nice, though more specalist title. Round here we just call Effective Java "The Book".
    • Effective Java is the best programming book I have ever read in any language.

      You should try reading fiction sometime. It's much more pleasant than books on programming languages.

      • It's much more pleasant than books on programming languages.

        It all depends on what you find pleasurable. I personally get more pleasure expanding my vision, than expanding my imagination (, which is not to say I don't get pleasure expanding the latter, merely moreso the former).

  • Hardcore Java (Score:3, Interesting)

    by herwin ( 169154 ) <herwin AT theworld DOT com> on Tuesday May 25, 2004 @03:36PM (#9252330) Homepage Journal
    I bought the book hoping for material that I could present in an Advanced Object Oriented Design class. I was disappointed.
  • How can something without pointers be hardcore? It's li
    Aborted.
  • uninstalled from my comp and in liquid form in my coffee cup
  • by Anonymous Coward
    That's all I've got to say about that.
  • Coroutines in assembly is trivial, one processor I worked with (the 1802, NASA's favorite processor for the '70s and '80s) uses coroutines as the basic calling mechainism. It doesn't support subroutines: you have to implement them using coroutines.

    Hardcore isn't even implementing coroutines portably in 48 lines of Forth, as I did for a control system in the '80s. Anything you can't at least prototype in 48 lines of Forth is probably something you don't understand well enough to do anyway.

    No...

    Hardcore is implementing coroutines in C using clever tricks with the subroutine calling conventions, and then building a paradigm-beating operating system like UNIX on top of it.

    Oh, I gave the punchline away. /* you are not meant to understand this. */
    • Allegedly, FST Modula-2 for MS-DOS (a shareware compiler) implemented co-routines. Unfortunaley I was too young and stupid to try them out. Anything other than "Hello, world!" on MS-DOS is hardcore ... by the very nature of the (lack of) design.

      Now, don't get me started on TSRs....

      I think it's all this beer they make me drink. ;-)

      Now, FORTH,... if only...

    • Yes, coroutines in assembly are trivial. But then, unlike the kids around here, we're experienced programmers. Hehe.
      -russ
  • - Write and compile Direct X based 3D code to win32 (for video games, physics sim etc.) - Write and compile code for 68K asm, ARM etc, for various types of portable devices (much cleaner source than C/C++) - Write very fast and efficient server side apps to run on Mac OS X. But I'm sure its much more fun and easier to slander Java than do something useful with it. I'll resuming coding now... Mark
    • But I'm sure its much more fun and easier to slander Java than do something useful with it.

      <looks around> I don't see any slander here.

      Why are you so insecure about your language of choice? If it's really all you make it out to be, what does it matter if a few twirps on some message board disparage it? Not to mention you've gotten defensive even before the insults have started flying...

      Very, very odd behavior, I think.

  • I hope the book actually talked about the JDK 1.4 dynamic proxy class java.lang.reflect.Proxy, because people will be unhappy if they look for DynamicProxy, which doesn't exist.
  • Where's the xJAVAx tattoo then? Object oriented till death!
  • This implements an object-oriented forth:

    \ Mini-OOF 12apr98py
    : method ( m v -- m' v ) Create over , swap cell+ swap
    DOES> ( ... o -- ... ) @ over @ + @ execute ;
    : var ( m v size -- m v' ) Create over , +
    DOES> ( o -- addr ) @ + ;
    : class ( class -- class methods vars ) dup 2@ ;
    : end-class ( class methods vars -- )
    Create here >r , dup , 2 cells ?DO ['] noop , 1 cells +LOOP
    cell+ dup cell+ r> rot @ 2 cells /string move ;
    : defines ( xt class -- ) ' >body @ + ! ;
    : new

  • A counterexample

    Mock me if you will, but there was once a book called Hardcore Visual Basic [mvps.org]. It was one of the few intelligent books written on the subject. I'm not a big VB fan, but I can appreciate how it once was a great RAD tool. I wished all of Microsoft's VB-like documentation looked like this. It was rigorous and concise.

    I remember all of the laughs I got when I went around the office asking if anyone had ever heard of a VB book written for C++ programmers. Of course, my smart-ass smirk proba
  • I read this book on Safari. Really, nothing in this book is advanced -- it's just about all covered much better in Bloch's Effective Java and in free articles online.

    Some parts that contribute to my bad review:

    • The first chapter tells us that RTTI is used by the compiler to prevent type errors.
    • Not only do the code examples dealing with the final keyword not work, they very obviously don't work.

    Oreilly has a good track record for their books, but this one made me think they'll give anyone a book deal

  • The google cache link is below

    Google cache [216.239.59.104]

    PDF Critique [peter-cockerell.net]

    OReilly book page with sample chapter. [oreilly.com]
  • Sweet! I, for one, have been DYING to see Java take it right up its...

    What? Not that kind of 'hardcore'? Damn.

    Doug

Let's organize this thing and take all the fun out of it.

Working...