Codetrails Connect | FAQ

What is the difference between the local and shared completion modes?

The Local Completion Mode works with proposals you have applied locally and does not download or upload any data. Your applied proposals are not persisted, and are only used to recommend proposals during the same Eclipse session. This provides you with realtime feedback, where each applied proposal is immediately visible in the next proposal window.

The Shared Completion Mode downloads recommendation models that are based on the applied proposals of all users of a particular server. Your own applied proposals are uploaded and integrated into these models. This strategy does not give you realtime feedback, but the ordering of proposals will change after a model has been updated.

Local + Shared Completion Mode combines the realtime feedback of the Local Mode while also dowloading models. Proposals are ranked according to both the shared models and your locally applied proposals. As with the Shared Completion mode, your applied proposals are uploaded to the server to be combined with all users' selections.

What data is being shared?

The Hippie Completion plugin sends data about applied proposals. At writing, applied method calls and constructor calls are sent to the server.

You can select which applied proposals to share in the list of whitelisted packages. For example, method calls are only sent to the server if the type is in a (sub)package that is whitelisted. For constructor call completions both the type of the constructor as well as the expected type (i. e. left hand side of an assignment) have to be whitelisted before they are shared.

The default whitelist consists of:

android* org.apache.*
com.google.* org.eclipse.*
java.* org.jboss.*
javafx.* org.w3c.*
javax.* org.xml.*

You may add or remove any package in the preferences under Codetrails Connect > Sharing.

For method call completions, the data package consists of the following information:

  • Receiver type - The type of the object that the method was called on.
  • Applied method - The signature of the applied method.
  • User UUID - A pseudonymous identifier.
  • Session ID - A random identifier per Eclipse session. This is randomly generated each time Eclipse is started.
  • Message ID - A random identifier for the completion event.
  • Timestamp - The date and time the proposal was applied.
  • Receiver Coordinate - Can be used to identify the origin of the type, but is not used in version 1.0.

In addition to the above, there are two additional data packages for constructor call completions:

  • Expected type - The type expected in the current context, i. e. the left hand side of an assignment.
  • Applied constructor - The signature of the applied constructor.

How often is data being sent?

Not every completion event is sent to the server separately. The events are aggregated and sent in bursts. The aggregation strategy follows three rules:

  1. Upload as soon as n events have been aggregated. This number can be adjusted in the preferences under Codetrails Connect > Sharing. The default is 10 events.
  2. If after t minutes less than n events have been aggregated, the data is uploaded. This number can be adjusted in the preferences under Codetrail Connect > Sharing. The default is 15 minutes.
  3. If there is unsent data when closing Eclipse, the data is uploaded.

How often are models updated locally?

The first time you trigger a method or constructor call completion, local models are updated with any newer versions from the server. Afterwards, an update occurs every five hours.