S J Martin

Or, ...
Store them as the value that they are and worry about rendering where it matters. ;-)

Originally posted by Burkhard Hassel:
These kinds of warning occur when you assign a generic variable to a "legacy object":

Indeed, and the compiler would see the call to addandDisp as "Legacy" as there was no generics decorator. Then, for those lines that add items to the list, warnings will be generated.

Hmmm, I'd be dubious as we suspect that they might use it for automated testing - especially for multi-threaded behaviour.

I, too, have a schema class (and several classes and interfaces), however, they are all access by the data class (which is thus simply a delegate). This seems sensible has the data class has quite high level functions in it (for a data access layer).

HTH

Also, did you use K&B. I noticed my copy was SCJP only - but the SCJD chapters are on the CD (under ebook) as PDFs.

Originally posted by rinke hoekstra:
Points you did not mention explicitly:
* the form should behave well when changing the screen resolution (not becoming a mess)
* Probably you should test it out at least on both linux and windows.

Ooooh, nice :-)
Thanks for that.

Snap on the SCJP score - bit annoying to have dropped those 6 questions though :-(

Originally posted by Mike Anakin:
List<? extends String>

Says: This will take a list of Strings, or lists of or something that "is a" String (i.e. a subclass - as String is not an interface). Thus you can retrieve Strings from this list and be confident that they have all "String" behaviour (what you retrieve may be a String or any object lower in the inheritance hierarchy).

However, I (the compiler) will not let you add anything to this list, because you are not allowed to mix generic classes and I (the compiler) can't be sure that you weren't passed a "List of sub-class to String" and put a String in it.

So, you are accepting List<String>, or a List<Subclass of String> and accessing items knowing that they have String behaviour.

List<? super String>

Says: I'm expecting a list of String or anything higher up the inheritance tree (e.g. an Object). Now the compiler can be sure that if you add a "String" to the list, any list accessors will not be confused (as the objects retrieved will have the necessary behaviour.

So, you are accepting a List<Object>, or a List<String>. In either case a "String" can be added to the list. As when something else accesses the lists items (e.g. Objects from the List<Object> ) what is in the list definitely has the "Object" behaviour.

HTH.

[ August 03, 2007: Message edited by: S J Martin ]
[ August 03, 2007: Message edited by: S J Martin ]

The identified classes of interest is sufficient.

I don't feel that they go into sufficient detail though. Not that I'm complaining - I wouldn't want them to waste pages in a book duplicating information in the API.

As well as reading the book.....
1. Study the Java API pages for those classes (class hierarchy, methods, etc)
2. Have a play with them.

HTH

Originally posted by Manfred Klug:
No. You will not get a warning at this point.

Ok, I was /nearly/ right. The above code will generate a warning - but on the list.add(...) lines within the addandDisp method.

Zero marks for "Nearly right" though :-(

Dolly,
The way I think of it is the JVM allocates such storage from the heap (as opposed to the stack). This is true for instance variables and static data. At the time of allocation it clears the data to zeros (which explains the default values for all variable types).

Only later (either at class loading for static initialisers), or constructors for (class instances) does the JVM run any initial assigement code (but before the constructor chain runs up the class heirarchy.

Finally, your class constructor code itself runs (as the JVM executes back down the class hierarchy) when /that/ code may start to over-write JVM defaults / static assignments.

(ok, there may be steps I've missed - it's late and I've drunk some wine ;-)
It all seemed logical to me when I studied the detail - though I can't help thinking in 'C' terms for some of this - NO "POINTERS" MY AR^H^H^H^H^H^H^H^H^H I'm an OO programmer, honest ;-)

Further to the above.

I'm fairly certain that you will get a compile time warning (as the compiler will see that you're passing a Genericised list into a Legacy style function).

You are expected to have a good understanding of the sort of scenarios that will cause errors and warnings for the exam when using generics.

I *strongly* suggest you paste the above code and compile it and satisfy yourself that you can see why you get what you get. I then suggest that you go through a series of "So that means if I change this line to blah, blah, blah I'll get such and such a response", then do the change and check your understanding (further refining your knowledge if you figured an incorrect result). Repeat that exercise for a whole host of changes to the above code (and lots of other code). Get to the stage where you're confident that you see some code and know the response.

Sorry, but some hard graft and good broad *knowledge* is required.

NB: I went into the exam expecting a gentle introduction with the first few questions, but WHAM!!!, they hit me with some taxing generics stuff that knocked me back a bit. I took it on the chin and ploughed through, some introduction :-( .

Ahhh, so you've changed machines.

Have you checked that you've got DB connectivity correctly configured ?

I assume that you're using a "thin" driver ?

Firstly, it looks like you've two tables with a 1:1 mapping, so I question if that is the case and why 1 table isn't more appropriate.

If you have a 1:Many (e.g. salary over time) then I'd have two transactions:
1. Create a new "Person" (done once)
2. Add that persons salary details (done many times, but after you've selected "the person" and hence your app knows the "id" of the person (and further "salaries" can be added as required).

If (for some other reasons) you definitely need two tables, and the insert into table b is required when you insert into table a I'd look a further options, e.g.
1. An updatable view (so it will look like only one table - don't know if your DB supports this concept).
2. A stored procedure that takes care of both tables.
However, these feel *much* less satisfactory than the first two and I'd only consider if there were strict reasons on not changing the schema (nor even allowing a new view definition).
3. Something else I've not yet thought of ;-)

What is your callable statement (the SQL).

Have you tried this from an db SQL client (e.g. SQL*Plus or some such ???).

Hmmm, probably JDBC driver specific.

Is there no driver generated error code further down the stack trace ?

I /think/ I've had such a response when there was no data available (but not because of an empty result set).

Thus, I suspect a programming/configuration error (as opposed to an SQL error).

Check that you've a valid connection, that the statement is correctly setup and that you're executing the statement correctly.

If you can't see anything wrong, take a few steps back - simplify things (e.g. remove any bind variables) and get that working. Then re-introduce one thing at a time.

Originally posted by Zein Nunna:
See my objective is to build something as efficient as possible. I want to do that from the start than to come back later and try to change things.

Ooooh, I always anticipate a good dose of "refactoring".