• Easy to use APIs for developing web service clients.
• Mix scripting and Java in your code. Javascript comes as standard, you can add many more languages.
• Updated JDBC 4.0 APIs, and an all-Java JDBC database included in the JDK.
• Programmatically control the javac compiler.
• Define your own annotations and plug in the code to process them.
• Double digit improvements in performance, client and server. 100,000+ tests for compatibility alone.
• 
  

demo's

http://www.jetbrains.com/idea/training/demos/struts.html

SQL

AND / OR
SELECT column_name(s)FROM table_nameWHERE conditionANDOR condition
ALTER TABLE (add column)
ALTER TABLE table_name ADD column_name datatype
ALTER TABLE (drop column)
ALTER TABLE table_name DROP COLUMN column_name
AS (alias for column)
SELECT column_name AS column_aliasFROM table_name
AS (alias for table)
SELECT column_nameFROM table_name AS table_alias
BETWEEN
SELECT column_name(s)FROM table_nameWHERE column_nameBETWEEN value1 AND value2
CREATE DATABASE
CREATE DATABASE database_name
CREATE INDEX
CREATE INDEX index_nameON table_name (column_name)
CREATE TABLE
CREATE TABLE table_name(column_name1 data_type,column_name2 data_type,.......)
CREATE UNIQUE INDEX
CREATE UNIQUE INDEX index_nameON table_name (column_name)
CREATE VIEW
CREATE VIEW view_name ASSELECT column_name(s)FROM table_nameWHERE condition
DELETE FROM
DELETE FROM table_name (Note: Deletes the entire table!!)
or
DELETE FROM table_nameWHERE condition
DROP DATABASE
DROP DATABASE database_name
DROP INDEX
DROP INDEX table_name.index_name
DROP TABLE
DROP TABLE table_name
GROUP BY
SELECT column_name1,SUM(column_name2)FROM table_nameGROUP BY column_name1
HAVING
SELECT column_name1,SUM(column_name2)FROM table_nameGROUP BY column_name1HAVING SUM(column_name2) condition value
IN
SELECT column_name(s)FROM table_nameWHERE column_nameIN (value1,value2,..)
INSERT INTO
INSERT INTO table_nameVALUES (value1, value2,....)
or
INSERT INTO table_name(column_name1, column_name2,...)VALUES (value1, value2,....)
LIKE
SELECT column_name(s)FROM table_nameWHERE column_nameLIKE pattern
ORDER BY
SELECT column_name(s)FROM table_nameORDER BY column_name [ASCDESC]
SELECT
SELECT column_name(s)FROM table_name
SELECT *
SELECT *FROM table_name
SELECT DISTINCT
SELECT DISTINCT column_name(s)FROM table_name
SELECT INTO(used to create backup copies of tables)
SELECT *INTO new_table_nameFROM original_table_name
or
SELECT column_name(s)INTO new_table_nameFROM original_table_name
TRUNCATE TABLE(deletes only the data inside the table)
TRUNCATE TABLE table_name
UPDATE
UPDATE table_nameSET column_name=new_value[, column_name=new_value]WHERE column_name=some_value
WHERE
SELECT column_name(s)FROM table_nameWHERE condition

JAXBContext

Class JAXBContext

java.lang.Object
 javax.xml.bind.JAXBContext 

---

public abstract class JAXBContext

extends java.lang.Object

The JAXBContext class provides the client's entry point to the JAXB API. It provides an abstraction for managing the XML/Java binding information necessary to implement the JAXB binding framework operations: unmarshal, marshal and validate. A client application obtains new instances of this class via the newInstance(contextPath) method.

     JAXBContext jc = JAXBContext.newInstance( "com.acme.foo:com.acme.bar" );

The contextPath contains a list of Java package names that contain schema derived interfaces. The value of this parameter initializes the JAXBContext object so that it is capable of managing the schema derived interfaces.

SPEC REQUIREMENT: the provider must supply an implementation class containing a method with the following signature:

        public static JAXBContext createContext( String contextPath, ClassLoader classLoader )
           throws JAXBException;

JAXB Providers must generate a jaxb.properties file in each package containing schema derived classes. The property file must contain a property named javax.xml.bind.context.factory whose value is the name of the class that implements the createContext API.

The class supplied by the provider does not have to be assignable to javax.xml.bind.JAXBContext, it simply has to provide a class that implements the createContext API.

In addition, the provider must call the DatatypeConverter.setDatatypeConverter api prior to any client invocations of the marshal and unmarshal methods. This is necessary to configure the datatype converter that will be used during these operations.

Unmarshalling

The Unmarshaller class provides the client application the ability to convert XML data into a tree of Java content objects. The unmarshal method for a schema (within a namespace) allows for any global XML element declared in the schema to be unmarshalled as the root of an instance document. The JAXBContext object allows the merging of global elements across a set of schemas (listed in the contextPath). Since each schema in the schema set can belong to distinct namespaces, the unification of schemas to an unmarshalling context should be namespace independent. This means that a client application is able to unmarshal XML documents that are instances of any of the schemas listed in the contextPath. For example:

        JAXBContext jc = JAXBContext.newInstance( "com.acme.foo:com.acme.bar" );
       Unmarshaller u = jc.createUnmarshaller();
       FooObject fooObj = (FooObject)u.unmarshal( new File( "foo.xml" ) ); // ok
       BarObject barObj = (BarObject)u.unmarshal( new File( "bar.xml" ) ); // ok
       BazObject bazObj = (BazObject)u.unmarshal( new File( "baz.xml" ) ); // error, "com.acme.baz" not in contextPath

The client application may also generate Java content trees explicitly rather than unmarshalling existing XML data. To do so, the application needs to have access and knowledge about each of the schema derived ObjectFactory classes that exist in each of java packages contained in the contextPath. For each schema derived java class, there will be a static factory method that produces objects of that type. For example, assume that after compiling a schema, you have a package com.acme.foo that contains a schema derived interface named PurchaseOrder. In order to create objects of that type, the client application would use the factory method like this:

       com.acme.foo.PurchaseOrder po =
          com.acme.foo.ObjectFactory.createPurchaseOrder();

Once the client application has an instance of the the schema derived object, it can use the mutator methods to set content on it.

For more information on the generated ObjectFactory classes, see Section 4.2 Java Package of the specification.

SPEC REQUIREMENT: the provider must generate a class in each package that contains all of the necessary object factory methods for that package named ObjectFactory as well as the static newInstance( javaContentInterface ) method

Marshalling

The Marshaller class provides the client application the ability to convert a Java content tree back into XML data. There is no difference between marshalling a content tree that is created manually using the factory methods and marshalling a content tree that is the result an unmarshal operation. Clients can marshal a java content tree back to XML data to a java.io.OutputStream or a java.io.Writer. The marshalling process can alternatively produce SAX2 event streams to a registered ContentHandler or produce a DOM Node object.

Here is a simple example that unmarshals an XML document and then marshals it back out:

        JAXBContext jc = JAXBContext.newInstance( "com.acme.foo" );

       // unmarshal from foo.xml
       Unmarshaller u = jc.createUnmarshaller();
       FooObject fooObj = (FooObject)u.unmarshal( new File( "foo.xml" ) );

       // marshal to System.out
       Marshaller m = jc.createMarshaller();
       m.marshal( fooObj, System.out );

Validation

There are three varieties of validation available to JAXB client applications:

Unmarshal-time Validation

Validation performed on the XML data as it is being unmarshalled into a Java content tree

On-Demand Validation

Validation performed on the Java content tree in memory

Fail-Fast Validation

Validation of Java property constraints at runtime when client applications invoke the setter methods of the generated classes

See: Validator javadocs for a more detailed definition of the different type of validation.

Although unmarshal-time validation and on-demand validation are very similar, they are completely orthogonal operations with no dependencies on each other. Client applications are free to use one, both, or neither types of validation.

Validation errors and warnings encountered during the unmarshal and validate operations are reported to the client application via a callback error handler interface (ValidationEventHandler) that receives ValidationEvent objects. The ValidationEvent objects contain information about the error or warning encountered. JAXB allows a few diffent methods of handling validation events which are described in more detail in the Validator javadoc.

JAXB Runtime Binding Framework Compatibility

Since the JAXB Specification does not define a common runtime system, a JAXB client application must not attempt to mix runtime objects (JAXBContext, Marshaller, etc. ) from different providers. This does not mean that the client application isn't portable, it simply means that a client has to use a runtime system provided by the same provider that was used to compile the schema.

java coding examples

http://www.java2s.com/

Dynamic sorting

import java.util.Comparator;
public class BeanPropertyComparator implements Comparator {
private String property;
private Comparator comparator;
public BeanPropertyComparator(String property, Comparator comparator) {
this.property = property;
this.comparator = comparator;
}
public int compare(Object bean1, Object bean2) {
// Get the value of the properties
Object value1 = BeanPropertyUtil.getProperty(property,bean1);
Object value2 = BeanPropertyUtil.getProperty(property,bean2);
return comparator.compare(value1,value2);
}
}

Dynamic sorting

http://java.sys-con.com/read/45837.htm