Eclipse IDE OH2 installation fails with code=1002 Unable to read repository at ... SSLProtocolException: Received close_notify during handshake

I’m trying to install Eclipse using the openHAB Eclipse instructions but it keeps failing with errors like:

  ERROR: org.eclipse.equinox.p2.transport.ecf code=1002 Unable to read repository at https://dl.bintray.com/bndtools/bndtools/latest/plugins/biz.aQute.bnd.embedded-repo_4.3.1.201911131708.jar.
  javax.net.ssl.SSLProtocolException: Received close_notify during handshake

Windows 10
Oomph 1.18.0 build 4828
I tried 2020-09 w/ jre 11.02, 2020-06 with Oracle jdk 1.8.0.261, 2020-03 with Oracle jdk 1.8.0.261
I tried turning my firewall off and it didn’t help

In all cases the repository that fails is bndtools.

Here are the repositories that fail:

  ERROR: org.eclipse.equinox.p2.engine code=0 session context was:(profile=D__eclipse-oxygen_openhab-smartthings-new_eclipse, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
  ERROR: org.eclipse.equinox.p2.transport.ecf code=1002 Unable to read repository at https://dl.bintray.com/bndtools/bndtools/latest/plugins/biz.aQute.bnd.embedded-repo_4.3.1.201911131708.jar.
  javax.net.ssl.SSLProtocolException: Received close_notify during handshake

  ERROR: org.eclipse.equinox.p2.transport.ecf code=1002 Unable to read repository at https://dl.bintray.com/bndtools/bndtools/latest/plugins/biz.aQute.bndlib_4.3.1.201911131708.jar.
  javax.net.ssl.SSLProtocolException: Received close_notify during handshake

  ERROR: org.eclipse.equinox.p2.transport.ecf code=1002 Unable to read repository at https://dl.bintray.com/bndtools/bndtools/latest/plugins/biz.aQute.repository_4.3.1.201911131708.jar.
  javax.net.ssl.SSLProtocolException: Received close_notify during handshake

  ERROR: org.eclipse.equinox.p2.transport.ecf code=1002 Unable to read repository at https://dl.bintray.com/bndtools/bndtools/latest/plugins/biz.aQute.resolve_4.3.1.201911131708.jar.
  javax.net.ssl.SSLProtocolException: Received close_notify during handshake

  ERROR: org.eclipse.equinox.p2.transport.ecf code=1002 Unable to read repository at https://dl.bintray.com/bndtools/bndtools/latest/plugins/bndtools.builder_4.3.1.201911131708.jar.
  javax.net.ssl.SSLProtocolException: Received close_notify during handshake

  Plus 6 more

Any recommendation for what I should try? I tied clearing my .eclipse, .p2 caches but it didn’t help.

I have the same problem. I think it’s a Java issue. I can download the files with Firefox and wget, but the installer client, which uses Java, fails.

I network trace shows it’s balking on the TLSv1.2 “Client Hello”, so these specific endpoints(s) don’t like something is the SSL negotiation, but I’m not sure what exactly… there are a lot of options the two side have to negotiate over, and for security reasons it won’t tell you what it didn’t like, it just hangs up.

Java is notorious for screwed up trust stores, and this worked a while ago, so I’m going on the assumption that the java version I have is broken. … Which is:

openjdk version "1.8.0_265"
OpenJDK Runtime Environment (build 1.8.0_265-b01)
OpenJDK 64-Bit Server VM (build 25.265-b01, mixed mode)

in my case. This is a CentOS 8 system, so the package is:
java-1.8.0-openjdk-1:1.8.0.265.b01-0.el8_2.x86_64

I’m going to try Java 11 now and see if I have better luck.

I should have looked closer before I spoke. The installer ships with it’s own copy of java, and that’s what’s broken.

openjdk version "14.0.2" 2020-07-14
OpenJDK Runtime Environment (build 14.0.2+12-46)
OpenJDK 64-Bit Server VM (build 14.0.2+12-46, mixed mode) 

I just pointed the installer to a different version on the system and then it worked okay.

Change the -vm argument in eclipse-inst.ini to point to a different java version. I used:

openjdk version "11.0.8" 2020-07-14 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.8+10-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.8+10-LTS, mixed mode, sharing)

Please read the Prerequisits

We do not recommend using openJDK, please use Azul Zulu !

I don’t think that’s related. My openhab is on a Raspberry PI. That’s whole other environment.

If you are going to debug in Eclipse, this will be related.

I can’t speak for the OP who is on Windows, and may have everything in one place, but the question here is about getting the Eclipse Installer to work. You’re response I believe is referring to the “default” java version. Both the Eclipse Installer as well as Eclipse are packaged with their own jvms and they explicitly override whatever the “default” java version, already on the system.

In this case, the jvm that ships with the current Eclipse Installer has a problem establishing SSL connections with certain endpoints, specifically 13.32.192.42, and probably others as well. A quick workaround is to point the installer to a functioning jvm, which simply gets Eclipse installed. Running openhab and Debugging in Eclipse is beyond the scope of this issue.

While installing, the advanced parameters are explicitly coded to take the “JRE 1.8 Location”, even though Eclipse will run under the jvm it’s packaged with unless you edit it’s .ini file. I’m not sure what effect the install parameter has or what might happen if Eclipse were to run under a different jvm, but that is beyond the scope of the OP and I don’t know that we want to go down that hole on this thread.

In my case I wasn’t able to get debugging in Eclipse to work because I have included some dependent osgi bundles and I couldn’t get them to resolve, so I’m remote debugging against the actual openhab server on another machine. I find that much better than struggling to fix things to work the the local scenario, and then having to fix it again when I deploy it and it runs in a different osgi container. For me it’s more efficient to fix it where it going to live, but the OP probably has different circumstances, so I’ll yield this thread back to him.

I have just setup a new IDE for OH3 development and all variables pointed to my Zullu-11.
There is an embedded JRE installed in the background, but this is not used.

That’s not my experience. The Eclipse launcher appears to be referencing a jvm in the repository, then someone seems to be launching another jvm process without an explicit path, so that one should find the “default” jvm on the system.

tlum      200728   66148  0 09:04 pts/1    00:00:00 ./eclipse
tlum      200750  200728 99 09:04 pts/1    00:02:00 /home/tlum/.p2/pool/plugins/org.eclipse.justj.openjdk.hotspot.jre.full.linux.x86_64_14.0.2.v20200815-0932/jre/bin/java -Dosgi.requiredJavaVersion=11 -Dosgi.ins
tlum      200816  200750  7 09:05 pts/1    00:00:03 java -Dhttps.nonProxyHosts=localhost|127.0.0.1 -Dhttp.nonProxyHosts=localhost|127.0.0.1 -classpath /home/tlum/openhab-2-5-x/eclipse/configuration/org.eclipse.o

I suspect the 2nd process is LemMinX

Sep 29, 2020 9:05:04 AM org.eclipse.lemminx.XMLLanguageServer initialize
INFO: Initializing XML Language server
LemMinX Server info:
 - Version : 0.12.0
 - Java : /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.265.b01-0.el8_2.x86_64/jre
 - Git 43595c3 - [maven-release-plugin] prepare release 0.12.0

It occurred to me afterwards that you’re referring to actually launching the osgi container. Yes, that invocation will use whatever you set for the “JRE 1.8 Location” in the Install. I’ll never use that, but it may be relevant to others.

tlum      201242  200750 85 09:20 pts/1    00:00:44 /usr/lib/jvm/jre/bin/java -Dlauncher.properties=/home/tlum/openhab-2-5-x/git/openhab-distro/launch/app/target/tmp/resolve/app/generated/launch18049018542412519

Thanks Ted for investigating this. I made the following change to eclipse-inst.ini file and it successfully ran.

; replaced by Bob Raker 9-29-2020
; -vm
; plugins/org.eclipse.justj.openjdk.hotspot.jre.minimal.stripped.win32.x86_64_14.0.2.v20200815-0932/jre/bin
-vm D:\Program Files\Java\jre1.8.0_261\bin

I’ll open a bug on the eclipse site and hopefully they will try to resolve this. I’ve been using Eclipse since it was first released. It is more capable every year but also more complicated. If it doesn’t work successfully it is tough to figure out.

Thanks again for your help

I submitted this bug to the Eclipse organization and they closed it as a duplicate. And, recommended that I download an eclipse installer using this link:

1 Like