<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Java -</title>
	<atom:link href="https://stancalau.ro/tag/java/feed/" rel="self" type="application/rss+xml" />
	<link></link>
	<description>Effective Software Engineering</description>
	<lastBuildDate>Tue, 28 Apr 2020 20:18:33 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.8.2</generator>

<image>
	<url>https://stancalau.ro/wp-content/uploads/2017/09/cropped-stancalau-icon-e1511612290885-32x32.png</url>
	<title>Java -</title>
	<link></link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>GitHub Actions with Gradle to Set Up a Basic CI/CD Build</title>
		<link>https://stancalau.ro/basic-ci-build-github-actions-gradle/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=basic-ci-build-github-actions-gradle</link>
					<comments>https://stancalau.ro/basic-ci-build-github-actions-gradle/#respond</comments>
		
		<dc:creator><![CDATA[Cristian S.]]></dc:creator>
		<pubDate>Sat, 25 Apr 2020 10:48:48 +0000</pubDate>
				<category><![CDATA[Java in Practice]]></category>
		<category><![CDATA[CI/CD]]></category>
		<category><![CDATA[GitHub]]></category>
		<category><![CDATA[Gradle]]></category>
		<category><![CDATA[Java]]></category>
		<guid isPermaLink="false">https://stancalau.ro/?p=2075</guid>

					<description><![CDATA[<p>I don&#8217;t know about you, but setting up CI and dev-ops tasks freak me out. There are so many different platforms, libraries and configurations to set up just right that I&#8217;m usually overwhelmed. But what if there is a more developer-friendly way? Let&#8217;s look at how to set up a basic continuous development workflow using [&#8230;]</p>
<p>The post <a href="https://stancalau.ro/basic-ci-build-github-actions-gradle/">GitHub Actions with Gradle to Set Up a Basic CI/CD Build</a> appeared first on <a href="https://stancalau.ro">Stancalau.ro</a>.</p>
]]></description>
		
					<wfw:commentRss>https://stancalau.ro/basic-ci-build-github-actions-gradle/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Lombok Mutability Pitfalls and How To Avoid Them</title>
		<link>https://stancalau.ro/lombok-mutability-pitfalls/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=lombok-mutability-pitfalls</link>
					<comments>https://stancalau.ro/lombok-mutability-pitfalls/#comments</comments>
		
		<dc:creator><![CDATA[Cristian S.]]></dc:creator>
		<pubDate>Sun, 31 Dec 2017 17:27:28 +0000</pubDate>
				<category><![CDATA[Java in Practice]]></category>
		<category><![CDATA[Java]]></category>
		<category><![CDATA[lombok]]></category>
		<guid isPermaLink="false">http://stancalau.ro/?p=1423</guid>

					<description><![CDATA[<p>Find out how Lombok can unwittingly undermine good mutability and encapsulation practices and what to do about it. Object-oriented encapsulation best practices lead development towards only relying on mutators to change object state. Any other way of changing it is called a side-effect and is generally very unwelcome. Side-effects have a nasty habit of introducing [&#8230;]</p>
<p>The post <a href="https://stancalau.ro/lombok-mutability-pitfalls/">Lombok Mutability Pitfalls and How To Avoid Them</a> appeared first on <a href="https://stancalau.ro">Stancalau.ro</a>.</p>
]]></description>
		
					<wfw:commentRss>https://stancalau.ro/lombok-mutability-pitfalls/feed/</wfw:commentRss>
			<slash:comments>2</slash:comments>
		
		
			</item>
		<item>
		<title>Java Package-Info Annotation Generation with Gradle</title>
		<link>https://stancalau.ro/java_package-info_generator_gradle/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=java_package-info_generator_gradle</link>
					<comments>https://stancalau.ro/java_package-info_generator_gradle/#comments</comments>
		
		<dc:creator><![CDATA[Cristian S.]]></dc:creator>
		<pubDate>Sun, 26 Mar 2017 12:41:47 +0000</pubDate>
				<category><![CDATA[Java in Practice]]></category>
		<category><![CDATA[Gradle]]></category>
		<category><![CDATA[Java]]></category>
		<category><![CDATA[package-info]]></category>
		<guid isPermaLink="false">http://stancalau.ro/?p=1248</guid>

					<description><![CDATA[<p>Elegance and cleanliness in programming are important to me. Having a lot of package-info.java files scattered everywhere is an eyesore. However, that is exactly what I&#8217;ve prescribed in my earlier post about Java default nullability annotation set by a package. To define default package contracts throughout your project, you need to copy the same package-info [&#8230;]</p>
<p>The post <a href="https://stancalau.ro/java_package-info_generator_gradle/">Java Package-Info Annotation Generation with Gradle</a> appeared first on <a href="https://stancalau.ro">Stancalau.ro</a>.</p>
]]></description>
		
					<wfw:commentRss>https://stancalau.ro/java_package-info_generator_gradle/feed/</wfw:commentRss>
			<slash:comments>2</slash:comments>
		
		
			</item>
		<item>
		<title>Set Java Nonnull/Nullable Annotation By Package for Cleaner Code</title>
		<link>https://stancalau.ro/java-package-nullability-contract/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=java-package-nullability-contract</link>
					<comments>https://stancalau.ro/java-package-nullability-contract/#respond</comments>
		
		<dc:creator><![CDATA[Cristian S.]]></dc:creator>
		<pubDate>Wed, 08 Mar 2017 19:48:50 +0000</pubDate>
				<category><![CDATA[Java in Practice]]></category>
		<category><![CDATA[Gradle]]></category>
		<category><![CDATA[Java]]></category>
		<category><![CDATA[Nullability]]></category>
		<category><![CDATA[package-info]]></category>
		<guid isPermaLink="false">http://stancalau.ro/?p=1179</guid>

					<description><![CDATA[<p>What is a Java Null Annotation? Java null annotation (or nullability annotation) contracts are a way to mark the code in a way that static checkers know which parameters, variables or return types can be null. You would especially want to do that if you hate defensive null checks everywhere in the code, like this [&#8230;]</p>
<p>The post <a href="https://stancalau.ro/java-package-nullability-contract/">Set Java Nonnull/Nullable Annotation By Package for Cleaner Code</a> appeared first on <a href="https://stancalau.ro">Stancalau.ro</a>.</p>
]]></description>
		
					<wfw:commentRss>https://stancalau.ro/java-package-nullability-contract/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
