I am currently evaluating Aspose.Total, and have been following some of the forum discussions - after running into the same type of issues: ClassNotFoundExceptions due to the fact that Aspose uses Sun’s proprietary classes that ONLY EXIST IN SUN’S IMPLEMENTATIONS OF JVM!
I am surprised no one seems to have mentioned the very obvious problem and solution. The sun. classes are NOT part of the Java language but rather are the “building blocks” Sun used to implement their own JVM. As, I’m sure you know, there are many other JVM implementations - from Oracle, IBM, Apple, etc., where those classes are not present. Yes, Oracle still used Sun’s classes through Java 6, in which those classes became officially deprecated. They no longer exist in Java 7. Sun has always made it clear that the sun. packages were not portable with other JVMs, were not documented, and were not guaranteed to be present in any particular release of the JVM.
Read the Sun/Oracle disclaimer: Why Developers Should Not Write Programs That Call ‘sun’ Packages
I simply cannot imagine how the Aspose engineering team could have overlooked this, continue to use sun.* in their products for years, and seemingly remain unaware of the issue to this day! Seriously?
The very obvious reason why the Aspose developers cannot re-create the problem in their environments is because they are testing their code in Sun JVMs that have the classes that many of your customers are missing due to the fact that those customers run their applications in non-Sun JVMs! But I don’t understand why no one has actually pin-pointed and addressed this trivial and very obvious problem. You guys are building a product that is NOT pure Java, it is not portable, it will only run on one particular type of JVM. It is not a minor bug, it is a very serious FLAW.
The fix is simple. Refactor your code base to replace all sun.* usages with the proven alternative implementations that are available. Provide the dependency JARs in your distributions, and/or provide the info on the resources where the latest versions of those libraries may be obtained, i.e Maven artifact configurations for those libs. No need to have year-long forum exchanges. Just get it done. The task is technically very simple although a few API signatures might need to be
adjusted, and, of course, a new round of QA will be required, so we would not expect you to come up with the fix overnight. However, acknowledging the problem and a reasonable time estimate would be appreciated.
I am not sure how many Sun packages you are using throughout your applications, but here’s an example of an alternative open-source JAI implementation, and how you can pull it using Maven (this example uses the SpringSource Maven repository, but there are certainly other sources):
SpringSource Enterprise Bundle Repository - External Bundle Releases
Hope this helps.