David Harkness

Still no luck, but after a lot more research I've switched to a bi-directional relationship.
@Entity @Table(name = "slave") @GenericGenerator(name = "master_pk", strategy = "foreign", parameters = { @Parameter(name = "property", value = "master") }) public class Slave implements Serializable { @Id @GeneratedValue(generator = "master_pk") @Column(name = "master_id") private Integer masterId; @OneToOne @PrimaryKeyJoinColumn private Master master; ... } Master hasn't changed, and I get a new exception:
org.hibernate.id.IdentifierGenerationException: attempted to assign id from null one-to-one property: master However, in my DAO I dump out the references between the master and slave; both are valid, non-null objects. That means that either the exception is completely erroneous or Hibernate/Spring is setting the slave's master reference to null after persisting the master but before persisting the slave. That makes no sense.

I have two tables that use the same primary key generated for the "master" table in a one-to-one relationship, and I'm using JPA annotations with Hibernate 3.5.6.
class Master { @Id @GeneratedValue(strategy = GenerationType.AUTO) private Integer id; @OneToOne @PrimaryKeyJoinColumn(name = "id") private Slave slave; } class Slave { @Id @Column(name = "master_id") private int masterId; // <-- note int instead of Integer } When I create a new master and slave and save them together by saving the master, a 0 value is inserted into slave.master_id instead of the generated value from master.id. The problem is that it's not copying the generated ID from the Master instance to its Slave instance. If I change Slave's masterId type to Integer I get an exception instead:
org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save(): com.foo.Slave I'm using Spring and Hibernate which I last used a few years ago so I'm basically starting over. I copied this from the example:
<property name="eventListeners"> <map> <entry key="merge"> <bean class="org.springframework.orm.hibernate3.support.IdTransferringMergeEventListener"/> </entry> </map> </property> and the code that saves the objects is quite basic:
public Master storeMaster(Master master) { return (Master) getSession().merge(master); } Specifying a cascadeType (ALL) has no effect. Am I missing a step? While my model does allow a Master to be saved without a Slave, I'd rather not save the Master, attach the Slave, copy the generated ID over, and save again. It just doesn't feel right.

Great, that's quite clear now. We use jQuery for the user-facing site here and GWT for our deployment platform. As a backend engineer I am only a little familiar with these libraries. I think I'll pick up this book for myself and another for the junior members on our team.

Thanks for your analysis. I'm reminded of when I started with Python. At first I tried to use it like Java, but once I learned about its functional aspects I became far more productive. You can really shoot yourself in the foot by ignoring the true nature of a language.

What about Dojo? It looked slick back in 2006 when the scene was exploding.

Now that you've written two books on these three JavaScript frameworks, which would you pick for a new project, for example on a new forum system? Or would you use them each for different aspects of the system?

Congratulations on moving into the author sphere. It's been a long while since I tipped back a glass in the saloon, but not too long to remember that you have put a lot of time into this site and helping the other ranchers, and it's great to see you publishing now!

The main thread catching the exception does indeed terminate the program. However, all that logic is happening in the main thread. Until the program actually terminates, the other thread is still active and running. This is one possible sequence of events:

1. Thread t1 starts
2. Second call to start() throws exception
3. Exception caught by main thread's run()
4. Thread t1's run() prints "go "
5. Main thread calls System.exit()

If you can use a prebuilt library, search for GUID and UUID. Universally unique sounds so much more unique than globally unique, don't you agree?

If you have to build your own, start with the ideas I presented and start diving into the JavaDocs! Even if this is the case, there's plenty of sample code that can get you started and keep you moving.

Good luck!

Note that every variable must be initialized before it is used. It's easy to miss this because the JVM initializes all instance and static members whether you want it to or not.

I suspect the reason for the difference in behavior involved many late nights of frenetic nerf gun battles in the Sun hallways.

James: Auto-initializing variables is ugly and wasteful! The compiler run your code through a proof engine to ensure every constructor call results in exactly one initialization per variable.

Patrick: Do you realize how hard that would be? *ducks* Besides, 83.2% of all class members are initialized to the same defaults, so we save the developers keystrokes!

James: Hey! I got you, cheater! You're out.

Patrick: No way man -- prove it!

Yes, I think that's exactly how it went down. Such reverent times they were. . .

This is a pretty common problem. One fairly simple solution (minimize your effort -- usually a good thing) is to use an external utility to sort each file to a new file. If you're tight on RAM, do one at a time rather than in parallel. Once that's complete, performing a "diff" is a snap.

Here's an example of two sorted files, using single letters rather than whole lines though there is no difference.F1 F2 A B B C D E E F H GThe algorithm is slightly different if you can make certain asumptions like "Some lines in F1 aren't in F2 (must be processed), but every line in F2 is in F1". In other words, F2 is a subset of F1. Once you understand the general case, however, handling assumptions is easy.

I'll put it into words instead of psuedocode to provide a challenge.

Logically, you have a pointer into each file to a "current line". They both start at the first line of their file. In code, this entails simply a BufferedReader to maintain the pointer and a currentLine to hold the line just read. I'll refer to the lines as L1 and L2.

Do the following until you run out of lines. Compare the two lines using String.compareTo(). [note: does case matter? whitespace?]

If they are equal, read the next line for both files and continue the loop.

If L1 < L2 (sorts before it), F2 doesn't contain L1. Process L1 and read the next line from F1 only.

By necessity L1 > L2, meaning F1 doesn't contain L2. Do whatever you feel is necessary to L2 (flog, shread, decompile) and then read the next line from F2.

Give that a shot, and let me know if I glossed over too much.

I'd definitely recommend storing a copy on the server to keep everyone honest. Allow them to upload new versions for history tracking, and they'll love you.

Are the path to the file and its name valuable information beyond allowing you to grab a copy of it? Or is it sufficient to just get the contents? As a compromise you could have an edit box for "title" so they're not constrained to valid file name formats. Again, it all depends on your needs.

There are pre-built tools to handle the uploaded content, for example Jakarta's FileUpload (probably part of Commons Net, I'd guess). I coded my own way back when but haven't needed to handle uploaded files since. I do know it's not so simple. You get a stream and don't get told the size of the file up-front. The early tools simply wrote the data to a temporary file and returned it to your application. You can double-check, but when you get the file's contents, you don't get its name.

Then again, maybe the latest versions of Struts abstract this all out of sight for you. Wouldn't that be nice?

Be sure to share your pain with us when you hit that part.

Originally posted by aaron UD:
it starts very quickly, then slows down more and more as the program runs (i can tell because of the output).

Glad to hear you solved the issue. I'd just like to point out output to the console can be very slow. You'd be amazed at how much a program speeds up if you minimize/hide the window and only show it every so often to check on progress.

Bhuvi, welcome to JavaRanch! If I may, I'd like to pass on some friendly advice based on your recent posts.

People volunteer their time here to answer questions, and we enjoy doing it to be sure. But like most people, we have busy lives that limit the amount of time we can devote. It will greatly increase your chances of getting answers if it's clear that you've done at least the bare minimum of work to answer your own question before posting. Better still if you've exhausted every resource you know.

As an example, I'm going to pretend I don't know the answer, and I'll time how long it takes to find an reasonable answer. Ready, set, go! . . . Done! Total time: two minutes. Granted, I knew what I was looking for, and I could quickly recognize a ballpark answer, but in this case it didn't even matter.

Here's what I did:

Opened www.google.com. Actually, this is always my first step!

Entered [url=http://www.google.com/search?hl=en&q=java+design+patterns&btnG=Google+Search-"java design patterns"[/url] (no quotes) and hit enter.

First link was a Google search, skipped it.

Second link was a free PDF book -- looks good, but I didn't want to take the time to download it. I suggest you check it out though.

Third link was the actual PDF, skipped it.

Fourth link was a link to an index of the JavaWord "Java Design Patterns" articles, very promising indeed (check it out!), but I'm lazy so I skipped it. I was on the clock here!

Fifth link was one of those articles. The summary left no room for doubt -- I was home free!

Design patterns are proven techniques for implementing robust, malleable, reusable, and extensible object-oriented software.

Arguably not a very complete definition, but the article starts by extending that definition and continues to provide a few concrete (real-world) examples.

So my advice is that you make an effort to teach yourself before asking for others to teach you. Not only will you get more answers, but by learning how to find your own answers, you'll be able to get answers on your time instead of waiting for someone to respond. That in itself is very powerful and absolutely necessary in a job situation.

Best of luck!
[ May 03, 2005: Message edited by: David Harkness ]

Originally posted by bhuvi mdu:
why transient variable cannot be serialized?

It's been explained a couple times in this thread, but just in case it wasn't crystal clear: Java's transient keyword tells the serialization system to ignore the fields when writing and to initialize them the same way instance fields are initialized during reading.

Here's another example from the JDK itself. The standard Collection classes introduced in JDK 1.2 can cause intermittent exceptions or simply "unexplainable" behavior under specific multi-threaded conditions, even if you synchronize all calls to its methods. One such condition is when any thread calls a method that structurally modifies it while one thread is using its Iterator.

For example, changing a value in a Collection doesn't alter the its structure. But adding a new value can. In a TreeSet, adding a new value requires inserting a new node somewhere in the tree. Any live Iterators will have an internal state that's no longer consistent with the TreeSet. Trying to return the next element might return the wrong element (skipping some or jumping back in the sequence) or one that was removed.

Sun's solution was to add an instance variable (called modCount) that tracks the number of times the Collection has been structurally modified. When an Iterator is created, it stores a copy of modCount. At the start of each method -- hasNext(), next(), and remove() -- it checks its copy against the Collection's current value. If they differ, it throws a ConcurrentModificationException.

[ Note to self: examples aren't very good if they require three paragraphs to provide background that's necessary but in the end doesn't really relate to the topic at hand. My bad. ]

In any case, if you serialize the Collection and then deserialize it some time in the future, you receive a new reference to a new Collection. It's physically impossible for any object in memory to hold a reference to it. Therefore, there's no point in storing modCount; it can safely be initialized to 0.

What about any Iterators on that Collection that were serialized with it? It would be a problem only if the Collection's Iterators implemented Serializable. I checked ArrayList's, and it isn't in JDK 1.5.0. I suspect none of them are as serializing an Iterator seems marginally useful at best.

That's got my vote. Nice one, Ricardo!

To be specific, "System.currentTimeMillis() >>> 8" divides the millisecond value by 256, equivalent to dropping the milliseconds and dividing by 32, yielding a value of approximately the "current current half minute." This method is clearly likely to yield duplicate values, even between JVMs on different machines.

That last clause brings up something not mentioned in the original question: Does the value need to be unique across all JVMs running on any machine in the world (or even limited to a local area network)? If so, Google for "globally unique identifier," often abbreviated as GUID. There are several libraries that will generate them for you by combining various attributes to achieve maximum likelihood of randomness. Common attributes used include the current time, machine's IP address, a memory address of some object, some process's identifier, and a random number.