The Sun Java Wireless Toolkit 2.5 for CLDC final version is now available for download, and is it is packed with lots of good stuff, including supported for all the JSRs under the Mobile Services Architecture Specification (MSA):

    * Java Technology for the Wireless Industry (JTWI) (JSR 185)
    * Connected Limited Device Configuration (CLDC) 1.1 (JSR 139)
    * Mobile Information Device Profile (MIDP) 2.0 (JSR 118)
    * PDA Optional Packages for the J2ME Platform (JSR 75)
    * Java APIs for Bluetooth (JSR 82)
    * Mobile Media API (MMAPI) (JSR 135)
    * J2ME Web Services Specification (JSR 172)
    * Mobile 3D Graphics API for J2ME (JSR 184)
    * Wireless Messaging API (WMA) 2.0 (JSR 205)

    (New supported JSRs)
    
    * Mobile Service Architecture (JSR 248)
    * Security and Trust Services API for J2ME (JSR 177)
    * Location API for J2ME (JSR 179)
    * SIP API for J2ME (JSR 180)
    * Content Handler API (JSR 211)
    * Scalable 2D Vector Graphics API for J2ME (JSR 226)
    * Payment API (JSR 229)
    * Advanced Multimedia Supplements (JSR 234)
    * Mobile Internationalization API (JSR 238)
    * Java Binding for the OpenGL(R) ES API (JSR 239)

Awesome...

> Related to this see the article the Mobile Services Architecture Specification which introduces JSR 248 and next generation platform for Java ME devices. See how the pieces of the new platform fit together.

http://subclipse.tigris.org/svn/subclipse/tags/subclipse/1.0.5

• JavaHL 1.4.3 binaries for Windows


• SVNKit 1.1.1


• Removed size from feature.xml. This can prevent install on Vista.


• When file lock failed, we were still flipping the read-only bit.


• Fix potential NPE in SVNStatusSyncInfo (598)


• Modified code to not commit auto-added parents in a separate commit. (599)


• Fixed problem with Import Project Set when there are multiple projects to import.

Resin 3.1.x

Resin 3.1.x is a development branch. New capabilities will be added along with bug fixes for future versions of the Resin 3.1.x branch.

Deployments which need a Resin version with only bug fixes should use the Resin 3.0.x branch.

Servlet 2.5

Resin 3.1 adds Servlet 2.5 support. The Servlet 2.5 specification adds annotation-based injection to servlets, filters, and listeners. Servlets can now mark a field as a @Resource and Resin will assign the configured database, bean, or service to the field, avoiding the need for a JNDI lookup.

package example;

import javax.annotation.Resource;
import javax.servlet.*;
import javax.sql.*;

public class MyServlet extends GenericServlet {
  @Resource(name="jdbc/mysql")
  private DataSource _database;

  public void service(ServletRequest req, ServletResponse res)
  {
     ...
  }
}

Amber capabilities

With Resin 3.1, the JPA features have been reviewed. Amber now provides a near to complete and stable implementation of the JPA specification.

JPA queries are fully supported, including queries with parameters, named queries, and subqueries. The javax.persistence.Query API is also supported, including date/time (temporal) data types.

Embedded properties and optimistic-locking with version fields have been added to Amber in Resin 3.1. Also, inheritance combined with many-to-one, one-to-many, one-to-one, and many-to-many relationships have been reviewed and are now totally stable following the final release of the JPA specification.

Finally, an object relational mapping file (orm.xml) can now be merged together with annotations, when present. In other words, with Resin 3.1, the set of JPA features supported by Amber is near to complete, i.e., only a few unusual features will be added to the next release.

watchdog/startup changes

Resin 3.1 now uses a Java watchdog process to manage Resin instances for reliability. Like the older 3.0 wrapper.pl, it detects if the instance has stopped and restarts it automatically.

Because the watchdog is now a Java process, the Resin start and stop can now use a Java -jar command:

unix> java -jar $RESIN_HOME/lib/resin.jar -server a start

Also, because the Resin instance is started from Java itself, the JVM command-line arguments must now be specified in the resin.conf.

JVM command-line arguments

With Resin 3.1, JVM command-line arguments are specified in the resin.conf. The watchdog JVM will read the resin.conf, select the proper <server>, and apply the server's arguments. As usual, the <server-default> tag can provide common defaults.

  

    
      -Xmx1024m
      -Xss1m
      -verbosegc

Welcome to the 138th edition of The Java(tm) Specialists' Newsletter, where we will look at new features of JDBC 4 that will help you to understand what went wrong with your database queries. I remember cornering Mark Hapner in 1999 when he visited Cape Town and presenting this problem to him. Mark Hapner was the architect for the first JDBC version and went on to architect J2EE and EJB. At the time, there was no easy solution to this problem.

Better SQLExceptions in Java 6

Many years ago, I mentioned in a newsletter that when a SQLException occurs, we do not necessarily know what went wrong. It could be a temporary failure or a permanent fault. The SQL could contain a syntax error (permanent fault) or the database could be rebooting (temporary fault). I promised to write up a newsletter on how to solve this, but never got round to it.

Previously, these faults could be determined by looking at the SQLState contained in the exception. However, I thought that the JDBC driver should do this analysis and give me more specific information about what went wrong.

In JDBC 4.0, which ships as part of JDK 6, we now have a solution that will make it easier to write robust code for communicating with the database.

Instead of just having a single SQLException telling us that there is "a problem", we have three new subclasses, namely SQLNonTransientException, SQLTransientException and SQLRecoverableException. These sub-exceptions are called "categorised exceptions". It can now be possible, if the driver supports JDBC 4, to decide whether we should retry immediately, retry later or give up altogether.

下面是JDBC 4.0规范中关于SQL异常的类结构:

  SQLException
    +---> SQLNonTransientException
    |    +---> SQLDataException
    |    +---> SQLFeatureNotSupportedException
    |    +---> SQLIntegrityConstraintViolationException
    |    +---> SQLInvalidAuthorizationException
    |    +---> SQLNonTransientConnectionException
    |    +---> SQLSyntaxErrorException
    +---> SQLTransientException
    |    +---> SQLTimeoutException
    |    +---> SQLTransactionRollbackException
    |    +---> SQLTransientConnectionException
    +---> SQLRecoverableException
  

The non-transient exceptions represent permanent failures that are the result of some condition that must be corrected before retrying. Simply retrying the query would almost certainly cause it to fail again. Examples are problems with the data, constraint violations (such as with foreign keys) and syntax errors in the actual SQL query.

The transient exceptions are thrown when an error condition might go away within a short time, without changing any application logic. A typical exception here is the transient SQL connection. However, I have found in my example that I had to start a new connection if we got this exception. With a transient exception, this should typically not be necessary. A good example of a transient exception is when a deadlock occurs in the database, which will cause a SQLTransactionRollbackException.

The recoverable exception means that it might succeed if the application does some recovery steps and then retries the transaction. This will require to at least close the connection and to open a new one.

Apache Derby

Another "feature" with the JDK 6 (not JRE 6) is that it ships standard with the Derby embedded database. I have still not met anyone who thinks this is a good idea. However, it is nice to be able to immediately start testing these new exceptions without having to find the correct drivers for your database.

However, before I show you the test code, there was another annoying problem with database connections in the past. You did not know whether they were still active, unless you sent down a "known good query". This could be something as simple as "SELECT 1". However, if you added a caching JDBC driver, it could happen that the answer would come back immediately for something as simple as that.

Since Java 6, we now have a standard mechanism for checking connectivity to the database. We can call the isValid(int timeout) method on a connection. This sends through a known good query and if it does not get a response within the given timeout (in seconds), then we know that the database connection is not valid anymore.

To run the DbTest below, all you need to do is make sure that the derby.jar file is in your classpath. This file is now in your JDK6/db/lib directory. Note that you do not need to do Class.forName() to load the driver - another feature of JDBC 4. How that works, is left as an exercise to the reader :-)

import java.sql.*;

public class DbTest {
  private final static String dburl = "jdbc:derby:tjsnTest";

  public static void main(String[] args) throws SQLException {
    Connection con = getNewConnection();
    Statement s = con.createStatement();

    try {
      s.execute("hello world - this should not work");
    } catch (SQLSyntaxErrorException ex) {
      System.out.println("Permanent problem with syntax");
    }

    s.execute("create table testTable(id int, name varchar(10))");
    try {
      s.execute("insert into testTable values (1, 'Heinz Kabutz')");
    } catch (SQLDataException ex) {
      System.out.println("Permanent problem with the data input");
    }

    System.out.println("Is connection valid? " + con.isValid(10));

    shutdownDB();

    System.out.println("Is connection valid? " + con.isValid(10));

    try {
      s.execute("drop table testTable");
    } catch (SQLTransientConnectionException ex) {
      System.out.println("Temporary problem connecting to db");
    }

    // restarting the database
    con = getNewConnection();
    s = con.createStatement();
    try {
      s.execute("drop table testTable");
    } catch (SQLTransientConnectionException ex) {
      System.out.println("Temporary problem connecting to db");
    }

    try {
      s.executeQuery("SELECT id, name FROM testTable");
    } catch (SQLSyntaxErrorException ex) {
      System.out.println("Permanent syntax problem with query");
    }
  }

  // shutting down the database
  private static void shutdownDB() throws SQLException {
    try {
      DriverManager.getConnection(dburl + ";shutdown=true");
    } catch (SQLTransientConnectionException ex) {
      // this should not happen - but it does ...
      System.out.println("Temporary problem connecting to db");
    }
  }

  private static Connection getNewConnection() throws SQLException {
    return DriverManager.getConnection(dburl + ";create=true");
  }
}
  

You should be able to run the program quite easily, like this:

    java -cp %JDK_HOME%/db/lib/derby.jar;. DbTest

    Permanent problem with the data input
    Is connection valid? true
    Temporary problem connecting to db
    Is connection valid? false
    Temporary problem connecting to db
    Permanent syntax problem with query
  

This is all very nice, but something like this should have been available in Java 1.0. To now go back and fix all the legacy code is just not practical. New code is usually done with the Java Persistence API, not direct JDBC calls. Still, I am pleased to see this finally being added to JDBC.(转载)

The Velocity Tools developers are pleased to announce the first beta release of Velocity Tools 1.3. You may download it here.

• Changed VelocityViewServlet to look for toolbox config at "/WEB-INF/toolbox.xml" and velocity init properties at "/WEB-INF/velocity.properties" when no other locations are specified (i.e. change the standard location into a convention to reduce configuration needs). (ndb)
• Upgraded VelocityStruts dependencies to those for Struts 1.3.x series and updated "struts" example app according to provided directions. (ndb)
• Replaced "layout" example with new "showcase" example to interactively demonstrate all tools and the VelocityLayoutServlet. (ndb)
• Added auto() and manual() methods to AlternatorTool and deprecated the make() methods that took a boolean parameter. (ndb)
• Added getAll() method to ParameterParser to retrieve map of all params via $params.all. (ndb)
• Added configurable getSelf() function to LinkTool to make self-referencing links easier. (ndb)
• Added create() methods to CookieTool to support more complex Cookie creation. (ndb)
• Added ContextTool for convenient access to context data and meta-data. (ndb)
• VELTOOLS-71: Overhauled ant build process: dependencies are now automatically download, jars have manifests, checksums are auto-generated, and more. Also, building with JDK 1.3 is no longer supported. (ndb)
• Updated license headers and notices to comply with new ASF policy. (henning)
• Made auto-alternate default of AlternatorTool configurable via toolbox config. (ndb)
• Add addQueryData(Map) and params(Map) method to LinkTool. Thanks to Mark Brunkhart for this. (ndb)
• VELTOOLS-56: Fixed a number of problems with ImportSupport. Thanks to Christopher Schultz for this. (ndb)
• VELTOOLS-67: Add ability to restrict availability of request-scoped tools according to a request path value set in the tool configuration. Thanks to Claude Brisson for this. (ndb)
• VELTOOLS-68: Change VelocityViewServlet to read logger and resource loader config from velocity.properties file instead of hard-coding it. (henning)
• Added setAbsolute() and absolute() methods to LinkTool. (ndb)
• Made default format of DateTool configurable via toolbox definition. (ndb)
• Deprecated ViewTool and Configurable interfaces. ViewToolInfo has been enhanced to automatically recognize such tools by checking for init(Object) and/or configure(Map) methods. (ndb)
• Enhanced TextKey trick in MessageTool to make using args and bundles easier. (ndb)
• Add getInteger() and getDouble() convenience methods to ValueParser. (ndb)
• Added get() method to StrutsLinkTool to allow syntax like $link.action.saveFoo. (ndb)
• Added param(), relative(), anchor(), and uri() convenience methods to LinkTool. (ndb)
• Added currency(), number(), integer(), and percent() convenience methods to NumberTool. (ndb)
• Changed auto-alternate default in AlternatorTool to match Alternator default.

The Mylar plugin for Eclipse (available for versions 3.1 and 3.2M3 only) is, without doubt, one of the most innovative ways to change out interaction with IDEs.

Let's see a typical example of our daily work on Java project. You get a task, which can be an enhancement, new feature or bug fix. Typically, you have your project as a tree on the left-hand side, along with the list of all methods / fields (either as sub-branches of the project tree or as a separate tree). When you need to view or change source code, you either locate the corresponding entry in the project tree, or use one of the many shortcuts (such as Ctrl+Shift+T in Eclipse) to locate that class. Typically, you will need to access a number of classes, with a couple of methods in each one of them. Now, consider what happens in an existing project.

You have hundreds (if not thousands) of classes in tens of packages, each class having quite a few functions (depending on the previous team members, it can get to hundreds). The classes that you need to change for a particular bug fix are most likely under different packages. When you need to go back and forth between these classes, you waste valuable time (and energy) to do so. Wouldn't it be nice to have a context view of your workspace. This view would contain only relevant branches of the project tree, the classes you are working on and the methods that you are changing. Ideally, the IDE itself would track the changes you are making to the codebase, continually updating the context view. Mylar plugin for Eclipse does exactly that.

Here are few screenshots that show the differences (before and after applying Mylar):

作者 徐永久   

本文是我在工作中调整 Solaris 8 上的 WebLogic 6.0SP2 中遇到诸多问题后，查阅相关资料而产生的一些概念，罗列出来，或许对您有所帮助。这并不代表，笔者推荐您使用 WebLogic 和 Solaris 的组合，相反，笔者欢迎相关 Tomcat 性能调整方面的心得。笔者在 Sun Tech Day 上和 Bea 公司的相关人员讨论后，认为 Bea 对 Open Source 和 Free Software 缺乏必要的远见。

另外，其中一些术语的翻译，是我自己的”创作“，我不知道别人是怎样翻译的。如果有不当的地方，希望指正。

import java.sql.*;
import java.io.*;
import java.util.regex.*;

public class test{
public static void main(String[] args){
try{
String s = "";
while(!s.equals("q")){
System.out.print("input:");
DataInputStream in = new DataInputStream(new BufferedInputStream(System.in));
s = in.readLine();
System.out.println("your input is :"+s);
String check = "^([a-z0-9A-Z]+[-|\\.]?)+[a-z0-9A-Z]@([a-z0-9A-Z]+(-[a-z0-9A-Z]+)?\\.)+[a-zA-Z]{2,}$";
Pattern regex = Pattern.compile(check);
Matcher matcher = regex.matcher(s);
boolean isMatched = matcher.matches();
if(isMatched){
System.out.println("it's a email");
}else{
System.out.println("it's not a email");
}

}
}catch(Exception e){
System.out.println("error"+e.getMessage());
}
}
}

Object类是所有类的超类，也就是说，Java中的每一个类都是由Object扩展而来的。因而每当你创建一个对象，它都将拥有Object类中的全部方法。让我们先来看看java.lang.Object的中的主要方法有哪些：

public class Object{
//公共构造函数
public Object();
//公共实例方法
public boolean equals(Object obj);
public native int hashCode();
public final native Class getClass();
public String toString();
public final native void notify();
public final native void notifyAll();
public final void wait() throws InterruptedException;
public final native void wait(long timeout) throws InterruptedException;
public final void wait(long timeout, int nanos) throws InterruptedException;
//保护实例方法
protected native Object clone();
protected void finalize() throws Throwable; }

方法equals测试的是两个对象是否相等，方法clone进行对象拷贝，方法getClass返回和当前对象相关的Class对象，方法notify,notifyall,wait都是用来对给定对象进行线程同步的。

然而Object类所提供的只是一些基本的方法，我们在编写自己的类时经常需要覆盖这些方法，一方面是加强功能，另一方面也是为了适应当前的情况。这就引出了本文的主题――