Skip to main content

hdcookbook_discimage compile error

4 replies [Last post]
paulemasters
Offline
Joined: 2011-12-07
Points: 0

Hello:

Not having struggled with the hdcookbook for over a year I updated the files. Also updated JAVA SE, ME runtime, NetBeens etc.

Running ant all in hdcookbooka I received a compile error. As near as I can tell it is in hdcookbooka\xlets\hdcookbook_discimage process.

Attached is the log with debug speciied from running ant from that folder.

The line that appears to have or reference the problem is near the bottom:
"signing: com/hdcookbook/bookmenu/monitor/bluray.MonitorXlet.permCaused by: java.io.IOException: ObjectIdentifier mismatch: 1.3.14.3.2.26"

I didn't have this problem when doing that process a year ago with JAVA and runtime of 6.29. Had a lot of others, but not that one. :)

However, as I am very new with all this and have no idea what I am doing or looking at, I could be wrong.

I am also wondering if I am using the wrong version of JAVA et all?
It / they were version 7.10.
I ask because I seem to remember that a specific version of one of the pieces (ME?) had to be at a specific version for BD. ME was version 3.2. Runtime was 7.10.

A help would be greatly appreciated.

Thanks for your time.

Paul Masters

AttachmentSize
log.txt141.91 KB

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
billf
Offline
Joined: 2004-02-13
Points: 0

Hi Paul,

Here's a guess: Maybe it's got something to do with the public or private key used for code signing? As in, maybe the underlying Java runtime has a compatibility problem around a certificate or something stored in the database where such things are stored.

The ant task does a bunch of stuff automatically. One thing it does is notice if you haven't generated the public-private keypair used for the self-signed certificate it uses to sign JAR files. Maybe your workspace has that keypair already, created with a prior version of the Java runtime. And maybe the new Java runtime has a bug where it can't read the database.

The quick fix would be to run "ant spotless". That deletes the signing database. If that doesn't work, you can make absolutely sure this isn't a problem by deleting the cookbook repository, and bringing over a fresh copy.

Dunno if this'll fix your problem or not, but it's worth a shot!

Cheers,

Bill

paulemasters
Offline
Joined: 2011-12-07
Points: 0

Hello Bill!

Thanks for the suggestions.

Ran ant spotless against that folder and it deleted some files. Then ran ant against that folder with Java 7 and it failed the same way. Perhaps 'spotless' should have been run against the base folder?

I though as you implied that there was a problem with running Java 7. Either with it or some incompatibility with the cookbook code. Therefore, I deleted Java 7 and ran a registry clean and restarted the PC. Installed Java 6. Did not change ME as it was 3.2 and the prior one was 3.0.5.

Ran ant against the base folder and received a different error:

[jdktools.java] java.lang.UnsupportedClassVersionError: net/java/bd/tools/security/BDCertGenerator : Unsupported major.minor version 51.0
[jdktools.java] at java.lang.ClassLoader.defineClass1(Native Method)
[jdktools.java] at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
[jdktools.java] at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
[jdktools.java] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
[jdktools.java] at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
[jdktools.java] at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
[jdktools.java] at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
[jdktools.java] at java.security.AccessController.doPrivileged(Native Method)
[jdktools.java] at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
[jdktools.java] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
[jdktools.java] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
[jdktools.java] at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
[jdktools.java] Could not find the main class: net.java.bd.tools.security.BDCertGenerator. Program will exit.
[jdktools.java] Exception in thread "main"
[ant] Exiting E:\hdcookbooka\xlets\hdcookbook_discimage\build_bdjo_security.xml.
[ant] Exiting E:\hdcookbooka\xlets\hdcookbook_discimage\build.xml.
[ant] Exiting E:\hdcookbooka\xlets\build.xml.

So, something must be really messed up or or incompatable with going back a version of Java.
(Although, I don't understand why it couldn't find the class.)

Even though the download folder had been updated with SVN a few days ago when all this started and the process was being run from an export copy of that, I took your suggestion.
I renamed the current download folder and downloaded it again with SVN. And made an export copy of that. Then ran ant all -debug to a log file.
It completed OK this time.

I searched the log for 'error' and did not find any. A search found quite a few 'warning' messages. Some were about deprecation.

Perhaps more troubling were a number of warnings about various items being "proprietary API and may be removed in future release". Which appear to be in "hdcookbooka\DiscCreationTools\bdjo\build.xml..."
At: E:\hdcookbooka\DiscCreationTools\security\src\net\java\bd\tools\security\BDCredentialSigner.java:62:
I attached the log file in case it is of any use.

Whether those warnings were in the original run I did over a year ago, I can not say. Having the current problem I did a deeper search this time.

So, apparently, the cookbook code won't work with Java 7. At least the signing part.
Any suggestions on how to correct that? Or perhaps I am doing somethhing wrong - a good possibility. Or may be the certificate file is not in the cookbook folders or it is in one that ant spotless wasn't run from?

I wouldn't be concerned but what happens if, in the future, I get a product that requires a later version of Java? I know I can have multiple versions on the PC, but the order of their files in the Windows Path or Classpath may become critical.

Thanks for all your time and help.

Paul Masters

billf
Offline
Joined: 2004-02-13
Points: 0

Hi Paul,

From that, I can't tell if it works with Java 7 or not. The test for that would be to bring over a new copy of the repository, and compile the known-clean copy with Java 7.

I think the "ant spotless" from the base directory of the repository should work, too, but that's less certain.

The class version mismatch you were seeing tells me that there were still compiled class files from a prior build. That might mean that "ant spotless" wasn't run from the right place, or that it doesn't quite clean everything up. Anyway, if you compile something with the Java 7 version of javac, and then try to use that .class file with the Java 6 version of javac, that's the expected error, so when you saw that there was still something remaining from a Java 7-based compile.

The error messages about "proprietary API" do raise a concern, but I'm afraid we're stuck with that. The thing is, Blu-ray JAR signing is almost the same as regular JAR signing, but not quite -- Blu-ray adds a header. The problem is that the public API didn't provide a way to add that header to the JAR signing tool, so we were forced to use a Sun-internal API. It's unlikley that it will go away, but it's not impossible. If it ever does, then as you say, older JDK versions are available.

Cheers,

Bill

paulemasters
Offline
Joined: 2011-12-07
Points: 0

Hello Bill:

W7 was working with java 6.29 (the last one available I think), I didn't want to delete that and install java 7 figureing I would have to go back to java 6.

I exported the updated hdcookbookdownload to another PC with Vista 32 bit. It has Java 7.2

There was an error like the one mentioned above. Attached is the debug log. I happen to see a 'Signature encoding error' a few lines above the 'Caused by' message. Checking the java 7 log from W7, I do not see that error. Therefore, there must be some slight difference between the java versions. (7.2 and 7.10). FWIW ME is 3.0.5 on Vista and 3.2 on W7.

Thanks.

Paul Masters