What are enums and why are they useful?

You should always use enums when a variable (especially a method parameter) can only take one out of a small set of possible values. Examples would be things like type constants (contract status: “permanent”, “temp”, “apprentice”), or flags (“execute now”, “defer execution”).

If you use enums instead of integers (or String codes), you increase compile-time checking and avoid errors from passing in invalid constants, and you document which values are legal to use.

BTW, overuse of enums might mean that your methods do too much (it’s often better to have several separate methods, rather than one method that takes several flags which modify what it does), but if you have to use flags or type codes, enums are the way to go.

As an example, which is better?

/** Counts number of foobangs.
 * @param type Type of foobangs to count. Can be 1=green foobangs,
 * 2=wrinkled foobangs, 3=sweet foobangs, 0=all types.
 * @return number of foobangs of type
 */
public int countFoobangs(int type)

versus

/** Types of foobangs. */
public enum FB_TYPE {
 GREEN, WRINKLED, SWEET, 
 /** special type for all types combined */
 ALL;
}

/** Counts number of foobangs.
 * @param type Type of foobangs to count
 * @return number of foobangs of type
 */
public int countFoobangs(FB_TYPE type)

A method call like:

int sweetFoobangCount = countFoobangs(3);

then becomes:

int sweetFoobangCount = countFoobangs(FB_TYPE.SWEET);

---

In the second example, it’s immediately clear which types are allowed, docs and implementation cannot go out of sync, and the compiler can enforce this. Also, an invalid call like

int sweetFoobangCount = countFoobangs(99);

is no longer possible.

http://stackoverflow.com/questions/4709175/what-are-enums-and-why-are-they-useful

Java SE and Java EE?

To clarify some things:

Java – a programming language.

JavaSE – a term that refers to Java, and a collection of standard libraries and utilities.

JavaEE – a term that refers to Java, and a collection of libraries used for building “enterprise applications” (usually web applications).

There is nothing you can do in JavaEE that can’t be done in JavaSE, but if you need to build an enterprise application, JavaEE will make your life easier.

By definition, you must learn Java (the language) and and some JavaSE (the libraries – though you could skip things like Swing and SWT which could be included in JavaSE but aren’t necessary for JavaEE) to work in JavaEE, because it doesn’t make any sense to learn JavaEE and not know Java and JavaSE.

http://programmers.stackexchange.com/questions/101282/java-se-and-java-ee

Assertion in Java?

Assertions (by way of the assert keyword) were added in Java 1.4. They are used to verify the correctness of an invariant in the code. They should never be triggered in production code, and are indicative of a bug or misuse of a code path. They can be activated at run-time by way of the -ea option on the java command, but are not turned on by default.

An example:

public Foo acquireFoo(int id) {
  Foo result = null;
  if (id > 50) {
    result = fooService.read(id);
  } else {
    result = new Foo(id);
  }
  assert result != null;

  return result;
}

http://stackoverflow.com/questions/2758224/assertion-in-java

Semaphore vs. Monitors – what’s the difference?

A Monitor is an object designed to be accessed from multiple threads. The member functions or methods of a monitor object will enforce mutual exclusion, so only one thread may be performing any action on the object at a given time. If one thread is currently executing a member function of the object then any other thread that tries to call a member function of that object will have to wait until the first has finished.

A Semaphore is a lower-level object. You might well use a semaphore to implement a monitor. A semaphore essentially is just a counter. When the counter is positive, if a thread tries to acquire the semaphore then it is allowed, and the counter is decremented. When a thread is done then it releases the semaphore, and increments the counter.

If the counter is already zero when a thread tries to acquire the semaphore then it has to wait until another thread releases the semaphore. If multiple threads are waiting when a thread releases a semaphore then one of them gets it. The thread that releases a semaphore need not be the same thread that acquired it.

A monitor is like a public toilet. Only one person can enter at a time. They lock the door to prevent anyone else coming in, do their stuff, and then unlock it when they leave.

A semaphore is like a bike hire place. They have a certain number of bikes. If you try and hire a bike and they have one free then you can take it, otherwise you must wait. When someone returns their bike then someone else can take it. If you have a bike then you can give it to someone else to return — the bike hire place doesn’t care who returns it, as long as they get their bike back.

http://stackoverflow.com/questions/7335950/semaphore-vs-monitors-whats-the-difference

What does this thread join code mean?

To quote from the Thread.join() method javadocs:

Waits for this thread to die.

So t1.join() is called to wait for the t1 thread to finish. Then t2.join() is called to wait for the t2thread to finish. The 2 threads have been running in parallel but the thread that started them (probably the main thread) needs to wait for them to finish before continuing. That’s a common pattern. When the main thread calls t1.join() it will stop running and wait for the t1 thread to finish.

The break; really isn’t necessary but is there because the code is in a while(true) loop. That’s a very strange pattern and probably can be removed. join() does throw InterruptedException but that means that the thread that is calling join() was interrupted. In that case the main thread should not loop around.

http://stackoverflow.com/questions/15956231/what-does-this-thread-join-code-mean

What is Java EE?

J2EE is actually a collection of technologies and APIs for the Java platform designed to support “Enterprise” Applications which can generally be classed as large-scale, distributed, transactional and highly-available applications designed to support mission-critical business requirements.

In terms of what an employee is looking for in specific techs, it is quite hard to say, because the playing field has kept changing over he last 5 years. It really is about the class of problems that are being solved more than anything else. Transactions and distribution are key.

http://stackoverflow.com/questions/106820/what-is-java-ee

Action-based or Component-based MVC?

Which type of MVC framework to use: action-based or component-based? A very opinionated topic to say the least and has many pros and cons to both sides of the argument. I’m going to provide some insight from my experience into this area of discussion and hopefully keep the discussion to facts and not market hype (“fluff” as I call it).

The Case for Action-Based MVC Frameworks
Action-based MVC frameworks were introduced about the time of Struts (some would argue that it was Struts that brought about the term). The basic premise of the action-based design is that for each user request into the application, these are considrered “actions”. Each action would have a mapping and a flow from the request to the object responsible for request handling to the view representing this action result, looking like this:

This design gives us a very fine-grained flow and makes the application web-tier very simplistic in terms of keeping up with which request is handled by which object(s) and is presented with which view. The benefits of this are many, including: ease of development; quick ramp-up time for new developers; easily tested using a browser. The drawbacks of this design include, among other minor issues, that the application project will become very large in the MVC management with any site consisting of more than a few pages. Another drawback is the lack of “collecting” the common actions into single objects (each action has its own object) – so if you had 30 actions, you would likewise have 30 configurations of action mappings along with 30 objects.

The Case for Component-Based MVC Frameworks
Component-based MVC frameworks provide a coarse-grained design and were born out of the desire for many architects to “collect” actions related to the same type of data together into groups. This means that if you have actions for ‘login’, ‘logout’ and ‘getAccount’ that these could be grouped together into one component called ‘AccountController’, for example. This controller object would then handle all account-related actions. The benefits of this design are: easy testing; small project footprint at the action level (actions essentially are methods); simplified configuration. The drawbacks of this design include: having to read code to determine presentation view (could be handled in configuration); multiple developers potentially working on same component at same time. The following is an overview of component-based design flow:

My Recommendation
Whether using an MVC framework or handling MVC on your own, I suggest that you first decide how big the project is going to potentially be. Of course no one has a crystal ball, however if the application is a storefront with displays of products and handling credit card information for payment, then it’s small enough that action-based will be sufficient. On the other hand, if the application is an online portal then most likely you should use the component-based design. It has been my personal experience that most applications are better off using the component-based design. I have worked with many clients and their employees in which the decision of which type of MVC framework to use was based purely on whichever one they had experience with – this is absolutely the worse way to design an application. Application design should be done by someone with no reservations as to which tools to use – rather to design the application with the best tool for the job. Deciding on the best tool for the application has nothing to do with how much experience one has with said tool.

http://shaunchilders.com/node/8

Difference between Request MVC and Component MVC

In request (action) based MVC, a single front controller servlet will delegate to action models based on request URL/params. You works directly with raw HttpServletRequest and HttpServletResponse objects in the action model. You’ve to write code yourself to gather, convert and validate the request parameters and if necessary update the model values before you can ever invoke the business action.

In component based MVC, a single front controller will gather, convert and validate request parameters and update the model values itself so that you only need to worry about the business action yourself. How the controller needs to gather/convert/validate/update the values is definied in a single place, the view. Since that’s not possible with “plain” HTML, a specific markup language is required to achieve the goal. In case of JSF 2.0, that’s XML (XHTML) based. You use XML to define UI components which in turn contain information about how the controller should gather/convert/validate/update the values and itself generate the necessary HTML representation.

Advantages and disadvantages should be clear at this point: With a request based MVC framework you need to write more code yourself to achieve the goal. However you end up with much more fine grained control over the process and the HTML/CSS/JS output. With a component based MVC framework you don’t need to write much code yourself. However you have less fine grained control over the process and the HTML/CSS/JS output. So if you’d like to do things a bit differently than the standard describes, you’ll waste a lot more time in a component based MVC framework.

See also:

• Design patterns in Java webapplications
• What are the main disadvantages of JSF 2.0?

http://stackoverflow.com/questions/4801891/difference-between-request-mvc-and-component-mvc

Is a many to many relationship bad? What about this example?

The relationships can be diagrammed as follows:

VIDEO >-- TITLE ---- ACTOR

Where “>--” is a many-to-one relationship and “--<” is one-to-many.

You’re right that a query that joins VIDEO to TITLE_ACTOR, even indirectly via TITLE, is going to match N rows from VIDEO to M rows from TITLE_ACTOR, and the result set will have N*M rows for a given TITLE. That’s a Cartesian product between VIDEO and TITLE_ACTOR, if there are no direct join restrictions between those two tables.

---

Re your comments:

The diagram notation I show can illustrate the difference between a logical many-to-many relationship, and thephysical implementation of that relationship, using an intersection table containing two many-to-one relationships. For example, the logical relationship we’re trying to represent is the following:

       TITLE >---< ACTOR

You might draw your logical data model this way while you’re designing the relationships.

But SQL does not support a way to store a many-to-many relationship. To store it physically in the database, we must use an intersection table:

TITLE ---- ACTOR

For any logical many-to-many relationship, your physical model adds an intersection table and reverses the direction of the arrows. This physical model achieves the same relationship as the logical many-to-many relationship.

Does this mean that on a diagram, that I shouldn’t show a direct relationship from video to title_actor?

Yes, I would consider there to be the following relationships:

• VIDEO references TITLE (M:1)
• TITLE_ACTOR references TITLE (M:1)
• TITLE_ACTOR references ACTOR (M:1)

But there is no direct relationship from VIDEO to TITLE_ACTOR. Only an indirect relationship via TITLE.

The references correspond to foreign key constraints. For example, VIDEO contains a foreign key referencing TITLE, but VIDEO does not contain (and has no need for) a foreign key referencing TITLE_ACTOR.

FWIW, the diagram above is my attempt to make a simple ASCII format of an Entity-Relationship Model.

http://stackoverflow.com/questions/8283793/is-a-many-to-many-relationship-bad-what-about-this-example

Passing parameters from JSP to controller – Spring MVC

Instead of normal buttons you can have submit buttons and handle them in controller as below

  type="submit" value="Developer" name="developer">       
  type="submit" value="Graphic" name="graphic">
  type="submit" value="Cleaner" name="cleaner">

And you can have different methods in the controller class for each of the buttons clicked using the paramsattribute like this

@RequestMapping(value = "/redirect", method = {RequestMethod.POST}, params = "developer")
public ModelAndView developerMethod(){
}

 @RequestMapping(value = "/redirect", method = {RequestMethod.POST}, params = "graphic")
public ModelAndView graphicMethod(){
}

 @RequestMapping(value = "/redirect", method = {RequestMethod.POST}, params = "cleaner")
public ModelAndView cleanerMethod(){
}

http://stackoverflow.com/questions/13977242/passing-parameters-from-jsp-to-controller-spring-mvc