**Update (15th January 2014):**
Oracle has released Java 7 Update 51. We have tested our rich application client with it and with our latest avaialable update releases of 4.2, 4.3, 5.0. The application starts without any problem or warning.
Older update releases will no longer work with Java 5 7 Update 51 if you use Security Level *Very High* or *High* (default). The following error will be displayed:
![alt text][1]
The Details looks as follows:
![alt text][2]
However, you can set the Security Level to *Medium* to run rich application clients with older update releases.
**ivyTeam recommends to update to the latest Xpert.ivy update release instead of using the Security Level *Medium***
The Security Level can be changed in the Java Control Panel:
![alt text][3]
**Original:**
The simple answer: If you use Ivy 4.2.0.44424, 4.3.19 or 5.0.7 and higher, than your on the safe side. If you use older versions but at least 5.0.3 or 4.3.16 you are safe but you will see warnings for the [expired certificate][4]. Read on if you want to know more.
The permission entry was added already in the 5.0.3, 4.3.16 and 4.2.0.44424 releases. If you already use on of theses releases (or higher), then you are safe. If not, please consider updating. If you cannot update, please see the advices at the end of the answer.
We sign our jars since ever, just recently we delivered updates with a new certificate (see the [corresponding question][5]). So, unless you (un-)signed your installation yourself you have not to fear anything. If you signed your installation with your own certificate which was issued by a trusted Certificate Authority (CA), then you are on the safe side too. But:
- if you unsigned your installation, then please sign it again with your certificate or update to a signed version again.
- if you signed your installation with a self-signed certificate then it is not clear what will happen. Oracle writes at one point *"RIAs must contain (...) Code signatures from a trusted authority"*. Which indicates that self-signed jars will not work any longer. On the other hand, Oracle wrote a [blog entry with explanations how to self-sign jars][6]. Why should they if this will no more work. So, here unfortunately we cannot give you an answer. If you use a self-signed certificate and you want to be on the safe side, either use a certificate issued by a trusted CA or switch to the standard release of ivyTeam.
If you - after reading this - find yourself in a situation where you cannot update or change your installation and you fear that Ivy Rich Dialogs will no more run in future, we can give you the following advices:
- Use the new [Deployment Rule Set][7] of the JRE. This is a new feature intended for system administrators to define rules which Java RIAs can do what or what not.
- Use the even newer [Exception Site List][8] that will come too with Java 1.7.51. As this feature is new we cannot tell you more than what is written in the link.
- Do not update to Java 1.7.51. Turn off automatic updates and prevent users to install updates themselves. Unfortunately this will solve the problem only for a short time as JRE's have an expiration date since Java 1.7.10 (see in the [release notes][9] or [here][10]). Sooner or later the [Dialog “Java Update needed”][11] will be shown with the options “Update”, “Block” and “Later”)
[1]: /upfiles/java7u51Error.png
[2]: /upfiles/java7u51ErrorDetails.png
[3]: /upfiles/java7u51Security.png
[4]: http://answers.xpertivy.ch/questions/110/xpert-ivy-rich-dialog-client-certificate-soreco-ag-is-expired
[5]: http://answers.xpertivy.ch/questions/110/xpert-ivy-rich-dialog-client-certificate-soreco-ag-is-expired
[6]: https://blogs.oracle.com/java-platform-group/entry/self_signed_certificates_for_a
[7]: https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets
[8]: https://blogs.oracle.com/java-platform-group/entry/upcoming_exception_site_list_in
[9]: http://www.oracle.com/technetwork/java/javase/7u10-relnotes-1880995.html
[10]: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/client-security.html#jexpire
[11]: https://www.java.com/en/download/faq/expire_date.xml