Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
Win a copy of GANs in ActionE this week in the AI forum
or WebAssembly in Action in the JavaScript forum!

Edward Kenworthy

Ranch Hand
+ Follow
since Oct 05, 2003
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Edward Kenworthy

Originally posted by Jeanne Boyarsky:
JavaRanch actually does have sigs. If you edit your profile, it's the last item in the first section.

Yeah I know: I just thought my comment would be funnier if I pretended they didn't. Kind of like when Roger rabbit escapes from the handcuffs and Bob Hoskyns asks him why he didn't do it earlier: "because it wasn't funny then.". Oh well maybe not

Originally posted by Eric Benoit:

I don't use EJB at work but I think it's a good technology to know. (and be certified in)

I heard that many enterprises want to remove EJB from their product, is it true that EJB is called to disappear?

I would like to have your opinion on that!


I think EJB's are an awful technology: it's one of the best examples of what happens when a committe tries to impose a theoretical standard from a standing start. I wouldn't be at all surprised if it became a text book example of how not to define a standard.

For goodness sake: a Java based technology that doesn't support inheritance!?!? And that's the only the start of the EJB creators' crimes. Talk about brain dead.

The sooner it dies and lifts its dark cloud from J2EE (which is generally excellent) the better.

IMO Spring and Hibernate with a decent J2EE server (even Tomcat) can do everything that EJBs were supposed do and in a much cleaner, portable and *testable* manner.

The primary key is not stored in the container at all, it's stored in the database and in the entity itself (ie its one of its fields).
Frankly that sounds like an awful idea: calling static methods on *business* objects to interact with the databse. Where do I begin in describing what's wrong with this approach.

Firstly: static methods are effectively global so you've made you're entire app dependent on those classes.

Second: You've hard coded your dependency on those classes: you couldn't for example use another object that implements the same interface to substitue: how do you test? How do you migrate to another environment?

Third: Well third you're using EJBs but then let's just say EJB CMP is an abomination and BMP is worse...

Have look at Hibernate which is a brilliant ORM library: and in case you're desperate to stick with EJB (some kind of masochist huh?) then a) you can use Hibernate from Stateless Session beans and b) Gavin King, the lead dev for Hibernate, is also on the EJB 3.0 CMP committe and reports EJB 3.0 CMP will look an awful lot like Hibernate.


If JavaRanch had sigs mine would say: Burn EJB and their creators!

Originally posted by Nidhi Singhal:
i have good hands on experience in java servlets and jdbc. I am interested in learning struts and ejb's. please suggest me a good book or any online tutorial/material from where i should start with.

My personal recommendation is: don't. They're both awful technologies (EJBs much more so than Struts but never the less). Look at some other J2EE based technologies instead: eg Hibernate for persistence, Spring for gluing applications together and either Spring or Tapestry for a Web framework.

Bruce Tate does a good job of explaining why: Don't Make Me Eat The Elephant Again

If you want to read a good book (I'd recommend reading this anyway) then try "J2EE Development without EJB" by Rod Johnson, published by Wrox.

You'll thank me.

[ January 10, 2005: Message edited by: Edward Kenworthy ]

Originally posted by Jeremy Wilson:
I have an inputstream that I need to read the data into a byte array or a byter buffer. The problem is I don't know exactly how many bytes I need to read into array to wrap with the bytebuffer. Any help reading an inputstream to a byte array without any indication of how many bytes there are that would be create. The data is being read from a proprietary flat file format.

Well if you're reading in a file then you can easily find out it's size and hence the size of the array you need: File has a method called length().

If you really don't know then do something like (this is pseudo code obviously):

read x bytes into temporary buffer;
increase the size of array by number of bytes actually read)
write bytes to array from buffer to array;

Choose x to be reasonably large (say 100) to keep the array re-sizing efficient but not too large otherwise the temporary buffer will have to be too big.
15 years ago

Originally posted by omar bili:

the number of possibilities is the factorial of abc.length() =>
3! = 6

Not entirely true. Eg the length of the string "aaa" is 3 yet the number of combinations is 1.
15 years ago
Well two problem's really: first use xxx.getClass().getName() and second use StringBuffer or MessageFormat to create your message string: concatentating strings inside two loops will slow things down a lot.
15 years ago
Whilst interfaces can be used to simulate multiple inheritance (in the C++ sense) that's a mis-use and a bit of a red herring. Interfaces are not there to give you multiple inheritance in Java: if you're doing that then either there's something wrong with your design, the design of some class library or the way you're trying to use it.

To answer the thread starter's question: why use an abstract class instead of an interface (and vice versa)?

I would *always* use an interface, as that defines the set of operations supported by my classes. I might then consider implementing that interface as an abstract class in order to provide some skeleton code or some default behaviour.

Why would I use both?

Because by implementing the top level as an interface I allow for the possibility of anything being overridden: I don't impose any unnecessary restrictions on how the interface is implemented in the future.

I'd use the Abstract class to implement any common implementation: and I'd make it abstract even if I implemented every method defined in the interface because (without going into the reasoning) only the leaf classes of an inheritance hierarchy should be concrete. I wouldn't necessarily have an abstract class at all.

Hope that helps.

[ January 07, 2005: Message edited by: Edward Kenworthy ]
15 years ago

Originally posted by M Burke:
Yes, I ended up doing a bunch of string copies. To bad there is no memcpy() in Java like in C

If that's really a problem then you're using the wrong language: use C.

I suspect however it's more the case that you're not yet up to speed with Java and you haven't taken a couple of steps back and asked "what am I actually trying to achieve here" and from there "what's the best way to do that in Java that fits Java's paradigm: not C's".
15 years ago

Originally posted by Marlene Miller:
Thank you all.

I made a mistake. I meant Word for Mac, not Windows for Mac. Office 2004 for Mac is too expensive just to send documents to Windows users. Is that the only way? I think I'll try saving Appleworks documents as .doc.

I've got all the information I need. I am ready to advise my dad on what he will need. I think he'll like the eMac.

Thank you for the help.

Do not, I say again, do NOT touch AppleWorks with a bargepole: it is truly awful: bug ridden and frankly Apple should be ashamed.

Either wait for the rumoured new Apple Office suite or have a look at OpenOffice.
15 years ago

Originally posted by Bear Bibeault:

Sage advice.

But also completely unnecessary: unless you change it your account is not by default a ROOT account and if an app needs to do something that requires admin access OSX prompts you for your password, so nothing can just sneak in and install itself.
15 years ago
resource only has one s in it...
15 years ago

Originally posted by Mark Spritzler:
In Better, Faster, Lighter Java from O'Reilly press there are chapters on Hibernate and Spring and how to use them together.


That's a bit of lightweight introduction: it's the kind of book you read, think "hmm interesting" and then never pickup again: it's certainly no use for giving any guidance in actually using Spring and Hibernate.

I have to disagree: serializable should implement an interface with a "serialize" method. A default can be provide by Object.
15 years ago