What is the folder $HOME/.oracle_jre_usage for?

Phantasmagorium

Hello!

Today I updated my JRE to version 1.8.0_60. Afterwards I got a folder $HOME/.oracle_jre_usage/. In this folder is one file *.timestamp. What is that and what is that for?

Thanks in advance.

Phantasmagorium

96523ee1-4d97-41c2-ae63-a0da310f3fb5

Yes, Why has this appeared? Why this location? I also had this folder show up, ".oracle_jre_usage" containing on file called, "48ac84126bcac2aa.timestamp" - this folder was arbitrarily placed in C:\Users\"my name"\.oracle_jre_usage. Does it need to be there? Why was I not informed of it? Why was I not given an option as to where to put it? Can I move it somewhere else? Can I delete it? What is is it? What does it do? Is it necessary?

Unknown

Today I updated my JRE to version 1.8.0_60. Afterwards I got a folder $HOME/.oracle_jre_usage/. In this folder is one file *.timestamp. What is that and what is that for?

That is the default location for the Java Usage Tracker. See the Oracle docs

https://docs.oracle.com/javacomponents/usage-tracker/overview/

As that doc section shows you can create a properties file to enable the tracker and configure the location and contents of the logging.

The tracker has been around since the early Java versions.

410bc2b5-b443-45c6-91bf-274a391fec6e

The tracker has been around but, but there seems to be some regression in that it now puts this folder there even if you haven't actually enabled the tracker.

a6032747-3a9e-4c71-9029-c143f132a595

Hello Community!

I know that´s a old Question, but I´ve the same problem (on 8 PC´s) and today, finally, I´ve successfully create the properties file and the usagetracker save his log in an other folder.

BUT, this tiresome folder ($HOME/.oracle_jre_usage) appears also, so I think this folder/ timestamp has not to do with the usagetracker.

Is there any people out there how knows something about the folder/ timestamp in my files folder?

Best Regards

Hans

Unknown

I know that´s a old Question, but I´ve the same problem (on 8 PC´s)

Not sure what you mean - there IS NO problem. OP merely asked a question.

 and today, finally, I´ve successfully create the properties file and the usagetracker save his log in an other folder.

Ok - but as I said above that is EXACTLY what the properties file is for.

 BUT, this tiresome folder ($HOME/.oracle_jre_usage) appears also, so I think this folder/ timestamp has not to do with the usagetracker.

Is there any people out there how knows something about the folder/ timestamp in my files folder?

I already answered that in my first reply.

If you believe you actually have some 'problem' that needs addressed I suggest you create your own thread and post ALL of the info needed to help you. That info would include:

1. the os name and full version

2. the full java version

3. the path and classpath your test uses.

4. the test script or command window commands showing WHAT you do and HOW you do it and that use the path and classpath you provide in step #3

5. the properties file contents and full path and name

6. the contents of the oraclel_jre_usage folder and the folder where you say the log file is created

7. the contents of the log file

ed5d7af1-6a72-489d-8052-1a41f2a7c3df

I personally do feel this is a PROBLEM.

However that is because I have my custom app environment set up on a removable drive which I use on an ever-changing set of machines, using the concept of "Portable Apps".

Other people may not care, but I certainly do thing that Java should not arbitrarily create files and folders on the host system outside of its own JAVA_HOME environment, and certainly not in the top-level root of my OS' user directory when there is no good (user opted-in) reason for it.

The Oracle devs and PTB may not consider it a problem either.

I have solved it for myself by adding a line to the batch files that launch all my Java-driven programs, to delete that folder on exit.

Kludgey workaround, but may help others that are also annoyed by this behaviour..

--------

Update: found this bug report https://bugs.openjdk.java.net/browse/JDK-8134300