Re: Question about using the OpenJDK 8 JDeps tool with IKVMC

Hi,


a)       If ikvmc can't find a class it will emit code to throw either a NoClassDefFoundError or code to dynamically try to load the class at runtime using the class loader associated with the assembly at runtime. Which of the two depends on the ikvmc version and the -static option.

b)      ikvmc will never guess at which assembly contains a class. When it gives an error about a missing assembly, it means that you referenced an assembly that in turn referenced the missing assembly.

c)       Yes, you get a warning and the behavior described in a).

I use "ikvmc { A.jar } { B.Jar}" this compiles both jars at the same time into two different assemblies. Then I examine the dependencies between the assemblies.

Regards,
Jeroen

From: Richard Callahan [mailto:[email protected]]
Sent: Wednesday, November 4, 2015 5:44
To: Jeroen Frijters <[email protected]>; [email protected]
Subject: RE: [Ikvm-developers] Question about using the OpenJDK 8 JDeps tool with IKVMC

Hi Jeroen,

Thanks very much! Well, I personally wouldn't call what you're doing "low-tech" at all.

I thought about your response and would like to follow up. Starting with IKVM 8, when a JAR file getting compiled is missing a reference to a class in a DLL which has already been compiled, IKVMC throws an error (instead of a warning as was the case in IKVM 7), then recommends that the user run IKVMC again, referencing the DLL this time when compiling the JAR. What happens when the class and namespace in question is contained in more than one JAR file? Unpacking this question further:


a)       Let's say that the same namespace and class, org.bar.foo, exists in two JAR files that have already been converted to DLL files (say A.DLL and B.DLL), that C.JAR is being compiled by IKVMC and includes a call to a method in org.bar.foo, and that the call to IKVMC compiling C.JAR references neither A.DLL nor B.DLL. Does IKVM 8 arbitrarily pick one of the DLL files and recommend a reference to that one when C.JAR fails to completely convert to a DLL file? (If that is the case, then for a project with a large number of dependencies that has been identified by JDeps, I believe that merely following the suggestions in each IKVM 8 error message could lead to a dependency graph that is not a subgraph of the graph produced by JDeps -- and therefore I could potentially end up in a situation where I am not able to convert my JAR file of interest and all its classes to a DLL file.)

b)      Now let's use the previous example, except that A.DLL has been created but B.JAR has not been converted to B.DLL. When C.JAR fails to completely convert to a DLL file, does IKVM 8 automatically throw an error and recommend a reference be added to A.DLL file (while ignoring org.bar.foo in B.JAR)?

c)       My understanding is that if neither A.JAR nor B.JAR have been converted to DLL files, then converting C.JAR to C.DLL will result in a "class not found" warning, referencing "org.bar.foo". Correct?

Also, I'd like to clarify: you said "I compile everything at once using ikvmc multiple assembly output feature and then use ildasm to examine the dependencies of the resulting assemblies." If I understand your response correctly, I think you mean that you run "ikvmc C.JAR -recurse: /directory/to/CJar/*.jar", and look for namespaces in the resulting DLL files, is that right? When you say that's what you do personally, do you mean that's what you do when you're converting your own JAR libraries to DLL files, or that it's what you have implemented in IKVM 8 when the software notifies a user that they may have forgotten to include a reference to a DLL library in an IKVMC command?

Thanks very much for your time in addressing these really specific questions, it really helps me to understand the technology and use it correctly for what I need to do.

Best,

Richard

From: Jeroen Frijters [mailto:[email protected]]
Sent: Tuesday, November 3, 2015 10:46 PM
To: Richard Callahan <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>
Subject: RE: [Ikvm-developers] Question about using the OpenJDK 8 JDeps tool with IKVMC

Hi,

I don't know for sure, but I suspect the answer is yes.

What I do personally is very low-tech. I compile everything at once using ikvmc multiple assembly output feature and then use ildasm to examine the dependencies of the resulting assemblies.

Regards,
Jeroen

From: Richard Callahan [mailto:[email protected]]
Sent: Tuesday, November 3, 2015 14:32
To: [email protected]<mailto:[email protected]>
Subject: [Ikvm-developers] Question about using the OpenJDK 8 JDeps tool with IKVMC

Hi,

I'm emailing the list with three questions (in three messages) today. Here's the first question: I am experimenting with the JDeps tool, released for the first time with OpenJDK 8, which analyzes the dependency relationships among JAR files and produces a dependency graph in the form of text output. (JDeps provides the option to specify entire JAR files as the nodes in such a graph, or to specify classes using its "verbose" option. For me, the nodes are currently JAR files.) My assumption is that because the developers of OpenJDK maintain both the Javac compiler and JDeps, then if a Java project correctly compiles with Javac, then some subgraph of the dependency graph produced by JDeps should be a directed acyclic graph that is used by the Java compiler when it actually walks through the project's dependencies during the build process - and no edges walked by the compiler should not be in the JDeps graph. This is not the right forum to ask if this assumption is true, so let's assume for the moment that it is gospel truth. Then, let's suppose that one were to know ahead of time at least one graph structure associated with a batch file containing a set of IKVMC commands that, when executed, would correctly convert a Java application and all of its associated functions (even those that reference external libraries) to a DLL file. (Note that multiple solutions to this problem likely exist, so let's just call such a graph structure a solution to the problem, not the solution to the problem.) Is the graph associated with that IKVM batch file always a subgraph of the JDeps graph?

If the answer is yes, then even though JDeps can produce graphs containing cycles, I should be able to write an algorithm to correctly produce a batch file for IKVMC. If the answer is no, then that's disappointing. Thanks very much! (Also, if anyone reading has suggestions for a tool to determine the structure of dependencies in a large directory of JAR files that is better than JDeps or Jar2Ikvmc, this would probably be a great thread to post to.)

Excuse me if I'm asking a question that's been partly answered before - I did search around but may have missed something.

Best,

Richard

Background: like at least one other person<http://sourceforge.net/p/ikvm/mailman/message/6714655/> who posted previously, I have a large Java application that I would like to convert to a DLL while correctly preserving, in the new DLL file, all the functions that reference external libraries. That means, of course, that I first need to at least partially convert those external JAR libraries to DLL files as well. The problem quickly becomes quite difficult, and I have seen others post horror stories about taking quite some time to manually determine the set of references to include in a batch file to feed to IKVMC. I am attempting to use a tool to automate this approach, and have tried Jar2Ikvmc<https://code.google.com/p/jar2ikvmc/> for this purpose but it simply falls short for complicated projects, as it uses a crude, greedy algorithm to attempt to create a dependency structure that often is simply wrong.

------------------------------------------------------------------------------

_______________________________________________
Ikvm-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ikvm-developers