Matt Vanecek

Greenhorn
+ Follow
since Oct 30, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Matt Vanecek

Where I work, we use Java Data Objects, using DataNucleus as the provider. At the outset of my project, I visited Spring in Action, and POJOs in Action, and a couple other books, to try and get up to speed. And oh, yeah, I read the JDO specifications (in shifts--I kept falling asleep!). We settled on JDO because it was 1) more mature then JPA, and 2) it works with our legacy data model with very little work-around. JPA would simply not be able to handle our data model and its old-style relationships without a HUGE amount of coding to manage the relationships.

What I had wanted to do with our app was use Spring as the transaction manager, connection manager, etc. I had two problems, however: JDO is very poorly documented and examples are quite lacking (and we had a short timeline), and I need to retrieve the database URL via a Web server (long story there, the retrieval method isn't going to change, can't have the URL statically configured in a bean, etc.). In JDO, once the PersistenceManagerFactory has been configured, certain properties are immutable. E.g., the DB URL.

So, the problem was, Spring would load the JDO beans and I couldn't set the URL that was retrieved from the Web service. What we ended up doing was creating a custom PersistenceManagerFactory wrapper that loaded all the basic properties, retrieved the URL, and instantiated the Factory. Works OK, I guess, but we would've saved some time in both coding and testing if we could've just autowired it all together.

My questions for Craig (or anybody who knows) are, does the new book have a more in-depth treatment of JDO and other persistence specifications (e.g., JPA, EJB3). And does Spring 3 provide expanded capabilities for managing JDO providers and resources, over Spring 2? And are those resources any better documented than in Spring 2.x?

I don't want to start any JDO vs. JPA discussions (EJB3 is totally out--not running in a container)--I just want to know if Spring 3 expands JDO-provider management any over Spring 3, and if the book has more in it than the last Spring in Action book I got, which had only a few pages touching JDO.

Thanks,
Matt
14 years ago
Thank you, Ankit! That explains the first one.

For the second one, I'm assuming the spec makes some special provision for enums declared inside a class? For example, for a normal non-static inner class, if I tried to instantiate the inner class directly from main(), I'd get a "No enclosing instance of type OuterClass is accessible." error. Inner classes also can't have static members, etc., which means in main() I can't do "InnerClass.someStaticMethod()", because the thing wouldn't compile anyhow with static fields in InnerClass.

But it seems enums are special, in that I can create an enum as an instance enum, yet can still access the instance enum in a static manner because the Java compiler makes almost everything inside the enum static, and anything inside the enum is only accessible via one of the static enum fields (e.g., Days.WED)--which can only be accessed statically via Days....or something like that.

I guess it's safe to say that writing an enum definition as a non-static "inner class" (so to speak) still leaves the enum class accessible in a static manner, where declaring a field of type "enum" follows the normal rules of access, as do any other non-static inner classes.

Somewhat circular and takes a bit of thinking...I *think* I understand this twist. My enums have always been stand-alone, because they're used across multiple classes, so I've never encountered this twist before.

Thanks,
Matt
Decided to get certified, so picked up this book yesterday. I have a couple questions on the self-test in Chapter 1 that didn't seem to be covered in the chapter:

1. ST question 4:


My assumption was that TestEnum.a would be null, since it is not initialized. Any other static field would be null, per default initialization. However, aside from static access using a non-static reference (a.DOG instead of Animals.DOG), this code works. Are statically-declared enums treated differently by Java? Where is this documented?

2: ST Question 9:

How is TestDays.main() able to access Days, when Days appears to me to be an instance declaration?

I love enums, but have not ever used them in a way that is contrary to normal Java access rules (e.g., can't access non-static fields from a static method, etc.) Is this contradiction further explained in the rest of the book, or am I missing something (seriously)?

Thanks,
Matt