<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Java on Random Ramblings</title><link>https://blog.foundev.pro/tags/Java.html</link><description>Recent content in Java on Random Ramblings</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 03 Feb 2021 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.foundev.pro/tags/Java/index.xml" rel="self" type="application/rss+xml"/><item><title>Heap Size Around 32 GB</title><link>https://blog.foundev.pro/2021/02/03/heap-size-around-31gb.html</link><pubDate>Wed, 03 Feb 2021 00:00:00 +0000</pubDate><guid>https://blog.foundev.pro/2021/02/03/heap-size-around-31gb.html</guid><description>&lt;h1&gt;Heap Size Around 32 GB&lt;/h1&gt;&#10;note: originally written Feb 3 2021&#10;&lt;p&gt;There was a question this morning around a pretty common discussion point around 31 gb versus 32 gb of heap. This &lt;a href="http://java-performance.info/over-32g-heap-java/"&gt;article discusses this in more detail&lt;/a&gt;, the key point follows:&lt;/p&gt;&#10;&lt;blockquote&gt;&#10;&lt;p&gt;Be careful when you increase your application heap size over 32G (from under 32G to over 32G) – JVM switches to 64 bit object references at that moment, which means that your application may end up with less available heap space. A rule of thumb is to jump from 32G right to 37-38G and continue adding memory from that point. The actual area of “grey” territory depends on your application – the bigger an average Java object in your application, the smaller is the overhead.&lt;/p&gt;</description></item><item><title>Snakeyaml error handling is tough</title><link>https://blog.foundev.pro/2019/12/27/snakeyaml-perms.html</link><pubDate>Fri, 27 Dec 2019 09:30:00 -0600</pubDate><guid>https://blog.foundev.pro/2019/12/27/snakeyaml-perms.html</guid><description>&lt;h1&gt;"Snakeyaml error handling is tough"&lt;/h1&gt;&#10;&lt;p&gt;Cassandra for years has relied on snakeyaml to parse configuration files, and it does a fine job, really not a lot of complaints. Until one day a colleague of mine discovered an issue where a permission issue incorrectly reported as an invalid yaml file (complete with the supposedly offending key). Digging into the source code and trying to match up the message. I found that &lt;a href="https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L128"&gt;we were handling YAMLException&lt;/a&gt;&lt;/p&gt;</description></item><item><title>Cassandra - Batch Loading Without the Batch The Nuanced Edition</title><link>https://blog.foundev.pro/2016/04/29/cassandra-batch-loading-without-the-batch-the-nuanced-edition.html</link><pubDate>Fri, 29 Apr 2016 16:03:56 +0000</pubDate><guid>https://blog.foundev.pro/2016/04/29/cassandra-batch-loading-without-the-batch-the-nuanced-edition.html</guid><description>&lt;h1&gt;Cassandra - Batch Loading Without the Batch The Nuanced Edition&lt;/h1&gt;&#10; My [previous post on this subject](https://blog.foundev.pro/2014/08/28/cassandra-batch-loading-without-the-batch-keyword.html) has proven extraordinarily popular and I get commentary on it all the time, most of it quite good. It has however, gotten a decent number of comments from people quibbling with the nuance of the post and pointing out it’s failings, which is fair because I didn’t explicitly spell this out as a “framework of thinking” blog post or a series of principles to consider. This is the tension between making something approachable and understandable to the new user but still technically correct for the advanced one. Because of where Cassandra was at the time and the user base I was encountering day to day, I took the approach of simplification for the sake of understanding. However, now I think is a good time to write this up with all the complexity and detail of a production implementation and the tradeoffs to consider.&#10;&lt;h3 id="tldr"&gt;&lt;em&gt;TLDR&lt;/em&gt;&lt;/h3&gt;&#10;&lt;ol&gt;&#10;&lt;li&gt;&lt;em&gt;Find the ideal write size it can make a 10x difference in perf (10k-100k is common).&lt;/em&gt;&lt;/li&gt;&#10;&lt;li&gt;&lt;em&gt;Limit threads in flight when writing.&lt;/em&gt;&lt;/li&gt;&#10;&lt;li&gt;&lt;em&gt;Use tokenaware unlogged batches if you need to get to your ideal size.&lt;/em&gt;&lt;/li&gt;&#10;&lt;/ol&gt;&#10;&lt;p&gt;&lt;em&gt;Details on all this below.&lt;/em&gt;&lt;/p&gt;</description></item><item><title>Java IoC containers and classpath scanning (or what I’ve been looking for from .NET for months)</title><link>https://blog.foundev.pro/2010/09/19/java-ioc-containers-and-classpath-scanning-or-what-i-ve-been-looking-for-from-net-for-months.html</link><pubDate>Sun, 19 Sep 2010 19:01:00 +0000</pubDate><guid>https://blog.foundev.pro/2010/09/19/java-ioc-containers-and-classpath-scanning-or-what-i-ve-been-looking-for-from-net-for-months.html</guid><description>&lt;h1&gt;Java IoC containers and classpath scanning (or what I’ve been looking for from .NET for months)&lt;/h1&gt;&#10;Frustrated with the typical way I saw IoC used in Java where every example I found involved thousands of lines of XML &#10;and/or Java code to configure Java beans or components.&amp;#160; This is very different than IoC typically used in .NET where most IoC containers allow &#10;you to "autowire" in their terminology up every class in an assembly with a couple of lines of code.&amp;#160; Having been coding in that fashion &#10;for several years in .NET I was dismayed when none of my fellow Java coders that I worked with or knew personally had any concept &#10;of the equivalent functionality, and instead informed me the IDE would be my help in maintaining these massive XML files. &#10;&lt;p&gt;Not content with their answers I burrowed into Spring, Guice and PicoContainer docs and found &amp;ldquo;classpath scanning&amp;rdquo; which is roughly&lt;br&gt;&#10;equivalent to &amp;ldquo;autowire&amp;rdquo; in .NET. Below is an example of this in Spring 3:&lt;/p&gt;</description></item><item><title>Project Management in Java: A Confused .NET Developer’s Perspective</title><link>https://blog.foundev.pro/2010/07/12/project-management-in-java-a-confused-net-developer-s-perspective.html</link><pubDate>Mon, 12 Jul 2010 11:00:00 +0000</pubDate><guid>https://blog.foundev.pro/2010/07/12/project-management-in-java-a-confused-net-developer-s-perspective.html</guid><description>&lt;h1&gt;Project Management in Java: A Confused .NET Developer’s Perspective&lt;/h1&gt;&#10;When I was first introduced to workplace Java the amount of ways one could define a project appeared to be restrictive, confusing and a point of frequent friction. While those things may all be true, it’s a great deal better than I would have expected since I was coming from a world where an upgrade to a newer version of Visual Studio requires your whole team to sync up to that same version!&amp;#160; So how do cross IDEA teams get any work done in the Java workplace? Do Java OSS projects require everyone uses Eclipse, NetBeans, or IntelliJ?&amp;#160; Does every new IDE need to have import/export filters for all of the other existing ones and if it becomes popular do the already present IDE’s have to include this? Which system is the best and what matters?&#10;&lt;p&gt;To answer these questions let break down what makes a project and while doing so compare and contrast the Java perspective with the .NET one.&lt;/p&gt;</description></item></channel></rss>