Bug 1112012

This is a bug in JavaConfig, a custom script supplied with pl.

It contains this snippet:

 78     value = value + ":" +
 79       home + filesep + "lib" + filesep + architecture + ":" +
 80       home + filesep + "lib" + filesep + architecture + filesep + "server";

That's really hardcoding jre/lib/aarch64 and jre/lib/aarch64/server, without checking if either one of those exist. Most architectures have a "server" dir, so this works.

It's not correct to assume the location of the libjvm.so: there's no requirement for "server". Some architectures have both "client" and "server" variants of libjvm.so and some have only one.

Reassigning to pl.

So after two and half years, there is still no programmatic way how to get paths to JVM libraries (bug #740762)? It's very sad that the OpenJDK developers are such selfish and cannot distribute any pkg-config file allowing to integrate JVM into other code.

Could you tell me, how can I determine which path to use for which platform?

(In reply to Petr Pisar from comment #2)
> So after two and half years, there is still no programmatic way how to get
> paths to JVM libraries (bug #740762)?

Sorry, somehow that fell through the cracks :(

> It's very sad that the OpenJDK
> developers are such selfish and cannot distribute any pkg-config file
> allowing to integrate JVM into other code.

I am going to ping folks to follow up with this.

> Could you tell me, how can I determine which path to use for which platform?

Perhaps the simplest way for now would be to modify JavaConfig.java to check if each

home + filesep + "lib" + filesep + architecture + filesep + "server"

home + filesep + "lib" + filesep + architecture + filesep + "client"

exists before adding it to the library path? And prefer "server" if both exist?

(In reply to Petr Pisar from comment #2)
> So after two and half years, there is still no programmatic way how to get
> paths to JVM libraries (bug #740762)? It's very sad that the OpenJDK
> developers are such selfish and cannot distribute any pkg-config file
> allowing to integrate JVM into other code.
> 

You are speaking as though the developers already have a solution and are just too lazy to release or, as though they have loads of free time and are wasting it instead of doing this.

There are issues with implementing a pkg config like system for a multi-vendor multi-version software piece like the JDK. 

Even if we do it for Fedora, all other distros will have to use the system. They will have to apply a similar system for proprietary JDKs as well (which are unlikely to implement a packages solution) because if it is only half implemented, upstream projects are not going to adopt such a system.

Calling people lazy and then expecting that to motivate them into doing what you want is not going to help your cause.

> Could you tell me, how can I determine which path to use for which platform?

(In reply to Deepak Bhole from comment #4)
> You are speaking as though the developers already have a solution and are
> just too lazy to release or, as though they have loads of free time and are
> wasting it instead of doing this.
> 
I'm telling that because inability to come with a small file in a 2.5 years shows there is something very wrong with JDK development.

However if it's such a hard problem, do you think that third-party software packager, like me, will be able to solve the problem on their side? And each packager again and again for each his package? Therefore I believe the only viable approach is to solve it on JDK/OpenJDK/IcedTea side.

> There are issues with implementing a pkg config like system for a
> multi-vendor multi-version software piece like the JDK. 
>
What? If the file is provided by vendor with each version separately, then the implementation is matter of opaque internals you don't have to bother.

If you talk about distribution-level solution, I'm really curious how distributor made java(1) or javac(1) tools or classpath directory lists available to the user? With your argumentation they would never managed it. The pkg-config file is just yet another instance of the same problem. And they do that without upstream help.
 
> Even if we do it for Fedora, all other distros will have to use the system.

If the job were done on OpenJDK site, other distros would just use it because it would come with the upstream.

> They will have to apply a similar system for proprietary JDKs as well (which
> are unlikely to implement a packages solution) because if it is only half
> implemented, upstream projects are not going to adopt such a system.
> 
I don't understand the obsession with proprietary implementations and their relation to OpenJDK. There are myriads of differences between JDK implementation. Adding a file which does not break any specification nor API is a no-go?

(In reply to Petr Pisar from comment #5)
> (In reply to Deepak Bhole from comment #4)
> > You are speaking as though the developers already have a solution and are
> > just too lazy to release or, as though they have loads of free time and are
> > wasting it instead of doing this.
> > 
> I'm telling that because inability to come with a small file in a 2.5 years
> shows there is something very wrong with JDK development.
> 
> However if it's such a hard problem, do you think that third-party software
> packager, like me, will be able to solve the problem on their side? And each
> packager again and again for each his package? Therefore I believe the only
> viable approach is to solve it on JDK/OpenJDK/IcedTea side.
> 
> > There are issues with implementing a pkg config like system for a
> > multi-vendor multi-version software piece like the JDK. 
> >
> What? If the file is provided by vendor with each version separately, then
> the implementation is matter of opaque internals you don't have to bother.
> 
> If you talk about distribution-level solution, I'm really curious how
> distributor made java(1) or javac(1) tools or classpath directory lists
> available to the user? With your argumentation they would never managed it.
> The pkg-config file is just yet another instance of the same problem. And
> they do that without upstream help.
>  

So you are suggesting using alternatives for a pkg-config file? Hmm, interesting. I have never seen it being done but you're right, it is possible.

> > Even if we do it for Fedora, all other distros will have to use the system.
> 
> If the job were done on OpenJDK site, other distros would just use it
> because it would come with the upstream.
> 

Fair enough.

> > They will have to apply a similar system for proprietary JDKs as well (which
> > are unlikely to implement a packages solution) because if it is only half
> > implemented, upstream projects are not going to adopt such a system.
> > 
> I don't understand the obsession with proprietary implementations and their
> relation to OpenJDK. There are myriads of differences between JDK
> implementation. Adding a file which does not break any specification nor API
> is a no-go?

It is not a question of obsession. If I am an upstream developer who wants to link to libjvm, why would I use pkg config if I know that 2 of 3 (IBM/Oracle vs OpenJDK) JDKs do not support that system?

Created attachment 911909 [details]
Patch for rawhide

(In reply to Omair Majid from comment #3)
> Perhaps the simplest way for now would be to modify JavaConfig.java to check
> if each
> 
> home + filesep + "lib" + filesep + architecture + filesep + "server"
> 
> home + filesep + "lib" + filesep + architecture + filesep + "client"
> 
> exists before adding it to the library path? And prefer "server" if both
> exist?

Yes, this seems to be the best way to fix this, although AFAICS they don't actually need to be checked since only one will exist: aarch64 uses "client" where ix86/x86_64/armv7hl/ppc64/s390/s390x all use "server".

Patch tested locally with mock (fedora-rawhide-x86_64) and with arm-koji:

http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2449565

(In reply to Deepak Bhole from comment #6)
> It is not a question of obsession. If I am an upstream developer who wants
> to link to libjvm, why would I use pkg config if I know that 2 of 3
> (IBM/Oracle vs OpenJDK) JDKs do not support that system?

You should use pkg-config because it brings automated configuration to OpenJDK users. There would be no change with other JDKs. (Unless distributors amend them with home-made pkg-config file which is fairly possible as that brings simplification even for the packagers.) Don't forget that users of current JDKs have to fiddle the compiler flags manually. And don't forget that pkg-config usage can be optional.

I would understand your worries if the change were negative or disruptive. However this change is an improvement. Somebody has to to be the first one.

(In reply to Yaakov Selkowitz from comment #7)
> Created attachment 911909 [details]
> Patch for rawhide
> 
Thanks. I applied it.

Omair is following up on this per comment 3. Whether or not other JDKs do it is of no concern -- I was merely pointing out that it is a potential barrier to adoption for other projects.

Omair, I have reassigned #740762 to you.

(In reply to Petr Pisar from comment #8)
> You should use pkg-config because it brings automated configuration to
> OpenJDK users.

Can you give me an example of what you would like from this pkg-config file? Would just including the various -L/path/to/jvm/ be enough or should it also include -ljvm and -ljava?

I'm not experienced in using java, so I don't know if there are some libraries which are always needed. If that's so, then they (like -ljvm -ljava) should be output on --libs argument. If there are some extensions which consists of other libraries, then the pkg-config way is to provide a separate pkg-config file for each of them.

Personally, I need the -L path (--libs output) and the java home directory (--variable=home output). I also think the -I path to header files (--cflags output) would be nice as well as --version output.

I just spoke with Mikolaj. His opinion is already described here: https://bugzilla.redhat.com/show_bug.cgi?id=449456#c5

Basically, a pkg-config file is the wrong solution for Fedora. Fedora (and JPackage in general) guidelines allow users to easily switch between JREs. This requires that applications respect $JAVA_HOME at runtime. They should not link to a specific libjvm, but rely on dlopen() instead.

This is the patch used in hadoop that makes it use dlopen() instead:
http://pkgs.fedoraproject.org/cgit/hadoop.git/tree/hadoop-dlopen-libjvm.patch

dlopen() requires absolute path to the library if the library is not in a regeristered linker search path (/etc/ld.so.conf). The patch repeats exactly the same mistake which each application should avoid---it hardcodes paths. Moreover the quoted patch will work only in i386 and x86_64 and only with JDK 1.7 and 1.8. There is still need for library path discovery mechanism at JDK level.