<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Chrise Nwachukwu </title>
    <description>The latest articles on DEV Community by Chrise Nwachukwu  (@missbellum).</description>
    <link>https://dev.to/missbellum</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1839314%2F4d900fbc-0655-45b8-936f-6235129cde08.png</url>
      <title>DEV Community: Chrise Nwachukwu </title>
      <link>https://dev.to/missbellum</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/missbellum"/>
    <language>en</language>
    <item>
      <title>Fixing "DemoApplication.java is a Non-Project File"</title>
      <dc:creator>Chrise Nwachukwu </dc:creator>
      <pubDate>Thu, 24 Oct 2024 14:36:10 +0000</pubDate>
      <link>https://dev.to/missbellum/fixing-demoapplicationjava-is-a-non-project-file-1npg</link>
      <guid>https://dev.to/missbellum/fixing-demoapplicationjava-is-a-non-project-file-1npg</guid>
      <description>&lt;p&gt;If you’re seeing the error "DemoApplication.java is a non-project file, only syntax errors are reported", it means your IDE isn’t recognizing your file as part of the project. You could try any of these:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;Mark Directory as Source Root: Right-click the folder containing the file, then select Mark Directory as Sources Root.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Reimport the Project: Right-click pom.xml (Maven) or build.gradle (Gradle) and select Reimport.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Check Project SDK: Ensure the correct JDK is configured in Project Structure.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Ensure File Belongs to a Module: Make sure the file is included in a valid module within your project.&lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;These steps should help your IDE recognize the file as part of your project. Let me know if it works!&lt;/p&gt;

</description>
      <category>java</category>
      <category>codeeditor</category>
    </item>
    <item>
      <title>Handling Resource Leaks with Scanner and System.in in Java</title>
      <dc:creator>Chrise Nwachukwu </dc:creator>
      <pubDate>Fri, 18 Oct 2024 16:23:50 +0000</pubDate>
      <link>https://dev.to/missbellum/handling-resource-leaks-with-scanner-and-systemin-in-java-5g43</link>
      <guid>https://dev.to/missbellum/handling-resource-leaks-with-scanner-and-systemin-in-java-5g43</guid>
      <description>&lt;p&gt;If you’ve worked with Java’s Scanner, you know it’s important to close it to avoid resource leaks—especially when reading from files. But when it comes to System.in, it's different.&lt;/p&gt;

&lt;h2&gt;
  
  
  Should You Close System.in?
&lt;/h2&gt;

&lt;p&gt;You generally don’t want to close System.in because doing so will stop any future input. This can create issues if other parts of your program still need user input.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Safe Solution: try-with-resources
&lt;/h2&gt;

&lt;p&gt;Java’s try-with-resources makes it easy. It automatically closes the Scanner without closing System.in, allowing you to safely read user input.&lt;/p&gt;

&lt;h2&gt;
  
  
  Why Do IDEs Warn About Resource Leaks?
&lt;/h2&gt;

&lt;p&gt;Some IDEs (like Eclipse or IntelliJ) might flag a potential resource leak with Scanner, treating all instances the same. This can be misleading, especially when using System.in, but you can confidently ignore these warnings.&lt;/p&gt;

&lt;h2&gt;
  
  
  Best Practices:
&lt;/h2&gt;

&lt;p&gt;Use try-with-resources to ensure the Scanner is closed properly while keeping System.in open.&lt;br&gt;
Avoid manually closing System.in; let the JVM handle it.&lt;/p&gt;

&lt;p&gt;Example Code:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;try (Scanner objName = new Scanner(System.in)) {
    System.out.println("What's your name?");
    String userName = objName.nextLine();

    System.out.println("Hello, " + userName + "!");
}
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



</description>
      <category>java</category>
      <category>resourceleak</category>
      <category>errors</category>
    </item>
    <item>
      <title>Why Going Back in Git Doesn't Have to Be Scary</title>
      <dc:creator>Chrise Nwachukwu </dc:creator>
      <pubDate>Thu, 10 Oct 2024 16:18:24 +0000</pubDate>
      <link>https://dev.to/missbellum/why-going-back-in-git-doesnt-have-to-be-scary-145n</link>
      <guid>https://dev.to/missbellum/why-going-back-in-git-doesnt-have-to-be-scary-145n</guid>
      <description>&lt;p&gt;If you've ever been working on a project - like I totally have this week - made some changes, and suddenly realized you've gone down the wrong path—don't panic. Git has your back, and rolling back to an earlier point isn’t as complicated as it might seem. &lt;/p&gt;

&lt;p&gt;Fellow earthlings, we all make mistakes. Maybe it was a bug you couldn't squash, or maybe you just want to rewind and try a different approach. With Git, it’s more like hitting "undo" than wiping the slate clean forever.&lt;/p&gt;

&lt;p&gt;*&lt;em&gt;The "Just Looking Around" Option&lt;br&gt;
*&lt;/em&gt;&lt;br&gt;
Ever wish you could check out how things were in the good old days (aka, before your code went haywire)? You can "borrow" an old commit without changing anything in your current branch. It's like flipping through the pages of a photo album, but in code.&lt;/p&gt;

&lt;p&gt;You can quickly do this with:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;git checkout &amp;lt;commit-hash&amp;gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;This is a great way to peek at a past version, without committing (pun intended) to any changes. When you’re done reminiscing, just hop back to the latest version of your branch.&lt;/p&gt;

&lt;p&gt;*&lt;em&gt;Going Back, But Not All the Way&lt;br&gt;
*&lt;/em&gt;&lt;br&gt;
Maybe you messed something up, but you don’t want to wipe out all your recent work. This is where Git's "reset" or "revert" options come in. You can pick the level of rollback you need—soft resets let you keep your changes, while hard resets are for those "just nuke it" moments.&lt;/p&gt;

&lt;p&gt;But here's a tip: don't jump to hard resets too quickly. Git revert might be your better friend—it leaves a record of what happened and why you decided to undo it. Plus, it makes you look super organized.&lt;/p&gt;

&lt;p&gt;*&lt;em&gt;Branching Out&lt;br&gt;
*&lt;/em&gt;&lt;br&gt;
Ever wish you could split the timeline and try something different? Git makes it easy. You can create a whole new branch from a previous commit and work on a new feature or fix without messing with your main branch. It's a great way to experiment without risk.&lt;/p&gt;

&lt;p&gt;*&lt;em&gt;The Bottom Line&lt;br&gt;
*&lt;/em&gt;&lt;br&gt;
Git isn’t just about version control; it's about freedom. Freedom to make mistakes, test new ideas, and confidently go back in time if needed. So next time you feel stuck or stressed, remember: Git’s got you covered!&lt;/p&gt;

</description>
      <category>git</category>
      <category>reset</category>
      <category>commit</category>
    </item>
  </channel>
</rss>
