DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Coding
  3. Java
  4. Odd Practices in Java

Odd Practices in Java

Peter Lawrey user avatar by
Peter Lawrey
·
Jul. 02, 12 · Interview
Like (0)
Save
Tweet
Share
8.18K Views

Join the DZone community and get the full member experience.

Join For Free
There are a number of practices in Java which oddly baffle me. Here are but a few.

Using -Xmx and -Xms

The option -Xmx is widely used to set the maximum memory size. As noted in the Java HotSpot VM Options 
Options that begin with -X are non-standard (not guaranteed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the JDK.
 So you would think that such a widely used option would not be non-standard any more.  In fact there is a standard option -mx and similarly -ms. I don't know why these standard options are not use more widely, or even documented.

Using NIO for non-blocking IO only

Non blocking IO was a new feature of NIO for sockets.  However, the default behaviour for NIO Socket is blocking. Files are only blocking in NIO. NIO2 provides an asynchronous interface, but does it by passing your request off to an ExecutorService (which is cheating really because it doesn't anything do what you can't do better already)

Personally I prefer blocking NIO. Its is only suitable when you have a low number of binary connections, but it is an option which doesn't get enough press IMHO.


Using the 32-bit JVM to save memory

The amount of memory you save with a 32-bit JVM is far less than you might think. Modern 64-bit JVMs use 32-bit references by default for up to 32 GB heap sizes. It is unlikely you want to have a larger heap size (if only to avoid very long Full GC times)

The 32-bit JVM still has a smaller object header than the 64-bit JVM, but the difference is fairly small.
The 64-bit JVM can use more, larger registers (on AMD/Intel x64 systems) and a much larger address space allowing you have less memory limitations.

Using threads to make everything faster

Using multiple threads can increase your CPU utilisation and reduce the impact of IO latency. It doesn't solve all performance problems. It won't make your disks go faster, increase your network bandwidth, the size of your L3 cache, increase you CPU to main memory bandwidth or make your database significantly faster.

Similarly making everything concurrent won't make so much difference either. Do you need 1000 concurrent collections when you only have 8 cores? No matter how many threads you have, only 8 of them will be running at once, and if you have 1000 collections its quite unlikely that two will be using the same collection.

Use concurrency selectively for critical resources. Otherwise you risk not only increasing overhead and slowing down your application, but far worse is the increase in complexity you introduce.
Java (programming language)

Published at DZone with permission of Peter Lawrey, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • DevOps vs Agile: Which Approach Will Win the Battle for Efficiency?
  • Unlocking the Power of Elasticsearch: A Comprehensive Guide to Complex Search Use Cases
  • Secure APIs: Best Practices and Measures
  • What Is the Temporal Dead Zone In JavaScript?

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: