Junilu Lacar

+ Follow
since Feb 26, 2001
Junilu likes ...
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
Forum Moderator
Junilu Lacar currently moderates these forums:
Columbus OH
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 Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Junilu Lacar

A daily plan is good but do it daily and only plan on work you need to do for the day. Having a general plan with a longer horizon, say 1 or two weeks or even four is also fine as long as you keep in mind that it can always change at any given moment. It's better to be adaptable if you can't keep things predictable.

I heard a great quote yesterday from Mike Tyson of all people: "Everybody has a plan until they get punched in the face."

We developers are constantly getting punched in the face. Figuratively of course, not literally.
7 hours ago

Satyaprakash Joshii wrote:I can say 75 to 80 percent of the superiors I have come accross in my career would take it on their ego. 20-25 percent superiors I came accross are not like that.

Very much related to Sturgeon's Law, 90% of bosses are A-Holes. Well, maybe not that many, but pretty close. I can count on the fingers of one hand the good ones I've worked with in the past 30 or so years.
7 hours ago
I could go on and on with a number of callouts on that UML diagram but let me just stop here and say that in my experience, spending a lot of time on UML diagrams like this before you've written any code is a huge waste in both time and effort.

If I ever create UML diagrams (and I seldom do anymore) I would want to use an automated tool that analyzes my code. That is, instead of creating UML diagrams before I code, I'd rather do it after the fact, when I have a stable, tested, and proven codebase/design. UML diagrams created to document existing code provides far more value than UML diagrams created otherwise. For me, the latter are gigantic black holes of time and effort == $$$.
Naming again. You appear to be using the "Interface" suffix on any interface names. Take a look at the Java Collections Framework: none of the interfaces defined in it use that prefix. Think about why that is.
Why do you have find*() methods in your Log classes? Those are incongruent with the semantics of a class that is responsible for logging, unless you're using a different definition of "Log" from what most people normally associate it in a computer program.
This constructor signature on the Shipment class is a poor design:

Shipment(int, int, int, int, int, int, ArrayList<Product>)

1. Way too many parameters - see also long parameter list code smell

2. When applicable, prefer using the interface type (List<Product>) of the implementation type (ArrayList<Product>).

Campbell Ritchie wrote:But there is a better bound; if you have tried dividing 23 by 5 and smaller numbers, you know it is a prime number. Actually you will know 23 is prime if you find you can't divide it by 3.

I think efficiency is the least of OP's worries at this point.
15 hours ago
There's quite a bit to say about the diagram so I will give you bits at a time, otherwise replies will be very long.

1. Naming - WriteToStringInterface and CreateFromStringInterface are not good names. They're also not idiomatic names for interfaces. Those are verb phrases and as such are better suited as method names that evoke a sense of action. Class and interface names should be noun phrases or adjectives. Writable and Indentifiable are adjectives that I would expect to be names of interfaces because they end with "-able". Another example is the Comparable interface in the standard Java Collections Framework.

2. Archetype - you use <<Java Class>> for Company but since it has a getInstance method, this is probably better: <<Singleton>>

3. Archetype - you use <<Java Class>> for Identifiable. That will probably be better as an interface as its name suggests. This is a poor candidate for a base class and can quickly lead you to a very problematic design if you use it as a base class and extend it with subclasses that wouldn't be related otherwise, thus creating a poor inheritance structure. A couple of rules of thumb to remember: Favor composition over inheritance and Design and Document for inheritance. These two are not contradictory, as a cursory glance might make you think. Follow the first one (composition over inheritance) but if you must use inheritance, then make sure you consider it carefully and design around it properly.

Cliff Black wrote:I think I have received all the feed back I am going to get in regards to this query, but just to be neat and clear here is the correct coding, (I hope)

Hoping does not make a program correct. The code you posted does not look any different from what you had originally: not properly formatted and indented, poor variable names, and incorrect results.  
17 hours ago
The loop termination clause is divisor < number/2 which essentially says "execute the body of the loop if divisor is less than half the number; otherwise, terminate the loop"

Think about it, if you were to test if 23 was prime, you would only try divisors from 2 up to 11, right? Why go up to 12 when you know that 12 is more than half of 23 so it can't possibly be a whole divisor of 23. Likewise for any number greater than 12. That's why your upper limit for divisor values is half the number you're checking to see if it's prime. There's no point in going all the way up to the number itself.
1 day ago
It seems you're not quite clear on what the different clauses of the for-statement header do and when they are evaluated. Rather me explaining them, I suggest you study this first: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/for.html
1 day ago
If you notice, getCount() becomes .count in JSTL. All the other properties are accessed similarly. Read the JavaDoc descriptions carefully: they all say what the attribute is that you need to use in JSTL.

I don't know about the other error you're dealing with. "Unbalanced" simply means that the end tag is not paired up properly with a begin tag. What you showed seems to be paired up properly though.
1 day ago
Using better names can also help you make your program make more sense. The variable names i and j are not very meaningful. Look at the same code below that uses different names (I also moved some of the declarations around):

Read that code and see if you have a better time understanding how it works now.
1 day ago
That code you gave is wrong.

The for-loop on line 11 should be this:

Ideally, you'd enclose the body of the for-loop with braces, like this:

Always do that, even if the body has only one statement. This makes your intent clear and also helps avoid bugs in the future if you decide to add more statements to the body.
1 day ago
First off, proper indentation of code is very important. Improper indentation make the code confusing and even misleading.

This is not properly formatted / indented.

This is properly formatted / indented

Proper indentation is not just for aesthetic purposes. Proper indentation makes the structure of the program logic clear, shows which statements go together, and informs you about the order that statements will be executed.

In general, statements that are similarly aligned will be executed one after another from top to bottom. Any statements that are indented under another statement, like how line 8 is indented under line 7, indicates another level of detail that is subjugate to the first.

So, the for-loop on line 7 really has only three "subjugate" or detailed statements: the assignment statement on line 8, the for-loop that starts on line 11, and the if-statement on line 15. These will be executed one after another on each iteration of the for-loop on line 7.

Similarly, line 13 is indented one level from the for-loop on line 11. This makes it the only statement that is executed repeatedly by that for-loop. The if-statement below that on line 15 will be executed after the for-loop on line 11 gets done.

One last thing to note about indentation: In Java, the compiler doesn't care about indentation. Indentation is only helpful to the human reader. This in contrast with a language like Python, which has much stricter rules about indentation. But this is Java, so make it easy on yourself and others and make sure your code is properly indented.

EDIT: if the use of "subjugate" above seems weird, just substitute "subordinate" - what I mean is essentially that the indented statements are dependent on the "ruling" statement in some way. These subordinate statements are often said to be "the body" of the first statement. That is, line 13 forms the body of the for-statement on line 11. Line 11 itself is in the body of the for-statement on line 7 and is "sibling" of the statements on lines 8 and 15.
1 day ago