Avoid using Optional#get

Fixes xdev-software/java-setup-template#8

Author: AB-xdev

.config/pmd/java/ruleset.xml

@@ -208,6 +208,36 @@
 	<rule ref="category/java/security.xml"/>
 
 
+	<rule name="AvoidOptionalGet"
+		language="java"
+		message="Avoid using Optional#get"
+		class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"
+		externalInfoUrl="https://stackoverflow.com/a/49159955">
+		<description>
+`Optional#get` can be interpreted as a getter by developers, however this is not the case as it throws an exception when empty.
+
+It should be replaced by
+* doing a mapping directly using `.map` or `.ifPresent`
+* using the preferred `.orElseThrow`, `.orElse` or `.or` methods
+
+Java Developer Brian Goetz also writes regarding this topic:
+
+> Java 8 was a huge improvement to the platform, but one of the few mistakes we made was the naming of `Optional.get()`, because the name just invites people to call it without calling `isPresent()`, undermining the whole point of using `Optional` in the first place.
+>
+> During the Java 9 time frame, we proposed to deprecate `Optional.get()`, but the public response to that was ... let's say cold. As a smaller step, we introduced `orElseThrow()` in 10 (see [JDK-8140281](https://bugs.openjdk.java.net/browse/JDK-8140281)) as a more transparently named synonym for the current pernicious behavior of `get()`. IDEs warn on unconditional use of `get()`, but not on `orElseThrow()`, which is a step forward in teaching people to code better. The question is, in a sense, a "glass half empty" view of the current situation; `get()` is still problematic.
+		</description>
+		<priority>3</priority>
+		<properties>
+			<property name="xpath">
+				<value>
+<![CDATA[
+//MethodCall[pmd-java:matchesSig('java.util.Optional#get()')]
+]]>
+				</value>
+			</property>
+		</properties>
+	</rule>
+
 	<rule name="AvoidStringBuilderOrBuffer"
 		language="java"
 		message="StringBuilder/StringBuffer should not be used"