Support multiple architectures about update4j HOT 19 CLOSED

Ok, let me think about it. The safest bet would be to require setting the os when arch is set

from update4j.

There's currently no support for handling architectures. This might be a great idea to create a PR; though, I know too little about it to do it myself.

You could potentially add a comment on the file element and through the update handler decide how to handle it.

from update4j.

Java has the standard system property os.arch to get the hardware architecture.
https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html

My understanding is that it is quite standardized, but different JVM vendors may have slight differences.

System.getProperty("os.arch"); //get hardware architecture

My Dell XPS show:
os.arch=amd64

Few Mac values over the years:
os.arch=ppc
os.arch=x86_64
os.arch=aarch64

Below are few libraries where we specify os="..." to get partially OS specific classpath.

# OS: Mac
<file uri="lib/client/javafx-media-17.0.2-mac.jar" 
      path="runtime/lib/cache/javafx-media-17.0.2-mac.jar" 
      size="1725689" 
      checksum="ebc08c40" 
      os="mac" 
      classpath="true" 
      ignoreBootConflict="true" 
      signature="..."/>

# OS: Windows
<file uri="lib/client/javafx-media-17.0.2-win.jar" 
      path="runtime/lib/cache/javafx-media-17.0.2-win.jar" 
      size="1089807" 
      checksum="9890c4f8" 
      os="win" 
      classpath="true" 
      ignoreBootConflict="true" 
      signature="..."/>

# OS: Linux
<file uri="lib/client/javafx-swing-17.0.2-linux.jar" 
      path="runtime/lib/cache/javafx-swing-17.0.2-linux.jar" 
      size="88803" 
      checksum="1a419e83" 
      os="linux" 
      classpath="true" 
      ignoreBootConflict="true" 
      signature="..."/>

# All OS
<file uri="lib/client/javafx-media-17.0.2.jar" 
      path="runtime/lib/cache/javafx-media-17.0.2.jar" 
      size="303" 
      checksum="927f47bf" 
      classpath="true" 
      ignoreBootConflict="true" 
      signature="..."/>

But nowadays with the introduction of Mac's newer M1 and M2 ARM architectures we do in some cases need to specify architecture as well, to get correct jars on the classpath.
Below is an example of how the update4j xml may look (introducing attribute arch="...")

# OS: Mac, architecture aarch64 (M1)
<file uri="lib/client/javafx-foo-17.0.2-mac_aarch64.jar" 
      path="runtime/lib/cache/javafx-foo-17.0.2-mac_aarch64.jar" 
      size="1725333" 
      checksum="ebc08d11" 
      os="mac" 
      arch="aarch64"   # new attribute, must match value of System.getProperty("os.arch") on client side (similar to how OS is checked).
      classpath="true" 
      ignoreBootConflict="true" 
      signature="..."/>

And to achieve the above when generating update4j xml, in class FileMetadata.Reference introduce method:

    public Reference arch(String arch) {
        this.arch = arch;

        return this;
    }

I also suggest using String instead of Enum since there might be variations or new architectures introduced.

Then on the client side, do a similar check with arch as you do with os to determine if the jar file should be included or not.

from update4j.

Yes this make perfectly sense.

The challenge will be that you might have properties or files overriding each other. Currently, update4j will check if the same file or property key exists twice and will only allow it if the OS of the 2 files/properties are different.

Now, by adding the arch we must now allow the same file or property with the same OS but different architecture. What might go wrong if one file only has the OS attribute set, and the other has only the arch set. Does this mean that the first targets only that OS and the other targets the remaining not matched by the first? What if I want the 2nd file to target the OS matches by the first file but only if the architecture is different? What if both files happen to match by OS and arch and they conflict each other?

So many questions and confusion might arise. Unless we only allow setting the arch if it also has the OS set.

from update4j.

For us 99% of the jars we specify does not require os or arch, but I do not see how for example javafx can work with update4j with the new architectures coming out (Mac M1).
Up until now it has worked since all Mac users have intel architecture.

Adding arch add some complexity for the user putting together the xml file, but I do not see any way around it. We already have to separate jars by name for os, and it could be the same for arch.

javafx has already taken care of naming for us in this case, by including the architecture in the filename.
https://repo1.maven.org/maven2/org/openjfx/javafx-graphics/17.0.2/

from update4j.

Sounds good. I appreciate you are looking into this.

from update4j.

update4j-1.5.9.zip

This is a first attempt, completely untested version that adds the arch attribute and handles the download accordingly. Let me know if it works or runs into any issues.

The arch should be automatically picked up from the filename if you use osFromFilename().

from update4j.

Thanks, we will test it out!

from update4j.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from update4j.

We have tested the version you provided and it works for our use case. We ended up not using the osFromFilename() due to some jar file not matching exactly. But since we can specify .arch(..) similar to how we specify OS it works for us.

In general I think it is a good idea to have the osFromFilename() but since filenames are not standardized there might be some cases where it does not work.

from update4j.

Would it be possible to get a new release based on the update4j-1.5.9.zip in the near future?

from update4j.

Yes, but I'll need to go through the flow again to make sure all edge cases are covered. I'll get to it in the next few days.

from update4j.

Sounds good, thanks.

from update4j.

@persal I pushed the code changes and created #181

I am too busy to complete this feature with all testing etc. If you want to contribute, it will be welcome.

from update4j.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from update4j.

FYI I filed #183 that should round out this feature, though I don't know if there are any additional places checks would need to be added.

from update4j.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from update4j.

Any news on this one? I have tried working around the aarch64 issue by using OS.OTHER for this case and the configuration file is generated as expected, but ConfigImpl.doUpdate uses OS.CURRENT in order to determine the value (which is impossible to override).

from update4j.

It has been implemented but I never released it, since I never tested it myself. You can try building from source and report if it works correctly

from update4j.