Tim Holloway

+ Follow
since Jun 25, 2001
Tim likes ...
Android Eclipse IDE Linux
Forum Moderator
Tim Holloway currently moderates these forums:
Long-time moderator for the Tomcat and JavaServer Faces forums. Designer and manager for the mousetech.com enterprise server farm, which runs VMs, a private cloud and a whole raft of Docker containers.

These days, doing a lot of IoT stuff with Arduinos and Raspberry Pi's.
Jacksonville, Florida USA
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
(keep public parts private until JForum day)
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Tim Holloway

Campbell Ritchie wrote:Thank you. Does that mean Eckel was mistaken, or have I simply misread the book?

Since I haven't read the book, I don't know the context, but definitely 0 is not null in Java.

That only makes sense, since you don't know what an object reference really is. It could be a straight pointer, it could be a Macintosh-style "handle" (pointer-to-a-pointer), it could be an index into a pointer array or map. Or a base+displacement tuple - the language doesn't require any specific implementation, unlike C, where you're programming to a much less abstract level.

There's a whole raft of situations in programming where you have what I'd term a "heterogeneous result set". I don't know of any formal studies on the matter, but it's endemic.

Consider the classic simple search of an array for an integer value. There are 2 possible types of outcomes. You can either obtain the array index of the matching element (we'll assume only 1 match), OR you can return "NOT FOUND".

But "NOT FOUND" is not an index or even an integer. In simpler times, to denote NOT FOUND we'd generally return an obviously invalid index, such as -1. These days, we often dodge the issue by throwing an exception. In Java, we'll often return null, unless the method in question returns a primitive result.

So in C, the convention for "obviously invalid index" of a pointer is 0. Except where it isn't. :eek"
1 day ago
I'm pretty sure that zero is not the same thing as null in Java. Wait, I just checked. It's definitely verboten. However, you can assign 0 to an object of class java.lang.Object. Apparently the auto-boxer converts 0 to Integer(0) and assigns it.


I'm afraid that "fortunately" is the operative word for C. C is used as a "high-level assembly language". The Prime Computer minicomputer systems kept their register file in the first half-dozen or so memory locations, with the Accumulator register being location 0. In systems-level programming you might actually end up coding something like "memory[0] = sysio(foo);".

That's just one case I can think of. IBM kept all sorts of important stuff in low RAM on the S/360 series and up, and that included location 0.

You may expect segmentation faults on nullpointer accesses, but I grew up on non-segmented systems. Depending on what (if any) memory-management hardware was present, you'd be lucky to get random garbage. A segment fault whose access address is 0 is pretty straightfoward by comparison.

0 In C is also the NUL character in both ASCII and EBCIDIC. Note that there's only one "L"! Java is much more type-safe. NUL, zero and null are all distinctly different and the differences are enforced at compile-type. Barring the "gotcha" I mentioned above!
1 day ago
Four concepts worth considering:
  • null
  • void
  • nothing
  • unknown

In some languages, such as C, null is literally zero. So a null pointer is actually memory address zero, which can (and does) lead to interesting complications on machines where memory location zero has a special purpose. Fortunately, C doesn't throw NullPointerExceptions. In Java, null is a "placeholder" value that - as so many before me have noted - means that the object reference in question doesn't actually have a value.

Void, isn't null, but it does mean nothing. In the sense that a function that "returns" void doesn't return any value, not even null. On some platforms I've even been known to cast the results of a function call to void either to document that I intended to discard the result or to keep the compiler from whining. Example:
Here the "memset" function would return the number of bytes cleared and I don't care, so I'm explicitly throwing it away. Actually, I do this with the C string copy and concatenation functions often.

Then there's "unknown". In Java you might adopt the convention that an unknown value should be represented by null, but that's at your option depending on need. Databases often use null for either unknown or not present, which are not the same thing and can often lead to grief.

Two of the biggest headaches in Java come from methods that return String or a collection where the returned value for an empty string/collection could either be literally an empty (zero-length) string/ empty collection or null. I'm solidly with Junilu on avoiding the use of null for something empty. The Optional feature was a useful addition to the repertoire, but it's still a kludge.

You may also see constructs like this in Java code:

While in English the sentence structure would be more natural as "if ( action.equals("stop"))", that will result in a NullPointerException if action is null because the base object belongs to no class and thus doesn't implement "equals()". On the other hand, it's perfectly legal to compare an object inheriting the equals() method from java.lang.Object to null, so no exception will occur.

1 day ago
I think you're trying to be too efficient.

Just because you ensured that the JSON was valid when you wrote it out to the database doesn't mean that some toe-rag can't come in and mess it up using a database utility program.

One thing that Murphy has taught me in a long and evil career is to trust no one and nothing and I'd count the cost of validation on fetched data as a small price to pay.
2 days ago
Parent/child isn't One-to-One. It's one-to-Many on the parent and Many-to-One on the child entity. Whether you define the mappings unidirectionally or bi-directionally is up to you.

A fully bi-directional mapping would include a collection of Child Entity. You can make this lazy-fetch or eager-fetch, depending on how you expect to use it. The child Entity would have a ManyToOne relationship back to its parent.

Normally you do the linkages using the Entity property name as the reference key. That may or may not be the same name as the database column name, depending on how the Entity maps to the underlying database schema. In my case column names are often things like "CREATE_DATE", and the corresponding Entity property name is java-style (createDate).
Markets haven't been around for decades, they've been around for centuries.

Contrary to popular belief, financial instrument and commodities markets aren't gambling casinos. And the major stock markets overall are one of the better ways to accumulate wealth. You simply need to follow some basic and well-published rules and determine what sort of goals you have. Based on your goals, you adopt a strategy. Your best chances for success are to be consistent in following that strategy, although goals (and hence strategy) may change throughout life.

Perhaps the most basic rule of them all is that the bigger the payout, the bigger the chance that you'll lose some or all of your investment. So if you expect to retire in comfort, don't grab at every get-rich-quick scheme that comes along. It's a good way to make a small fortune - assuming you started with a large fortune.

Investing is very much a bootstrapping process, Which means that if you can't afford a pair of boots to begin with, look elsewhere. If you have to tap your investments every time you need new soles, you'll lose. You do have to have money to make money and you need to be able to make your decisions on your own schedule, not someone else's. The people who got wiped out in the Crash of 1928 were not the ones who kept their investments, they're the ones who sold. In many cases, they had no choice but to sell, since conditions at the time led too much buying on margin and banks who had a vested interest in being stock brokers. The long-term holders saw their investments dip, then slowly return to (and mostly0) exceed) pre-crash values. Some companies failed, but the AT&T's, General Motors, and so forth didn't. The truly wealthy had diversified portfolios so a few failures were a mere annoyance. The day-traders and hot-tip investors ended up in the bread lines.

Incidentally, I once had over 1000 shares of a popular and now-defunct airline named Air Florida. Lost every penny. On the other hand, I bought Cisco, held onto it for 10-15 years and sold it to pay off the mortgage on my house. I also bought Red Hat not long after it went public

One of the biggest mistakes you can make is to buy into fads. Markets stampede. Once something like BitCoin gains general public notice, everyone rushes in, pushes valuations to absurd levels, the realists cash out and the accelerating sales cause prices to crash. Assuming that the market in question doesn't completely collapse, that's when the more cautious (and successful) investors like Warren Buffet move in, buy up and wait for prices to recover.
Don't try to "time" the market. It's enough to recognize trends. I sold Cisco when it had stopped growing and lost its early fire. I don't think I ever owned Microsoft or IBM directly (since I also invest via funds, what they do is up to them).

2 days ago
By using the JSTL "if" tag, you can code this without any Java scriptlet code at all.

Regardless, as a login page, a hacker could shred it in little or no time.

Don't write your own login system. Use the J2EE container security standard or at least a reputable third-party security package. If you're not a full-time trained security professional, it's very, very unlikely that you're going to produce a secure system, no matter how clever you think you are.
2 days ago
That was something I wondered about as well. In JSF, EL may reference a specific property, a method (for example, action methods) or be a arithmetic or logical expression.

The Schema definition says that the "if" element should evaluate to "true" if the navigation is to occur, so that would seem to rule out a method call and thus you'd code like this:

Which would invoke the isRegister() boolean property-get method on the user bean.
2 days ago
I checked the JSF 2.2 schema definition. The body of the <if> element is supposed to be an EL expression returning a boolean value.

2 days ago
I don't think that "images/germany" is a valid library name.

The syntax that I'd use would be like this:

Note, however that the exact terminology that Oracle uses to reference the image object is image name, not image pathname. So there's some question about the legality of doing subdirectories with image locations at all.

Sadly, the Sun and Oracle documentation tends to be sloppy in areas like this.
3 days ago
Oh, almost forgot.

One limitation. JSF works with forms, and when you submit a form, only data in that form gets submitted. No data from any other form on the page will be submitted, and therefore backing bean data from other forms will not be updated.

This is actually a restriction of HTML forms. JSF is based on HTML, so it inherits HTML's limitaitons.
3 days ago
I usually do have to do several cycles on questions like these. When I see obvious violations of JSF operating principles, I tend to focus on them first.

One of the magical things about MVC is that a View can be backed by multiple Models and a Model can be backed by multiple Views. It's not strictly one-to-one.

One of my favorite examples is a View that contains 2 sub-views of the same Model. One as a spreadsheet and one as a piechart. Change a cell in the spreadsheet, presto! The piechart gets re-drawn too.

In your case, I'm reading it that you have 2 distinct JSF Managed Beans. No problem. You can use them both as backing beans on the same view, no problem. To get information from one bean into the other, you simply inject the first bean as a ManagedProperty into the second bean. So if you have a bean that manages an editor session (editBean) and another bean that holds the actual data being edited (dataBean), then the editBean form can update the data bean's properties via EL like this:

And JSF will do the rest.

Likewise, if editBean has an action method named doEdit(), then the edit code can access the data like so:
3 days ago
JSF does not work by "passing parameters". Instead, JSF employs the Model/View/Controller architecture.

In MVC, changes to the controls in the View update their corresponding values in the Model (Backing Bean). Likewise, changes in the Model update the control values in the View.

Since this is operating under HTTP, however, it takes manual action (a form submit) to accomplish this. Unlike desktop MVC systems, HTTP cannot asynchronously make View changes or see View changes - only a request/response cycle can do this.

Because many controls are both read and written, function call representation of the control values on the form don't work. Instead, the Expression Language (EL) supports property references. That is:

Would have to be

JSF will automatically invoke getXyz() on the bean to obtain the value to display and it will also automatically invoke setXyz() on the bean when the form is submitted. You do not have to (and shouldn't!) write any actual code to transfer the data between the form and backing bean. This is part of JSF's Inversion of Control architecture. IoC is a common and popular way of programming where data is manipulated by external mechanisms (the JSF control framework) as opposed to having to hard-code the data manipulation in application logic.

Because JSF automatically brings the values on the form and the values in the backing bean(s) into sync when a form is submitted (via commandButton or commandLink), you don't submit using a function call or parameters, you use a method reference.

That is:

Will initiate the JSF lifecycle processing. JSF will validate the data on the form, and if (and only if) [i]all[/b] control values are valid, it will then update the backing bean with those values. JSF will then invoke the doSomething() method and the doSomething method can proceed confident that all the data that was entered is available as property values within the backing bean.

It's a general rule that the more work and the more JSF-specific code that you create, the more likely that you're doing it wrong. JSF is very automatic.

3 days ago

Peter Rooke wrote:My understanding is the idea behind AOP is to address two major issues with code; code scattering and code tangling. 

Logging, transactions, security, debugging, diagnostics would be candidates.


The normal organization of a system's functions is a hierarchical tree (Directed Acyclic Graph), working from the top down. With AOP, you go sideways instead.

A tree can have only one root. You can, however, have many aspects, as you've noted.

To simplify the application of aspects, one defines templates and uses a code processor to apply them to existing code. This can be done either at the source code level (which means basically writing an entire compiler) or by weaving into the generated bytecodes - which avoids having to do a lot of lexical scanning, parsing, and digestion.

In a sense, Java annotations also embody AOP, but you have to manually attach them to the code in question.

Spring itself has several function sets that lend themselves to the aspect-oriented approach. So what Keith really wanted to know is how Spring 5 changes them.
4 days ago