ActiveMQ 4.1 has crept in some Java 5 APIs, which prevent it from being used on Java 1.4 JVMs

• Key: AMQ-1185
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Blocker
• Assignee: Unassigned
• Reporter: Jason Dillon
• Affects Version/s: 4.1.1
• Fix Version/s: 4.1.1

Description

A few bits of Java 5 API has made it into the AMQ 4.1 branch, which prevent 4.1 from being used on Java 1.4 JVMS.

Apache Geronimo v1.2 needs AMQ 4.1 running on Java 1.4.

So far I don't see anything major which prevents AMQ 4.1 from being compiled with Java 1.4... only a few minor changes to keep compatibility. The alternative is of course to use the retrotranslator-maven-plugin to generate 1.4 compatible jars for each module (the new retrotranslator:translate-project makes this very easy to use, includes attaching jdk14 artifacts).

But IMO, that would just add more complexity for AMQ 4.1 when only a few simple changes will allow the it to be native 1.4... though you folks might consider using retrotranslator:translate-project for trunk to create 1.4 compatible jars for the new AMQ (> 4.1.x) bits.

Comments

[Jason Dillon]

Patch allows branches/activemq-4.1 to be built using JDK 1.4

[Jason Dillon]

Ugh... appears there are a bunch of test failures with the above... though very hard to find them due to all of the output from the tests

But they are failing with things like:

Test set: org.apache.activemq.spring.SpringTest
-------------------------------------------------------------------------------
Tests run: 5, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 11.035 sec <<< FAILURE!
testSenderWithSpringXml(org.apache.activemq.spring.SpringTest)  Time elapsed: 0.58 sec  <<< ERROR!
java.lang.NoClassDefFoundError: java/util/concurrent/ExecutionException
        at org.apache.activemq.store.DefaultPersistenceAdapterFactory.createJournal(DefaultPersistenceAdapterFactory.java:224)
        at org.apache.activemq.store.DefaultPersistenceAdapterFactory.getJournal(DefaultPersistenceAdapterFactory.java:132)
        at org.apache.activemq.store.DefaultPersistenceAdapterFactory.createPersistenceAdapter(DefaultPersistenceAdapterFactory.java:70)
        at org.apache.activemq.broker.BrokerService.createPersistenceAdapter(BrokerService.java:1320)
        at org.apache.activemq.broker.BrokerService.getPersistenceAdapter(BrokerService.java:631)
        at org.apache.activemq.broker.BrokerService.deleteAllMessages(BrokerService.java:888)
        at org.apache.activemq.broker.BrokerService.start(BrokerService.java:387)
        at org.apache.activemq.transport.vm.VMTransportFactory.doCompositeConnect(VMTransportFactory.java:113)
        at org.apache.activemq.transport.vm.VMTransportFactory.doConnect(VMTransportFactory.java:52)
        at org.apache.activemq.transport.TransportFactory.doConnect(TransportFactory.java:43)
        at org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:77)
        at org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:230)
        at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:245)
        at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:214)
        at org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:161)
        at org.apache.activemq.spring.SpringConsumer.start(SpringConsumer.java:49)
        at org.apache.activemq.spring.SpringTest.assertSenderConfig(SpringTest.java:154)
        at org.apache.activemq.spring.SpringTest.testSenderWithSpringXml(SpringTest.java:91)

Which shows there is more Java 5 stuff lingering around... perhaps in some other dependency?

[Jason Dillon]

Crap, crap, crap... there is a ton of Java 5 bits in activeio 3.1-SNAPSHOT, which ActiveMQ is using.

I missed this before, as I was still compiling with JDK 1.5, but set the compiler to generate 1.4 classes. But, when compiling activeio with JDK 1.4 it pukes up a bunch more stuff.

Perhaps activeio 3.1 needs to be retrotranslated so that activemq 4.1 can use -jdk14 versions of this... pffff.

[Jason Dillon]

I updated activeio/trunk to use the latest retrotranslator-maven-plugin's translate-project to make jdk14 versions of activeio (in the AMQ-1185-activeio-retro.diff patch). And then I updated activemq/branches/activemq-4.1 to use the jdk14 jars (via classifier) plus a few other changes for compilation with JDK 1.4 (in the AMQ-1185-2.diff patch). Re-ran the tests for activemq-core and almost everything passed...

Tests run: 1488, Failures: 0, Errors: 2, Skipped: 0

2 Errors were in:

• org.apache.activemq.broker.region.cursors.KahaCursorDurableTest

With errors like:

java.io.IOException: Bad file descriptor
	at sun.nio.ch.FileChannelImpl.release0(Native Method)
	at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:105)
	at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97)
	at java.io.RandomAccessFile.close(RandomAccessFile.java:523)
	at org.apache.activemq.kaha.impl.index.IndexManager.delete(IndexManager.java:119)
	at org.apache.activemq.kaha.impl.KahaStore.delete(KahaStore.java:137)
	at org.apache.activemq.store.kahadaptor.KahaPersistenceAdapter.deleteAllMessages(KahaPersistenceAdapter.java:164)
	at org.apache.activemq.broker.BrokerService.deleteAllMessages(BrokerService.java:888)
	at org.apache.activemq.broker.BrokerService.start(BrokerService.java:387)
	at org.apache.activemq.broker.region.cursors.CursorDurableTest.createBroker(CursorDurableTest.java:212)
	at org.apache.activemq.broker.region.cursors.CursorDurableTest.setUp(CursorDurableTest.java:183)
	at junit.framework.TestCase.runBare(TestCase.java:125)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:160)
	at org.apache.maven.surefire.Surefire.run(Surefire.java:81)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:182)
	at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:743)

Not sure, but this might have been due to not cleaning up the activemq-data directory (which really should by the way, be put into the target/ dir for testing, so that killing all target dirs will clean up all state).

I'm going to nuke everything... ugh... annoying that you folks have svn:ignore set to ignore activemq-data (as well as a bunch of other stuff)... so it makes it rather hard to use svn status to determine what is junk state outside of the target dir. I suppose I will have to svn co ... again and re-apply the patches.

It looks better now... though something else has popped up in the G 1.2 branch which is causing some major problems which prevent me from verifying that the current AMQ 4.1-SNAPSHOT resolves the spec compliance issues. Hopefully we'll have that sorted out soonish.

[Jason Dillon]

Okay... we are good now... spec compliance problems are gone with the latest 4.1-SNAPSHOT of AMQ.

Hopefully 4.1.1 will be on its way to a friendly neighborhood maven repo soon