svn mergeinfo probs

This helps with svn mergeinfo probs/bugs:

svn propget svn:mergeinfo --depth=infinity

To check if there is a bad mergeinfo entry in a file causing e.g . svn: Pathname not terminated by ':'

THis might also help in that regard:
http://subversion.tigris.org/issues/show_bug.cgi?id=3896

java6

With java6 many new libs were integrated directly into the jdk - without changing the classpath names. For Jaxws a custom solution(or custom cloassloader?) was integrated within a java6 update to support newer versions of jaxws so at least that worked after that. With other libraries there are still problems. For example the java activation framework. Before java6 it always had to be bundled with java mail in the war file and you had to make sure that there were no other versions in the classpath for it to work. So this worked fine with java5 - with java6 jaf was part of the system classpath but java mail wasn't. With tomcat this would result in classpath loader problems because jaf would need to use java mail classes and would throw classnotfound exceptions (if debugged) if not you would just get a classic generic no object DCH for MIME type error message.
Further information about that can be read here: http://blog.hpxn.net/2009/12/02/tomcat-java-6-and-javamail-cant-load-dch/

I really hope that in future java versions this problems can be addressed preferably by a versioned class loading mechanism. (Alternativly you could use osgi and libraries adapted for that - which would ultimately mean to avoid java system classes completely)

java the future and improvements

In the last year I often read that developers are considering to switch away from java and that java does not really evolve. For other reasons many devs also discuss if java has any future at all for them.
For many java provides a stable base for developing solid software solutions - with the backing of big companies and countless proven libraries.
Actually many of these libraries now seem dated and the language did not really change the way many devs would have expected.
For many years I thought that there are some very specific issues in java which would have to be solved for java to really evolve:

• classpath/classloader "hell" (e.g. outdated libraries shipped with the jdk, permgenspace issues)
• debugging of proxies (aspectj/spring)
• integration of osgi to allow clean lib management and better memory management

I wouldn't mind if the next java release is completely incompatible to the old java versions. In reality new java versions take years to be actually used and ready to be used.
If the next version of java has completely new basic packages (api/impl) it would break compatibility but it would allow new projects to use a cleaner and evolved environment.
Although I guess in the end devs having these requirements will switch to different languages before something like that can be achieved.