Develop Reference

Bazel with Java 11 on Ubuntu

I am trying to use Java 11 for my Java Homework. It works fine on my OS X machine, but I have JDK 13 installed on my machine. My instructor uses Ubuntu and does not have the latest java installed. How Can I get Bazel to use JAVA 11 without requiring my instructor to update his JDK.
My .bazelrc is as follows:
test --test_output=errors
test --cache_test_results=yes
test --java_toolchain=#bazel_tools//tools/jdk:toolchain_java11
And when I run:
bazel test java/test/edu/berkeley/cs/util:{hashset,hashmap}
I get this wonderfull error.
Starting local Bazel server and connecting to it...
INFO: Writing tracer profile to '/home/tomgrant/.cache/bazel/_bazel_tomgrant/75fd013422b9b35862a74918dc983c19/command.profile.gz'
INFO: Analyzed 2 targets (23 packages loaded, 287 targets configured).
INFO: Found 2 test targets...
INFO: Deleting stale sandbox base /home/tomgrant/.cache/bazel/_bazel_tomgrant/75fd013422b9b35862a74918dc983c19/sandbox
ERROR: /home/tomgrant/.cache/bazel/_bazel_tomgrant/75fd013422b9b35862a74918dc983c19/external/bazel_tools/tools/jdk/BUILD:319:1: Action external/bazel_tools/tools/jdk/platformclasspath.jar failed (Exit 1) java failed: error executing command external/remotejdk11_linux/bin/java -XX:+IgnoreUnrecognizedVMOptions '--add-exports=jdk.compiler/com.sun.tools.javac.platform=ALL-UNNAMED' -cp ... (remaining 4 argument(s) skipped)
Use --sandbox_debug to see verbose messages from the sandbox
Exception in thread "main" java.lang.IllegalArgumentException: external/local_jdk
at jdk.compiler/com.sun.tools.javac.file.Locations$SystemModulesLocationHandler.isCurrentPlatform(Locations.java:1862)
at jdk.compiler/com.sun.tools.javac.file.Locations$SystemModulesLocationHandler.update(Locations.java:1851)
at jdk.compiler/com.sun.tools.javac.file.Locations$SystemModulesLocationHandler.handleOption(Locations.java:1798)
at jdk.compiler/com.sun.tools.javac.file.Locations.handleOption(Locations.java:2062)
at jdk.compiler/com.sun.tools.javac.file.BaseFileManager.handleOption(BaseFileManager.java:269)
at jdk.compiler/com.sun.tools.javac.file.BaseFileManager$2.handleFileManagerOption(BaseFileManager.java:222)
at jdk.compiler/com.sun.tools.javac.main.Option.process(Option.java:1138)
at jdk.compiler/com.sun.tools.javac.main.Option.handleOption(Option.java:1086)
at jdk.compiler/com.sun.tools.javac.file.BaseFileManager.handleOption(BaseFileManager.java:232)
at jdk.compiler/com.sun.tools.javac.main.Arguments.doProcessArgs(Arguments.java:390)
at jdk.compiler/com.sun.tools.javac.main.Arguments.processArgs(Arguments.java:347)
at jdk.compiler/com.sun.tools.javac.main.Arguments.init(Arguments.java:246)
at jdk.compiler/com.sun.tools.javac.api.JavacTool.getTask(JavacTool.java:185)
at DumpPlatformClassPath.dumpJDK9AndNewerBootClassPath(DumpPlatformClassPath.java:106)
at DumpPlatformClassPath.main(DumpPlatformClassPath.java:67)
Caused by: java.nio.file.NoSuchFileException: external/local_jdk
at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:333)
at java.base/java.nio.file.Files.isSameFile(Files.java:1530)
at jdk.compiler/com.sun.tools.javac.file.Locations$SystemModulesLocationHandler.isCurrentPlatform(Locations.java:1860)
... 14 more
INFO: Elapsed time: 8.063s, Critical Path: 0.26s
INFO: 3 processes: 3 linux-sandbox.
FAILED: Build did NOT complete successfully
//java/test/edu/berkeley/cs/util:hashset NO STATUS
FAILED: Build did NOT complete successfully
If anyone can solve this will be glad to send you a bag of Blue Bottle beans or something similar that costs $20 =D

I don't know I understand your question correctly, but I'm looking for the same issue right now.
So far I got one answer from this link from Bazel Dev! from gerrit.googlesource.com
And please look at this section:
[[java-11]]
==== Java 11 support
Java 11 is supported through alternative java toolchain
link:https://docs.bazel.build/versions/master/toolchains.html[Bazel option].
To build Gerrit with Java 11, specify JDK 11 java toolchain:
$ bazel build \
--host_javabase=#bazel_tools//tools/jdk:remote_jdk11 \
--javabase=#bazel_tools//tools/jdk:remote_jdk11 \
--host_java_toolchain=#bazel_tools//tools/jdk:toolchain_java11 \
--java_toolchain=#bazel_tools//tools/jdk:toolchain_java11 \
:release

"UNAVAILABLE" gRPC failure from android client to python server

I've been struggling all day with the following issue with gRPC on Android when trying to make an RPC call to a python RPC server running on my machine (on the same network).
My android gRPC android client compiles and runs, however, I get the following error message on the client (and silence on the python server):
io.grpc.StatusRuntimeException: UNAVAILABLE
Caused by: java.io.IOException: PROTOCOL_ERROR invalid settings id: -509
The full stack-trace reads:
05-06 18:39:01.133 5018-5302/com.example.android.cimi I/SyncAdapter: Failed... :
io.grpc.StatusRuntimeException: UNAVAILABLE
at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:227)
at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:208)
at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:141)
at com.example.android.cimi.CimiSyncerGrpc$CimiSyncerBlockingStub.getHouseholdTimestamps(CimiSyncerGrpc.java:209)
at com.example.android.cimi.SyncAdapter.onPerformSync(SyncAdapter.java:130)
at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:259)
Caused by: java.io.IOException: PROTOCOL_ERROR invalid settings id: -509
at io.grpc.okhttp.internal.framed.Http2.ioException(Http2.java:589)
at io.grpc.okhttp.internal.framed.Http2.access$200(Http2.java:47)
at io.grpc.okhttp.internal.framed.Http2$Reader.readSettings(Http2.java:304)
at io.grpc.okhttp.internal.framed.Http2$Reader.nextFrame(Http2.java:162)
at io.grpc.okhttp.OkHttpClientTransport$ClientFrameHandler.run(OkHttpClientTransport.java:868)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:818)
05-06 18:39:01.139 5018-5018/com.example.android.cimi I/SyncService: Service destroyed
When shutting off the server, I get a different error, so something else must be going on.
I'm using the following versions:
io.grpc:protoc-gen-grpc-java:1.3.0
com.google.protobuf:protoc:3.0.0
Things I've tried:
Downgrading to grpc 1.0.0
Downgrading Android studio
Tried python 2&3
Connecting from a python client works!
How else could I debug this? Is there any way to get more meaningful exceptions? Is there a way to make the server more verbose?
Any help would be greatly appreciated!

I've narrowed it down to a problem with the python gRPC server by confirming that the call works when using a Java server instead.
It turns out it must have been related to recent gRPC/protobuf python packages (just installed via pip install, must have grabbed the most recent ones):
The following sequence of commands for downgrading the gRPC installation solved the issue:
cd /usr/lib/python2.7/site-packages
rm -rf packaging*
rm -rf pyparsing*
pip2 install protobuf==3.0.0
pip2 install grpcio==1.0.0
pip2 install grpcio-tools==1.0.0

Kubernetes "fatal alert: protocol_version" error when creating a Deployment

We're running a kubernetes cluster on the Google Cloud Platform, which creates a Deployment with 8 hazelcast-based replicas. We've had this running fine for over a month, but recently, we started receiving the below error message whenever we try to start our deployment (non-relevant stack frames omitted):
2016-07-15 12:58:02,117 [My-hazelcast.my-deployment-368708980-8v7ig # my-deployment-368708980-8v7ig] ERROR - [10.68.5.3]:5701 [MyProject] [3.6.2] Error executing: GET at: https://kubernetes.default.svc/api/v1/namespaces/default/endpoints/my-service. Cause: Received fatal alert: protocol_version
io.fabric8.kubernetes.client.KubernetesClientException: Error executing: GET at: https://kubernetes.default.svc/api/v1/namespaces/default/endpoints/my-service. Cause: Received fatal alert: protocol_version
at io.fabric8.kubernetes.client.dsl.base.OperationSupport.requestException(OperationSupport.java:272) ~[kubernetes-client-1.3.66.jar:na]
at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:205) ~[kubernetes-client-1.3.66.jar:na]
at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleGet(OperationSupport.java:196) ~[kubernetes-client-1.3.66.jar:na]
at io.fabric8.kubernetes.client.dsl.base.BaseOperation.handleGet(BaseOperation.java:483) ~[kubernetes-client-1.3.66.jar:na]
at io.fabric8.kubernetes.client.dsl.base.BaseOperation.get(BaseOperation.java:108) ~[kubernetes-client-1.3.66.jar:na]
at com.noctarius.hazelcast.kubernetes.ServiceEndpointResolver.resolve(ServiceEndpointResolver.java:62) ~[hazelcast-kubernetes-discovery-0.9.2.jar:na]
at com.noctarius.hazelcast.kubernetes.HazelcastKubernetesDiscoveryStrategy.discoverNodes(HazelcastKubernetesDiscoveryStrategy.java:74) ~[hazelcast-kubernetes-discovery-0.9.2.jar:na]
at com.hazelcast.spi.discovery.impl.DefaultDiscoveryService.discoverNodes(DefaultDiscoveryService.java:74) ~[hazelcast-all-3.6.2.jar:3.6.2]
....
Caused by: javax.net.ssl.SSLException: Received fatal alert: protocol_version
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.7.0_95]
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) ~[na:1.7.0_95]
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1991) ~[na:1.7.0_95]
...
at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:203) ~[kubernetes-client-1.3.66.jar:na]
... 18 common frames omitted
When I google this error, I get a lot of hits about TLS protocol version mismatch. Apparently, Java 8 assumes a different TLS protocol version (TLS 1.2) than Java 7 and 6(TLS 1.0). However, all of our containers run the same docker image (based off of the hazelcast/hazelcast:3.6.2 image), which is based off of Java 7, so there should be no protocol version mismatch (and this layer of our image has not changed).
We've tried to revert all of our recent changes in an attempt to resolve this error, to no avail. And frankly, nobody on our team has changed anything receltly related to SSL or the Hazelcast Kubernetes discovery mechanism. We recently updated our google cloud SDK components (gcloud components update) at the urging of the Cloud SDK tools ("Updates are available for some Cloud SDK components."). We're now running Google Clouds SDK version 117.0.0, but I don't see any breaking changes related to SSL or TLS in the release notes.
Why would we suddenly start seeing this "fatal alert: protocol_version" error message in our kubernetes pods, and how can I resolve it?

The initial google searches indicating this was a TLS version error (version 1.0 vs 1.2 incompatibility) turned out to be useful. This answer to a question about a similar SSLException protocol_version error is what pointed me in the right direction.
I got a test container to run, and using kubectl exec my-test-pod -i -t -- /bin/bash -il to launch an interactive bash shell into the container, I determined that the Hazelcast discovery service could NOT connect using TLS 1.0, but could using TLS 1.2:
/opt/hazelcast# curl -k --tlsv1.0 https://kubernetes.default.svc/api/v1/namespaces/default/endpoints/my-service
curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
/opt/hazelcast# curl -k --tlsv1.2 https://kubernetes.default.svc/api/v1/namespaces/default/endpoints/my-service
Unauthorized # <-- Unauthorized is expected, as I didn't specify a user/passwd.
I am still not sure what exactly changed, possibly a layer of a public Docker container we use, possibly something within Google cloud service (Java 7 is End of Life, after all), and the fine folks at Hazelcast suggested perhaps the REST API had been updated. But evidently something changed that was causing the discovery service expect clients to TLS version 1.2.
The solution was to download the Hazelcast Docker image we were using, and tweak it to use Java 8 instead of Java 7, and then rebuild the image in our own development sandbox:
$ pwd
/home/jdoe/devel/hazelcast-docker-3.6.2/hazelcast-oss
$ head -n3 Dockerfile
FROM java:8
ENV HZ_VERSION 3.6.2
ENV HZ_HOME /opt/hazelcast/
Voila! Our Deployment is running again.

getBalance.sh on Amazon Mechanical Turk (mturk) Command Line Tools (CLT) returns an error

Could someone help me figure out my mistake? Thank you in advance :) I'm trying to set up the Command Line Tool (CLT) on my Mac OS X Yosemite and I'm getting error messages.
My problem seems similar to the one in the link below, but not identical; I have changed "http" to "https" in the murk.properties file after installing the CLT.
getBalance in Amazon Turk gives error
CODE: This is what I entered in Terminal (initially thinking that my problem was Java location):
$ export MTURK_CMD_HOME=/Applications/aws-mturk-clt-1.3.1
$ java -version
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
$ which java
/usr/bin/java
$ export JAVA_HOME=/usr
$ cd /Applications/aws-mturk-clt-1.3.1/bin/
$ ./getBalance.sh
ERROR: This is an excerpt of the error message I received
Unable to find a $JAVA_HOME at "/usr", continuing with system-provided Java...
I/O exception (javax.net.ssl.SSLPeerUnverifiedException) caught when processing request: HTTPS hostname invalid: expected '176.32.98.23', received 'mechanicalturk.amazonaws.com'
Retrying request
I/O exception (javax.net.ssl.SSLPeerUnverifiedException) caught when processing request: HTTPS hostname invalid: expected '176.32.98.23', received 'mechanicalturk.amazonaws.com'
Retrying request
I/O exception (javax.net.ssl.SSLPeerUnverifiedException) caught when processing request: HTTPS hostname invalid: expected '176.32.98.23', received 'mechanicalturk.amazonaws.com'
Retrying request
An error occurred while fetching your balance: javax.net.ssl.SSLPeerUnverifiedException: HTTPS hostname invalid: expected '176.32.98.23', received 'mechanicalturk.amazonaws.com'
com.amazonaws.mturk.service.exception.InternalServiceException: javax.net.ssl.SSLPeerUnverifiedException: HTTPS hostname invalid: expected '176.32.98.23', received 'mechanicalturk.amazonaws.com'
at com.amazonaws.mturk.service.axis.AWSService.executeRequestMessage(AWSService.java:243)
at com.amazonaws.mturk.filter.FinalFilter.execute(FinalFilter.java:38)
at com.amazonaws.mturk.filter.Filter.passMessage(Filter.java:56)
at com.amazonaws.mturk.filter.ErrorProcessingFilter.execute(ErrorProcessingFilter.java:46)
at com.amazonaws.mturk.filter.Filter.passMessage(Filter.java:56)
at com.amazonaws.mturk.filter.RetryFilter.execute(RetryFilter.java:115)
at com.amazonaws.mturk.filter.Filter.passMessage(Filter.java:56)
at com.amazonaws.mturk.util.CLTExceptionFilter.sendMessage(CLTExceptionFilter.java:77)
at com.amazonaws.mturk.util.CLTExceptionFilter.execute(CLTExceptionFilter.java:62)
at com.amazonaws.mturk.service.axis.FilteredAWSService.executeRequests(FilteredAWSService.java:172)
at com.amazonaws.mturk.service.axis.FilteredAWSService.executeRequest(FilteredAWSService.java:152)
at com.amazonaws.mturk.service.axis.FilteredAWSService.executeRequest(FilteredAWSService.java:116)
at com.amazonaws.mturk.service.axis.RequesterServiceRaw.getAccountBalance(RequesterServiceRaw.java:1193)
at com.amazonaws.mturk.service.axis.RequesterService.getAccountBalance(RequesterService.java:922)
at com.amazonaws.mturk.cmd.GetBalance.getBalance(GetBalance.java:50)
at com.amazonaws.mturk.cmd.GetBalance.runCommand(GetBalance.java:41)
at com.amazonaws.mturk.cmd.AbstractCmd.run(AbstractCmd.java:148)
at com.amazonaws.mturk.cmd.GetBalance.main(GetBalance.java:28)
Caused by: javax.net.ssl.SSLPeerUnverifiedException: HTTPS hostname invalid: expected '176.32.98.23', received 'mechanicalturk.amazonaws.com'
at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
The error message continues a bit. So, what do you think? Thanks again for looking at this. - Soon
mturk.properties file
# -------------------
# ADVANCED PROPERTIES
# -------------------
#
# If you want to test your solution in the Amazon Mechanical Turk Developers Sandbox (http://sandbox.mturk.com)
# use the service_url defined below:
#service_url=https://mechanicalturk.sandbox.amazonaws.com/?Service=AWSMechanicalTurkRequester
# If you want to have your solution work against the Amazon Mechnical Turk Production site (http://www.mturk.com)
# use the service_url defined below:
service_url=https://mechanicalturk.amazonaws.com/?Service=AWSMechanicalTurkRequester
# The settings below should only be modified under special circumstances.
# You should not need to adjust these values.
retriable_errors=Server.ServiceUnavailable,503
retry_attempts=6
retry_delay_millis=500'

Guan, have you tried with an earlier version of the JDK (e.g., JDK-1.5?). I realize it's much older, but I'm curious if it's related to using the CLT on JDK 1.8. Just an idea.
Additionally, it would help if we could see the turk.properties file (please don't share your access keys or secret key) to make sure the endpoints are well-formed. Thanks!

JRE 7 update 51 breaks java swing application; get error: access denied ("java.io.SerializablePermission" "enableSubclassImplementation")

After installing JRE 7 update 51, our java swing applications doesn't work.
We have added the now required manifest attributes, so the application updates fine through java web start, and starts up, but it fails right after the log on process with the exception:
[CORBA MARSHAL 1398079699 Maybe; nested exception is:
org.omg.CORBA.MARSHAL: vmcid: SUN minor code: 211 completed: Maybe]
Caused by: access denied ("java.io.SerializablePermission" "enableSubclassImplementation")
If we use JRE 7 update 45 (or earlier versions) this error doesn't occur.
We're using Weblogic 9.2.3 as application server.
Any suggestions for solving this?
Edit: The jar files are signed with VeriSign Class 3 Code Signing

I am not sure if that's really the probelm, but in addition to the manifest attributes your application has to be signed now (New security requirements for RIAs in 7u51).

The solution was actually quite simple.
The clients needed to add the following in their {java.home}\lib\security\java.policy file:
grant codeBase "https://mydomain.com:443" {
permission java.io.SerializablePermission "enableSubclassImplementation";
}