Symbolic links in Java JAR files on IPF OpenVMS

[keithwhare]

We have copied the Java Jar files for Confluent Kafka from a Linux installation to an IPF OpenVMS V8.4.2L1.

Many of the jar files are symbolic inks. For example, kafka.jar is a symbolic link to ./kafka_2.13-7.6.1-ccs.jar

Our work-around so far is to rename the symbolic link .jar files to .jar_txt and include all of the folders in the classpath.

Is there some way to get symbolic links to work using Java 8 (build 1.8.0.11-vms-b1)?

[arne_v]

If you can live with a manual fixup (or a manual repeatable fixup by putting the commands in a COM file) then you could do an appropriate number of SET FILE/ENTER commands to create a *nix like setup.

If you are looking for a way to automatically create the correct setup using ZIP or TAR format, then I don't know what options exist. A quick glance at their help did not find anything for UNZIP but VMSTAR do have a:

s /SYMLINKS Extract archived symlinks as real symlinks.

that may or may not be useful.

[sms]

Code: Select all

> Our work-around so far is to rename the symbolic link .jar files to
> .jar_txt [...]

   What, exactly, are you working around?  What is the actual problem
which you are trying to solve?

> Is there some way to get symbolic links to work using Java 8 (build
> 1.8.0.11-vms-b1)?

   What, exactly, does "not work" mean in this case?  Is Java itself not
properly handling valid symlinks?

   "Not work" is not a useful problem description.  It does not say
what you did.  It does not say what happened when you did it.  As usual,
showing actual actions (commands) with their actual results (error
messages, ...) can be more helpful than vague descriptions or
interpretations.


> [...] UNZIP [...]

      unzip -v   ! Look  for "SYMLINKS".

[...]
UnZip special compilation options:
[...]
        SYMLINKS (symbolic links supported, if RTL and file system permit)
[...]

   I'd need to look at the code, but I believe that symlinks just work
if the program is built with that option, and you're extracting to a
volume which supports them.  Otherwise, I believe that you get a text
file which contains the link text.

   As I recall, VMSTAR gives you similar link-text files by default
(for compatibility with old versions), or real symlinks if you ask.

> that may or may not be useful.

   Yup.  Need a better problem description.

[arne_v]

As I understand the question then it can be simplified to:
* there is a Linux directory with a file kafka_2.13-7.6.1-ccs.jar and a symbolic link kafka.jar that points to that file
* the task is to pack it on Linux, transfer to VMS and unpack on VMS so that it end up in the same sitaution with a file kafka_2.13-7.6.1-ccs.jar and a symbolic link kafka.jar pointing to that file

There are probably a ton of directories with hundreds of files and dozens of symlinks, but if it works for 1+1 then it should also work for the real case.

[keithwhare]

For Confluent Kafka community edition 7.6.1, there are five folders with a total of 251 files that are symbolic links. They are easily identifiable because they use one VMS block.

If these files are in the classpath, Java fails to find classes that should be in the jar files.

The exceptions look like:

Code: Select all

Java ExceptionOccurred in (*env)->CallStaticVoidMethod(env, lmlStaticClass, OpenMID, stringArray, targetTables), describing ...
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/avro/Conversions$DecimalConversion
 at jcc.lml.kafka.lmlAvroProducer.lmlOpenKafka(lmlAvroProducer.java:259)
Caused by: java.lang.ClassNotFoundException: error in opening JAR file /C761/000000/slf4j-api-1.7.36.jar

I will take a look at VMSTAR. I untarred the files on a linux system because I didn't have a tar utility on our VMS system.

[sms]

Code: Select all

> * the task is to pack it on Linux, transfer to VMS and unpack on VMS
> [...]

   You're far ahead of me.  I got lost at "copied" (which is about as
helpful as "not work").

   If that's the case, then _Zip_ might require a little care.  Again, a
"zip -v" report should mention symlink support:

proa$ zip -v | grep link
        SYMLINK_SUPPORT      (symbolic links supported)

But the default in Zip is to _follow_ a symlink.  To _archive_ a
symlink, there's another option:

proa$ zip -h | grep link
  -y   store symbolic links as the link instead of the referenced file

   So, if using Zip+UnZip, you'd want "zip -y"; if using "tar"+VMSTAR,
you'd want "VMSTAR /SYMLINKS" (or "s").

   What could be simpler?

Added in 8 minutes 1 second:

Code: Select all

> [...]  I untarred the files on a linux system because I didn't have a
> tar utility on our VMS system.

   I'm still mystified about how you got anything onto the VMS system,
and what you have there now.  Are there symlinks in the VMS storage?  Is
this a Java problem, or a file-transfer problem, or what, exactly?

   See "not a useful problem description", above.

[arne_v]

I will take a look at VMSTAR. I untarred the files on a linux system because I didn't have a tar utility on our VMS system.

Steve make it available at:

http://antinode.info/dec/sw/vmstar.html

[sms]

Code: Select all

> [...] Are there symlinks in the VMS storage? [...]

      HELP DIRECTORY /SYMLINK

   Note the fine print:

      [...] If any file attribute is requested, then the contents
      of the symbolic link are also displayed, [...]

   So, the simplest DIRECTORY command is not so informative as one might
hope:

its $ dire [.itrc]isl.link

Directory ITS$DKA0:[SMS.itrc]

isl.link;1          

Total of 1 file.


   But, ask for any additional info (like, say, /DATE), and you get even
more:

its $ dire /date [.itrc]isl.link

Directory ITS$DKA0:[SMS.itrc]

isl.link;1 -> isl.c
                     20-SEP-2010 09:12:08.81

Total of 1 file.

[hb]

Symbolic links for a jar file work as expected (on IA64), as you probably tested with something like:

Code: Select all

$ set proc/parse=ext
$ java -version
java version "1.8.0.03-OpenVMS"
Java(TM) SE Runtime Environment (build 1.8.0.03-vms-rc1)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b02, mixed mode)
$ 
$ ty HelloWorld.java
public class HelloWorld 
{
       public static void main (String[] args)
       {
             System.out.println("Hello World!");
       }
}
$ javac HelloWorld.java
$
$ ty [.META-INF]MANIFEST.MF
Main-Class: HelloWorld
$ 
$ jar cvmf [.META-INF]MANIFEST.MF hw.0.9.1.jar HelloWorld.class
added manifest
adding: HelloWorld.class(in = 426) (out= 288)(deflated 32%)
$ 
$ cre/symlink="./hw.0.9.1.jar" hw.jar
$ dir/size *.jar

Directory LDA5:[JAVA]

hw^.0^.9^.1.jar;1             2
hw.jar;1 -> ./hw.0.9.1.jar
                              1

Total of 2 files, 3 blocks.
$ 
$ java -jar hw.jar
Hello World!
$

In case the symbolic link is no longer valid, there is no Java exception, you just get:

Code: Select all

$ rena hw.0.9.1.jar hw.0.9.2.jar
$ java -jar hw.jar
Error: Unable to access jarfile hw.jar
$ 

The shown Java exception indicates, that a) there is an absolute path in the symbolic link and b) that the Java code reads the symbolic link and tries to open the target file. I didn't try the latter. The first case works as expected. But it is very unlikely that a tar file with the Java Jar files for Confluent Kafka contains symbolic links with an absolute path.

Code: Select all

$ del hw.jar.
$ cre/symlink="/LDA5/JAVA/hw.0.9.2.jar" hw.jar
$ java -jar hw.jar
Hello World!
$ 

I didn't see your java command. Is the jar file with the exception on the command line? So far, to me this looks like a setup problem, not a generic Java on VMS problem.