Add standard exports to the java client.

Don't include memory for now, it is non-trivial to get
cross platform.
On 24 August 2014 13:35, Brian Brazil <brian.brazil@boxever.com> wrote:

> On 24 August 2014 10:47, Matt T. Proud <notifications@github.com> wrote:
>
>> In
>> utility/initilisation/src/main/java/io/prometheus/client/utility/initilisation/PrometheusInitilisation.java:
>>
>> > + * (the "License"); you may not use this file except in compliance with the
>> > + * License. You may obtain a copy of the License at
>> > + *
>> > + * http://www.apache.org/licenses/LICENSE-2.0
>>
>> > + *
>> > + * Unless required by applicable law or agreed to in writing, software
>> > + * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
>> > + * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
>> > + * License for the specific language governing permissions and limitations under
>> > + * the License.
>> > + */
>> > +
>> > +package io.prometheus.client.utility.initilisation;
>> > +
>> > +import io.prometheus.client.utility.standardexports.StandardExports;
>> > +import io.prometheus.client.utility.hotspot.Hotspot;
>>
>> Again, this module is not portable, so a generalized Prometheus
>> initializer must not include it. One made customly for an organization may.
>>
> The entire point of this is to create this function and have it work for
> the vast majority of organisations, rather than asking every single user of
> the Java prometheus client to have to write and maintain this code
> themselves. If you say this isn't possible (which I'm very dubious of),
> then that's going to make the Java client much harder to get working than
> the others.
>
> What precisely isn't portable about this, and what can we do to workaround
> it?
>

Thinking on it, how about make this the default implementation but document
the cases where it won't work? An organisation can then choose not to use
it if they need to.