Run the following in bash. I’m using git bash, but cygwin will probably work too.

This will install CEF in ~/.codenameone/cef. The Codename One simulator will check there the next time it runs, and will opt to use CEF instead of JavaFX if it finds it.

Run the following in bash. I’m using git bash, but cygwin will probably work too.

This will install CEF in ~/.codenameone/cef. The Codename One simulator will check there the next time it runs, and will opt to use CEF instead of JavaFX if it finds it.

Default JCEF builds don’t have proprietary codec support (e.g. h.264), so, if you need to update CEF (not JCEF, but CEF itself), you’ll need to build it from source. The build-mac.sh script is currently set to download a prebuilt cef binary from google drive that has been built with proprietary codec support. The process for updating CEF is roughly as follows:

1. Follow changes in the upstream java-cef repository to identify changes that we may wish to apply to the Codename One fork of java-cef. Specifically, look for the CEF_VERSION variable in the CMakeLists.txt file:

   set(CEF_VERSION "84.3.8+gc8a556f+chromium-84.0.4147.105")

2. Follow the CEF instructions for building from source. See "Building From Source" > "Automated Method".

   The "update.sh" script from the build instructions should be:

   #!/bin/bash
   export CEF_USE_GN=1
   export GN_DEFINES="is_official_build=true proprietary_codecs=true ffmpeg_branding=Chrome"
   python ../automate/automate-git.py --download-dir=/Users/shannah/code/chromium_git --depot-tools-dir=/Users/shannah/code/depot_tools --force-distrib --force-build --force-update --x64-build --branch=4147

   The --branch directive in the above snippet should be the branch referenced in the CEF_VERSION variable of the CMakeLists.txt above. In the example above, the branch is 4147.

3. Upload the resulting cef_binary_XXXX+chromium-XXXXX_macosx64.zip file to Google drive, and create a public link to it.

4. Update the build-mac.sh script to point to the new cef_binary that you uploaded to Google drive.

   FILENAME=cef_binary_84.4.1+gfdc7504+chromium-84.0.4147.105_macosx64
   FILEID=1YWWJT6ng1T6LAc-zztmWs3bsUTNcjyLP

5. Update the java-cef/src/CMakeLists.txt file, if necessary to match the version of cef_binary that you built.

6. Run sh build-mac.sh clean again

If you need to update CEF (not JCEF, but CEF), then you can’t just use an official build because we require proprietary codec support (h.264, etc.) To build CEF on linux, the best way that I’ve found is to use the cef-dockerized project which uses docker to build with all required dependencies.

1. Check out the CefSharpDockerfiles project from Github.

   cd c:/
   git clone https://github.com/mitchcapper/CefSharpDockerfiles

2. Rename versions_src.ps1 to versions.ps1

3. Modify versions.ps1 to the following contents:

   $VAR_CHROME_BRANCH="4147";
   $VAR_CEFSHARP_VERSION="75.0.90";
   $VAR_CEFSHARP_BRANCH="cefsharp/75";
   $VAR_BASE_DOCKER_FILE="mcr.microsoft.com/windows/servercore:1809-amd64";#mcr.microsoft.com/windows/servercore:1903-amd64
   $VAR_DUAL_BUILD="0"; #set to 1 to build x86 and x64 together, mainly to speed up linking which is single threaded, note may need excess ram.
   $VAR_GN_DEFINES="is_official_build=true proprietary_codecs=true ffmpeg_branding=Chrome";
   $VAR_CEF_BUILD_MOUNT_VOL_NAME=""; #force using this volume for building, allows resuming MUST BE LOWER CASE
   $VAR_GN_ARGUMENTS="--ide=vs2019 --sln=cef --filters=//cef/*";
   $VAR_GYP_DEFINES="is_official_build=true proprietary_codecs=true ffmpeg_branding=Chrome";
   $VAR_CEF_BUILD_ONLY=$true;#Only build CEF do not build cefsharp or the cef-binary.
   $VAR_CEF_USE_BINARY_PATH=""; #If you want to use existing CEF binaries point this to a local folder where the cef_binary*.zip files are. It will skip the long CEF build step then but still must make the VS container for the cefsharp building.  Note will copy a dockerfile into this folder.
   $VAR_REMOVE_VOLUME_ON_SUCCESSFUL_BUILD=$true;
   $VAR_CEF_BINARY_EXT="zip"; #Can be zip,tar.bz2, 7z Generally do not change this off of Zip unless you are supplying your own binaries using $VAR_CEF_USE_BINARY_PATH above, and they have a different extension, will try to work with the other formats however
   $VAR_CEF_SAVE_SOURCES="0"; #normally sources are deleted before finishing the CEF build step.  Set to 1 to create a /code/sources.zip archive that has them (note it is left in docker image, must use docker cp to copy it out, it is also around 30GB).
   $VAR_CEF_VERSION_STR="auto"; #can set to "3.3239.1723" or similar if you have multiple binaries that Docker_cefsharp might find
   $VAR_HYPERV_MEMORY_ADD="--memory=30g"; #only matters if using HyperV, Note your swap file alone must be this big or able to grow to be this big, 30G is fairly safe for single build will need 60G for dual build.
   if ($false){ #Sample 65 overrides
   	$VAR_CHROME_BRANCH="3325";
   	$VAR_CEFSHARP_VERSION="65.0.90";
   	$VAR_CEFSHARP_BRANCH="master";
   }

   Key things to note about these contents:

   1. The branch ($VAR_CHROME_BRANCH) is set to "4147". This is chosen to correspond to the branch that is set up in the jcef project. It must be the same. See the CEF_VERSION default value in the CMakeLists.txt in the java-cef fork repo to see the exact branch number that is required.

   2. $VAR_GN_DEFINES="is_official_build=true proprietary_codecs=true ffmpeg_branding=Chrome"; - This is the magic sauce that makes it build with proprietary codec support.

   3. $VAR_CEF_BUILD_ONLY=$true; - This tells it to build CEF only, and not try to build CEFSharp. We don’t need CEF sharp. Just CEF.

4. Make sure Docker is installed, and it is set to use Windows containers.

5. Open Powershell and run ps build.ps1

If the Build Fails…​

If the build fails in the final step (zipping up all the files), as it did with me, you’ll have to extract the files from the container manually. Luckily the build script creates an image after the build which you can run in docker to extract the image files. These are the steps I took:

1. Create a folder named "binaries" inside the CefSharpDockerfiles directory. We’ll mount this directory inside the docker container when we run it so that we can copy the binaries there.

2. Find out the Image ID that was created by docker. Use docker image for this:

   PS C:\CefSharpDockerfiles> docker images
   REPOSITORY                             TAG                 IMAGE ID            CREATED             SIZE
   cef                                    latest              3b772c1ec91a        13 hours ago        16.6GB
   i_cefbuild_srxnu                       latest              3b772c1ec91a        13 hours ago        16.6GB
   cef_build_env                          latest              9be99f7e48b3        3 days ago          14.8GB
   i_cefbuild_pdxas                       latest              ae02cd810c04        3 days ago          16.6GB
   <none>                                 <none>              d79aced55e48        5 days ago          14.8GB
   <none>                                 <none>              45a354c8b285        5 days ago          14.8GB
   vs                                     latest              d0a493e1a26e        5 days ago          13.9GB
   mcr.microsoft.com/windows/servercore   1809-amd64          2352228ff6bc        4 weeks ago         5.12GB

   The most recent image ID will be the one that we want. In this example it is 3b772c1ec91a. Run docker with that image:

   PS C:\CefSharpDockerfiles> docker run -it --entrypoint cmd --mount 'type=bind,source="c:/CefSharpDockerfiles/binaries",target="c:/binaries"' 3b772c1ec91a

   Some notes here:

   1. We use --entrypoint cmd to open the command prompt inside the docker container.

   2. The --mount 'type=bind,source="c:/CefSharpDockerfiles/binaries",target="c:/binaries"' bit mounts our binaries directory inside the docker container at c:/binaries so that we can copy files into it.

      When the command prompt opens inside the Docker container, you should find the binaries inside the c:\code\binaries directory:

      C:\code\binaries>dir
       Volume in drive C has no label.
       Volume Serial Number is E6CC-657A
      
       Directory of C:\code\binaries
      
      12/02/2020  04:01 PM    <DIR>          .
      12/02/2020  04:01 PM    <DIR>          ..
      12/02/2020  03:54 PM        92,835,819 cef_binary_84.4.1+gfdc7504+chromium-84.0.4147.105_windows32.zip
      12/02/2020  03:57 PM       528,607,702 cef_binary_84.4.1+gfdc7504+chromium-84.0.4147.105_windows32_release_symbols.zip
      12/02/2020  03:58 PM        96,928,126 cef_binary_84.4.1+gfdc7504+chromium-84.0.4147.105_windows64.zip
      12/02/2020  04:01 PM       519,176,166 cef_binary_84.4.1+gfdc7504+chromium-84.0.4147.105_windows64_release_symbols.zip
                     4 File(s)  1,237,547,813 bytes
                     2 Dir(s)  21,207,175,168 bytes free

      Just copy these into c:\binaries using the copy command:

      C:\code\binaries>copy *.zip c:\binaries\
      cef_binary_84.4.1+gfdc7504+chromium-84.0.4147.105_windows32.zip
      cef_binary_84.4.1+gfdc7504+chromium-84.0.4147.105_windows32_release_symbols.zip
      cef_binary_84.4.1+gfdc7504+chromium-84.0.4147.105_windows64.zip
      cef_binary_84.4.1+gfdc7504+chromium-84.0.4147.105_windows64_release_symbols.zip
              4 file(s) copied.

Currently, I’m storing the binaries in Google drive. If you want to do it the same way, just upload them to Google Drive, and create a public link to them. (Don’t need the release_symbols files).

Then update the build-win32.sh and build-win64.sh files to set the FILEID and FILENAME variables to point to the correct files in gdrive.

That’s all there is to it :)

If you need to update CEF (not JCEF, but CEF), then you can’t just use an official build because we require proprietary codec support (h.264, etc.) To build CEF on linux, the best way that I’ve found is to use the cef-dockerized project which uses docker to build with all required dependencies.

1. Checkout the repo

2. Update the cef/script/set_env.sh file so that the GN_DEFINES variable is:

   export GN_DEFINES="is_official_build=true use_sysroot=true use_allocator=none symbol_level=1 enable_nacl=false use_cups=false proprietary_codecs=true ffmpeg_branding=Chrome"

3. Add --branch=4147 to the extra_automate_args environment variable. Though this will be different if you need to build a different branch.

4. Run the command cef_arch=x64 docker-compose run --rm cef

   This will take a while. Probably about a day.

5. When it is finished, you will find a .7z file in the cef/output directory. It’s huge (like 8 gigs). Extract this file.

6. After the file is finished extracting you’ll find the zip archive for CEF that we can use for building jcef at chromium_git/chromium/src/cef/binary_distrib/cef_binary_84.4.1+gfdc7504+chromium-84.0.4147.105_linux64.zip

   Copy this file into the java-cef/src/third_party/cef directory and extract it.

7. Update the CEF_VERSION environment variable in the build-linux.sh script to match the version in the cef_binary you just extracted. In the example above, the version would be cef_binary_84.4.1+gfdc7504+chromium-84.0.4147.105.

8. Run bash build-linux.sh

At this point, if the build worked, you should have a new zip file with this updated build inside the dist directory.

On Ubuntu 20, and some other versions of Linux, it has been reported that, when running the Codename One simulator with CEF installed, you get UnsatisfiedLinkException mentioning that libjcef.so could not find libjawt.so. This is caused because the lib directory of the JDK is not in the LD_LIBRARY_PATH. You an work around this problem by adding it. E.g.