Stephan Schwab - java tag

Sun offers support for Java 1.4 for the next 15 years

Sat, 12 Apr 2008 00:22:28 GMT

As a paid support offering for enterprise customers Sun now offers up to 15 years of support per Java SE family. Basically that means you could buy support for the Java 1.4 JVM and JDK for the next 15 years according to this press release.

Sun Releases Java Platform Standard Edition For Business:
Java SE for Business is designed for customers looking for longer, more predictable support for the platform - up to 15 years per family. Sun will also continue to support the latest non-subscription release of Java SE, at no cost, and deliver three years of quarterly maintenance updates per release family.

Some people have been dubbed Java the new COBOL (1, 2, 3, 4, 5). Looks to me that there were not mistaken ;-)

Is Java 6 really ready?

Thu, 01 Nov 2007 21:04:30 GMT

Ok... Now it's getting ugly with the Java 6 VM on Ubuntu Linux:

java.lang.OutOfMemoryError: PermGen space
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xb48d24d3, pid=4758, tid=3075954368
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing)
# Problematic frame:
# C  [libswt-pi-gtk-3346.so+0x2e4d3]  Java_org_eclipse_swt_internal_gtk_OS_GTK_1ACCEL_1LABEL_1GET_1ACCEL_1STRING+0x6
#
# An error report file with more information is saved as hs_err_pid4758.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted (core dumped)

Java and Mac OS X: it's all about priorities

Thu, 01 Nov 2007 05:04:07 GMT

To most users Mac OS X is a desktop operating system. It has Unix under the hood, but the most important part that distinguishes Darwin (the FreeBSD variant) from Mac OS X is the user interface and the applications one can build by using libraries such as Cocoa and others.

Now apparently Apple has done a number of improvements for the Java 5 VM and JDK libraries to allow Java developers to write equally compelling desktop applications in their language of choice. That makes sense and is a good thing.

Server side Java developers and people interested in the bleeding edge can always use tools like Parallels or VMware Fusion to run another operating system (Windows, Linux or Solaris) to get access to the latest Java VM whether it is experimental or short after Sun releases a first production version. So it's not a matter of whether Java gets abandoned by Apple or not. It's simply a matter of where the priorities are. To a desktop application developer it's more important that his applications can be run on a solid and well equipped environment. Apparently Mac OS X Leopard (10.5) is such an environment. I've always been happy with its predecessor Tiger (10.4) and I don't feel a big urge to use the Java 6 VM. For a current server side project I need to use Java 6 and I do that with Ubuntu Linux running on VMware Fusion. There I have the Sun Java 6 VM. It's a huge difference and I would love to keep working on OS X as I don't have to restart Eclipse so frequently.

Java on Leopard - enough complaining

Wed, 31 Oct 2007 21:13:11 GMT

This is definitely a comment worth sharing.

Stale Java for the Mac Faithful

Mon, 29 Oct 2007 20:22:57 GMT

Now that Apple has released Leopard (Mac OS X 10.5.0) many blogs start talking about the missing JVM 1.6. Here is a quote from one of them:

Om Malik's Broadband Blog in Stale Java for the Mac Faithful:

Mac releases of Java lag those for Linux and Windows, and release 1.6 speeds up applications considerably, something Java needs in its fight with Adobe (ADBE) and Microsoft. Apple teased Java developers at its worldwide development conference with details on how Leopard would work well with Java and the community got its hopes up.

Part of the problem is that Apple insists on developing the JDK for MacOS. But another part is the company’s attitude towards innovation: That’s Apple’s Job.

As a company that makes both the hardware and the operating system, Apple has imposed more restrictions and regulations on its products than other computer manufacturers.

It’s possible that giving developers tools and open access to platforms will further reduce Apple’s control over the desktop. But by limiting development tools Apple is playing a risky game that may send developers looking for more friendly development platforms.

Currently I'm using Java 1.6 for a project on Ubuntu Linux. The IDE of choice is Eclipse 3.3 with a small number of plugins (Subclipse, M2Eclipse and Spring IDE). My experience so far is that Eclipse crashes arbitrarily with the latest JVM 1.6 upgrade 3. It's probably two or three times per day. That never happens with Apple's JVM 1.5 on Mac OS X (Tiger). On OS X I never close Eclipse throughout the week. I simply close the lid of the MacBook Pro, go home, use the laptop to surf the web in the evening and when I open it the next day I simply keep using Eclipse at the point where I left it.

So from my point of view I'm not so eager to use JVM 1.6 at this point in time. Speed improvements are one thing. But developer's productivity decreases drastically, if the tools are not stable. It's cheaper and easier to buy more powerful hardware, than to find skilled developers. I like to focus on my development problems and not on solving problems with the computing environment. In the end that saves a lot of time and money.

Starting to love EJB3 Hibernate Annotations

Fri, 09 Mar 2007 03:24:31 GMT

As our current project allows for some experimentation and adoption of recent technologies, we spent today with EJB3 Hibernate Annotations to get away from the XML configuration one used to create with Hibernate before.

The annotations need to be placed in the same compilation unit as the entity class lives in. The result is that these POJOs now are no longer POJOs in a very tight sense. That has been criticized as polluting the codebase with ORM specific annotations. That's certainly right, but one does not replace one ORM tool for another very often and going with the EJB3 Java Persistence annotation one can replace ORM tools, as Hibernate is just one implementation of that API. So I wouldn't fear too much. After all those classes that become entity classes are meant to be stored into a database and somewhere I have to put the mapping. Doing so in Java code instead of an external XML file appears to be clearer and more appealing to a developer.

Here is something we learned today.

Let's define a persistent entity class called Issue.

@Entity
@Table(name="issue")
@NamedQueries( { @NamedQuery(name = "findIssueById", query = "from Issue i where i.id = ?") })
public class Issue implements IdentifiableObject {

  @Id @GeneratedValue
  private long id ;

[...]
}

This entity will be persisted into the table issue and you see that it has an id field. Other fields are omitted for clarity. Further we define a named query findIssueById.

In a generic DAO class using Spring's Hibernate template we create a method findById as follows.

public Object findById(String query, long id) {
  List list = getHibernateTemplate().findByNamedQuery(query, id);
  if (list.isEmpty())
    return null ;
  else
    return list.get(0) ;
}

Elsewhere in the application we can the find any entity by calling findById passing in the name of the named query and of course the query criteria id.

Issue issueRead = (Issue) repository.findById("findIssueById", someId) ;

In your Spring application context configure your session factory using the AnnotationSessionFactoryBean.

<bean id="mySessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
  <property name="dataSource" ref="myDataSource"/>
  <property name="hibernateProperties">
    <props>
      <prop key="hibernate.dialect">org.hibernate.dialect.HSQLDialect</prop>
      [...]
    </props>
  </property>
  <property name="annotatedClasses">
    <list>
      <value>net.caimito.savila.Issue</value>
    </list>
  </property>
</bean>