bbottema / simple-java-mail

Simple API, Complex Emails (Jakarta Mail smtp wrapper)

Home Page:http://www.simplejavamail.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Problem with java 6 version (4.2.1-java6-release): incompatible class version (1.7)

szilard-nemeth opened this issue · comments

Hi,

I have a maven enforcer rule on my project so that I can only use Java 6 compatible maven dependencies.
I imported your simple-java-mail:4.2.1-java6-release, I got this output from maven:

[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-bytecode-version) @ thinpoc-ejb ---
[INFO] Restricted to JDK 1.6 yet org.simplejavamail:simple-java-mail:jar:4.2.1-java6-release:compile contains org/simplejavamail/outlookmessageparser/model/OutlookAttachment.class targeted to JDK 1.7
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.EnforceBytecodeVersion failed with message:
Found Banned Dependency: org.simplejavamail:simple-java-mail:jar:4.2.1-java6-release
Use 'mvn dependency:tree' to locate the source of the banned dependencies.

Seems that org.simplejavamail:outlook-message-parser is compiled with Java 7.

My maven enforcer rule, for reference:

<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-enforcer-plugin</artifactId>
				<version>1.4.1</version>
				<executions>
					<execution>
						<id>enforce-bytecode-version</id>
						<goals>
							<goal>enforce</goal>
						</goals>
						<configuration>
							<rules>
								<enforceBytecodeVersion>
									<maxJdkVersion>1.6</maxJdkVersion>
									<!--<excludes>-->
										<!--<exclude>org.mindrot:jbcrypt</exclude>-->
									<!--</excludes>-->
								</enforceBytecodeVersion>
							</rules>
							<fail>true</fail>
						</configuration>
					</execution>
				</executions>
				<dependencies>
					<dependency>
						<groupId>org.codehaus.mojo</groupId>
						<artifactId>extra-enforcer-rules</artifactId>
						<version>1.0-beta-5</version>
					</dependency>
				</dependencies>
			</plugin>

Please fix,
Thanks!

Oh hmm, I see. Thanks for the report, I'll try to have it fixed this weekend.

I tried to use the enforcer plugin in the project as well, but I'm not able to get it complaining about the dependencies. Not sure what I'm doing wrong. I'll keep on it though.

I also tried to recompile your project with Java 6 target level, but I did not understand how did you manage java 6 compatibility since I came accross some classes that only available from Java 7 like StandardCharsets and Phaser. After the recompilation I included it in my project and got a ClassNotFoundException since StandardCharsets is not present in JDK 6, obviously.
Do you know which tag/commit is the last which is java 6 compatible, or could you please explain how do you guarantee java 6 compatibility if these classes are present in the code, even if I checkout the 4.2.1 tag?

To be honest, I'm taking a quite naive approach in hindsight; I simply set the target compiler version to 1.6, but that doesn't give any guarantees about the dependencies, which I package along.

This approach worked while Simple Java Mail had fewer features, but it won't work anymore. I'm not sure I can still support Java6 now. Do you have suggestions?

Thanks for your time and your fast response!
Unfortunately I don't as you are already using classes from JDK 7.
I think it would be better to state somewhere that java 6 is not really supported from now so that no one may fall into the same pitfall, maybe removing java-6 from the release name would make sense.

I'll see what it takes to make a reduced java6 version. Otherwise I will deprecate the java6 releases and stick to java7.

Sounds good, thank you for your effort!

I've released a customised 4.2.3-java6-release with a customised outlook-message-parser 1.1.16-java6-release. This is the last java6 release I will do, as it is simply too much manual labor to create a limited second edition.

I've removed the Phaser completely which has the following consequences:

  • If authenticated proxy is used, the bridging proxy server will not be shut down automatically (and might not run the second time)
  • If mails are sent in async mode, the connection pool will not be shut down anymore by itself

This means your server/application might not stop properly due to lingering processes. To be completely safe, only send emails in sync mode (used by default) and don't use authenticated proxy config.