The Auto Commit setting is enabled by default and can be adjusted in the Connection Properties. You may also adjust the  auto commit state for the SQL editor you are using in the SQL Commander with the following command:

@set autocommit true/false

Unfortunately this didn’t work for  me in either 6.5.12 or 7.04 (I’m using OS X and Java 6) against an Oracle 10g database. I get an error alert stating “/application/set autocommit false (No such file or directory)”
I was finally able to figure out that you can get it to work using:

@set autocommit off/on

I’m not sure if this is a problem that only occur on OS X.

Related posts:

1. SQL*Loader-522: lfiopn failed for file (loader.log)

table { width:100%; border:1px solid #e5eff8; margin:1em auto; border-collapse:collapse; } th { color:#678197; border: 1px solid #e5eff8; padding: 2px; text-align:center; font-weight: bold; text-align: left; } td { color:#678197; border:1px solid #e5eff8; padding: 2px; text-align:left; }

A handy list for Java data types and sizes

Integer Data Types

Floating Point Data Types

Boolean Data Types

Character Data Types

Default Values

References:
http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html

Related posts:

1. Java and the current work directory

In a project you may have dependencies on libraries like Log4J or Freemarker. These libraries in their turn may have dependencies on other libraries, this is also known as transitive dependencies.

Using the following Maven command we’ll be able to see a list of these dependencies:

mvn dependency:resolve

For a nice tree view of the same information use:

mvn dependency:tree

If you want to see a full dependency trail that also show you artifacts that were rejected due to conflicts or other reasons then run maven with the debug flag enabled:

mvn install -X

For more information about the Maven dependency plugin go here: http://maven.apache.org/plugins/maven-dependency-plugin/

Related posts:

1. Want to use Spring 3.0 milestone release from Maven?
2. Maven, Log4j and javax.jms
3. Maven pom.xml structure

For the full explanation check out the link to “Spring/Maven Repositories” link in the bottom. For a quick 1-2-3 step solution add this to the <repositories> section in your Maven pom.xml file so that Maven can find Spring’s early access milestone releases:

<repository>
  <id>spring-milestone</id>
  <name>Spring Portfolio Milestone Repository</name>
  <url>http://s3.amazonaws.com/maven.springframework.org/milestone</url>
</repository>

<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-core</artifactId>
  <packaging>jar</packaging>
  <version>3.0.0.M4</version>
</dependency>

Related posts:

1. Maven, Log4j and javax.jms
2. How to find project dependencies in a Maven project
3. Maven pom.xml structure

assertEquals(12345, result.getValue());

And when you try to compile your project it produces a compilation error like this:

/projects/myapp/src/test/java/org/myapp/MyTest.java:[88,8] reference to assertEquals is ambiguous, both method assertEquals(double,double) in org.junit.Assert and method assertEquals(java.lang.Object,java.lang.Object) in org.junit.Assert match

Since JUnit offer several methods that are very similar the compiler can not always determine which one to use. In our case we have the number 12345 which is an int and result.getValue() which is an Integer. You’d think that the compiler could figure out to convert the number 12345 to an Integer object which would give us a match on “assertEquals(java.lang.Object, java.lang.Object) method, but instead it throws the above error.

The reason for this is that Java uses best match to try to determine the method that will require the least conversion of the parameters. In this case one method requires boxing, and the other method would require un-boxing. Both of these methods have equal priority and that’s why there is ambiguity since none of the methods are more specific than the other.

The solution is to help the compiler determine what it need to do. We can do that using this:

assertEquals(12345, (int) result.getValue());

or this:

assertEquals((Integer)12345, result.getValue());

to resolve this problem. The second solution that converts 12345 to an Integer object is most likely the better once since Java will auto-box a null value to the number 0 which may not be the correct behavior for the class you’re testing.

Related posts:

1. Java primitive data type sizes for byte, short, int, long, float, double and char

<bean id="some-bean-id" class="some-class">
    <property name="my-property-name" value="\n"/>
</bean>

This simply wont work. You’ll end up with a backslash followed by the letter n. What you have to do is to use an escape character like this

<bean id="some-bean-id">
    <property name="my-property-name" value="&#10;"/>
</bean>

Related posts:

1. Want to use Spring 3.0 milestone release from Maven?

[INFO] Unable to find resource 'com.sun.jmx:jmxri:jar:1.2.1' in repository central (http://repo1.maven.org/maven2)
[INFO] Unable to find resource 'com.sun.jdmk:jmxtools:jar:1.2.1' in repository central (http://repo1.maven.org/maven2)
[INFO] Unable to find resource 'javax.jms:jms:jar:1.1' in repository central (http://repo1.maven.org/maven2)

These packages are not in the Maven repositories due to licensing issues. There are two simple solutions to this problem. You can either modify your pom.xml file to use the previous version of log4j (log4j 1.2.14) which doesn’t depend on the JMX and JMS packages:

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.14</version>
</dependency>

Or you can exclude the dependencies with the caveat that some of the lo4gj appenders  that depend on these packages wont be available

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.15</version>
    <exclusions>
        <!--
        These packages are not in the Maven repository
        If you do this certain log4j appenders will not be available
        -->
        <exclusion>
            <groupId>javax.jms</groupId>
            <artifactId>jms</artifactId>
        </exclusion>
        <exclusion>
            <groupId>com.sun.jdmk</groupId>
            <artifactId>jmxtools</artifactId>
        </exclusion>
        <exclusion>
            <groupId>com.sun.jmx</groupId>
            <artifactId>jmxri</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Related posts:

1. Want to use Spring 3.0 milestone release from Maven?
2. How to find project dependencies in a Maven project
3. Maven pom.xml structure

SET logfile=/location/to/my/log/file.log

or

java -Dlogfile=/location/to/my/log/file.log HelloWorld

When you want to access these environment variables from your Java source file you can use

Java 1.5 and newer:

String logfileLocation = System.getenv("logfile");

Java 1.4 and older:

String logfileLocation = System.getProperty("logfile");

Related posts:

1. Java and the current work directory

You can just enter the name of the class or JAR file your looking for and the site will display the result.

http://www.findjar.com/index.jsp

Related posts:

1. JUnit 4 error: reference to assertEquals is ambiguous

context.checking(new Expectations() {{
    oneOf (department).employees(); will(returnIterator(employees));
}});

In Mockito the equivalent code would look like this

when(department.employees()).thenReturn(employees);

I find the Mockito syntax to be easier to write and understand. I’ve seen fellow developers implement JMock expectations in a way where they actually didn’t perform a useful test, and I think the sometimes confusing syntax of JMock was the reason. I’m not dismissing JMock as an inferior mocking framework, but I do think that the learning curve is a bit steeper. If you haven’t used Mockito yet I encourage you to take a look at it.

No related posts.