NoClassDefFoundError exception in your Maven project

After you have added a new dependency, you could have exception like this:

NetBeans error:

--- exec-maven-plugin:1.2.1:exec (default-cli) @ integration ---
java.lang.NoClassDefFoundError: path/to/the/class/ClassName
    at java.lang.Class.getDeclaredMethods0(Native Method)
    at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
    at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
    at java.lang.Class.getMethod0(Class.java:3018)
    at java.lang.Class.getMethod(Class.java:1784)
    at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
    at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
Caused by: java.lang.ClassNotFoundException: package.ClassName
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 7 more

IntellijIdea error:

JAXB: Marshalling kickstart blank template application

This is a simple JAXB application, that could be used as template. It has console (and file) output.

import java.io.File;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Marshaller;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlAttribute;

@XmlRootElement
public class Test {
    String name;
    int age;
    int id;

    public String getName() {
        return name;
    }

    @XmlElement
    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    @XmlElement
    public void setAge(int age) {
        this.age = age;
    }

    public int getId() {
        return id;
    }

    @XmlAttribute
    public void setId(int id) {
        this.id = id;
    }



    public static void main(String[] args) {

        Test test = new Test();
        test.setId(100);
        test.setName("Tim Rott");
        test.setAge(29);

        try {

//            File file = new File("C:\\file.xml");
            JAXBContext jaxbContext = JAXBContext.newInstance(Test.class);
            Marshaller jaxbMarshaller = jaxbContext.createMarshaller();

            // output pretty printed
            jaxbMarshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);

//            jaxbMarshaller.marshal(test, file);
            jaxbMarshaller.marshal(test, System.out);

        } catch (JAXBException e) {
            e.printStackTrace();
        }

    }
}

JAXB: Generate schema and generate Java class

You could easily generate .xsd file from java model class and vice versa.

Generate the schema

Lets have a model class as follows:

@XmlRootElement(name="product")
@XmlAccessorType(XmlAccessType.FIELD)
public class Product {

    @XmlElement(required=true) 
    protected int id;
    @XmlElement(required=true) 
    protected String name;
    @XmlElement(required=true) 
    protected String description;
    @XmlElement(required=true) 
    protected int price;
    
    public Product() {}
    
    // Getter and setter methods
    // ...
}

Run the JAXB schema generator on the command line to generate the corresponding XML schema definition:

schemagen Product.java

This command produces the XML schema as an .xsd file.

Generate Java class

Lets have schema definition in .xsd file:

<?xml version="1.0"?>
<xs:schema targetNamespace="http://xml.product" 
           xmlns:xs="http://www.w3.org/2001/XMLSchema"    
           elementFormDefault="qualified"
           xmlns:myco="http://xml.product">

  <xs:element name="product" type="myco:Product"/>

  <xs:complexType name="Product">
    <xs:sequence>
      <xs:element name="id" type="xs:int"/>
      <xs:element name="name" type="xs:string"/>
      <xs:element name="description" type="xs:string"/>
      <xs:element name="price" type="xs:int"/>
    </xs:sequence>
  </xs:complexType>
</xs:schema>

Run the schema compiler tool on the command line as follows:

xjc Product.xsd

This will produce the following class:

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "Product", propOrder = {
    "id",
    "name",
    "description",
    "price"
})
public class Product {
    protected int id;
    @XmlElement(required = true)
    protected String name;
    @XmlElement(required = true)
    protected String description;
    protected int price;

    // Setter and getter methods
    // ...
}

Source

Source: https://docs.oracle.com/javaee/6/tutorial/doc/gkknj.html

IF operator alternative in JPQL

JPQL (and dialects as HQL) does not support IF operator/function, but the same functionality could be built with CASE construction:

CASE
    WHEN condition_1 THEN
         ...
    [WHEN condition_n THEN]
         ...
    ELSE
         ... 
END

Example:

SELECT e.name, 

  CASE 

    WHEN (e.salary >= 100000) THEN 1 

    WHEN (e.salary < 100000) THEN 2 

    ELSE 0  

  END 

FROM Employee e;

MySQL Data Engines comparison - MyIsam Vs Innodb Vs Memory

Feature	MyISAM	InnoDB	Memory
ACID Transaction ACID - Atomicity, Consistency, Isolation, Durability (read more on it here: http://en.wikipedia.org/wiki/ACID)	No	Yes	No
Configurable ACID Properties	No	Yes	No
Crash Safe	No	Yes	No (RAM)
Foreign Key Support	No	Yes	No
Multi Version Concurrency Control (MVCC)	No	Yes	No
Geospatial datatype	Yes	Yes	No
Geospatial indexing	Yes	No	No
Full-text Search Index	Yes	No	No
Data Cache	No	Yes	N/A
Compressed Data	Yes	Yes	No
Storage Limits	256TB	64TB	RAM
Storage Cost	Low	High	N/A
Memory Cost	Low	High	Medium
Locking Granularity	Table	Row	Table

MyISAM:
The MyISAM storage engine in MySQL.

• Simpler to design and create, thus better for beginners. No worries about the foreign relationships between tables.

A Windows editor for huge files - PilotEdit

PilotEdit is nice Windows editor for huge files.

There is two versions:
 - normal (paid with trial) and 
 - lite (free)

http://www.pilotedit.com/index.php?option=com_content&view=section&layout=blog&id=8&Itemid=56

Get extended EXPLAIN profiling data in MySQL

As always with a slow query, finding the execution plan with EXPLAIN is the 1st step to understand where time is spent.

For extended profiling information, SHOW PROFILE can be used: 

mysql> set @@profiling = 1;
mysql> SELECT ....;
mysql> SHOW PROFILE;
+--------------------+----------+
| Status             | Duration |
+--------------------+----------+
| starting           | 0.000783 |
| Opening tables     | 0.000192 |
| System lock        | 0.000005 |
| Table lock         | 0.000010 |
| init               | 0.000369 |
| optimizing         | 0.000091 |
| statistics         | 3.459529 |
| preparing          | 0.000213 |
| executing          | 0.000005 |
| Sending data       | 0.004597 |
| end                | 0.000008 |
| query end          | 0.000005 |
| freeing items      | 0.000066 |
| logging slow query | 0.000004 |
| cleaning up        | 0.000006 |
+--------------------+----------+

Source: https://www.percona.com/blog/2014/03/06/many-table-joins-mysql-5-6/

JPA Cache behavior with JPQL Update and Delete queries

JPA experience desynchronization between read data and cache while executing modifying queries. Even in the same application. It is helpful to know JPA behavior to avoid cache issues.

In short

Update queries: Lets have an update statement, which will update all rows in the database (no where cause). It will be executed on the database itself only - updating first level cache and second level cache will not be executed. Next time you access some row via that cache, you will get the old value (if the cache has not been invalidated because of timeout).

Delete queries: deleting all rows with JPQL will result removing them from database but they will stay in both caches.

1st Level Cache

If you bypass JPA and execute DML directly on the database, either through native SQL queries, JDBC, or JPQL UPDATE or DELETE queries, then the database can be out of synch with the 1st level cache. If you had accessed objects before executing the DML, they will have the old state and not include the changes. Depending on what you are doing this may be ok, otherwise you may want to refresh the affected objects from the database.

The 1st level, or EntityManager cache can also span transaction boundaries in JPA. A JTA managed EntityManager will only exist for the duration of the JTA transaction in JEE. Typically the JEE server will inject the application with a proxy to an EntityManager, and after each JTA transaction a new EntityManager will be created automatically or the EntityManager will be cleared, clearing the 1st level cache. In an application managed EntityManager, the 1st level cache will exist for the duration of the EntityManager. This can lead to stale data, or even memory leaks and poor performance if the EntityManager is held too long. This is why it is generally a good idea to create a new EntityManager per request, or per transaction. The 1st level cache can also be cleared using the EntityManager.clear() method, or an object can be refreshed using the EntityManager.refresh() method.

2nd Level Cache

 If the application is the only application and server accessing the database there is little issue with the 2nd level cache, as it should always be up to date. The only issue is with DML, if the application executes DML directly to the database through native SQL queries, JDBC, or JPQL UPDATE or DELETE queries. JPQL queries should automatically invalidate the 2nd level cache, but this may depend on the JPA provider. If you use native DML queries or JDBC directly, you may need to invalidate, refresh or clear the objects affected by the DML.

If there are other applications, or other application servers accessing the same database, then stale data can become a bigger issue. Read-only objects, and inserting new objects should not be an issue. New objects should get picked up by other servers even when using caching as queries typically still access the database. It is normally only find() operations and relationships that hit the cache. Updated and deleted objects by other applications or servers can cause the 2nd level cache to become stale.

For deleted objects, the only issue is with find() operations, as queries that access the database will not return the deleted objects. A find() by the object's Id could return the object if it is cached, even if it does not exist. This could lead to constraint issues if you add relations to this object from other objects, or failed updates, if you try to update the object. Note that these can both occur without caching, even with a single application and server accessing the database. During a transaction, another user of the application could always delete the object being used by another transaction, and the second transaction will fail in the same way. The difference is the potential for this concurrency issue to occur increases.

For updated objects, any query for the objects can return stale data. This can trigger optimistic lock exceptions on updates, or cause one user to overwrite another user's changes if not using locking. Again note that these can both occur without caching, even with a single application and server accessing the database. This is why it is normally always important to use optimistic locking. Stale data could also be returned to the user.

Refreshing

Refreshing is the most common solution to stale data. Most application users are familiar with the concept of a cache, and know when they need fresh data and are willing to click a refresh button. This is very common in an Internet browser, most browsers have a cache of web pages that have been accessed, and will avoid loading the same page twice, unless the user clicks the refresh button. This same concept can be used in building JPA applications. JPA provides several refreshing options, see refreshing.

Some JPA providers also support refreshing options in their 2nd level cache. One option is to always refresh on any query to the database. This means that find() operations will still access the cache, but if the query accesses the database and brings back data, the 2nd level cache will be refreshed with the data. This avoids queries returning stale data, but means there will be less benefit from caching. The cost is not just in refreshing the objects, but in refreshing their relationships. Some JPA providers support this option in combination with optimistic locking. If the version value in the row from the database is newer than the version value from the object in the cache, then the object is refreshed as it is stale, otherwise the cache value is returned. This option provides optimal caching, and avoids stale data on queries. However objects returned through find() or through relationships can still be stale. Some JPA providers also allow find() operation to be configured to first check the database, but this general defeats the purpose of caching, so you are better off not using a 2nd level cache at all. If you want to use a 2nd level cache, then you must have some level of tolerance to stale data.

Source: https://en.wikibooks.org/wiki/Java_Persistence/Caching