Tuesday Mar 03, 2015

Announcing Java SE 8 Update 40

Improved performance, scalability and administration in Java SE 8 Update 40 will allow Java developers to innovate faster and improve application services. Here are some features and changes including JavaFX updates: 

JVM Reaction to Memory Pressure: “Memory pressure” is a property that represents the total memory usage (RAM) on the system. This new feature can be leveraged to reduce the amount of memory used on a system where multiple JVMs are deployed and control the amount of memory designated to be consumed by each JVM, avoiding Out of Memory Errors (OOMEs) from occurring.

Improvements to the native packager: Enables developers to create native-feel applications that do not require clients to have an existing Java Runtime installed. These self-contained applications can then be deployed into areas like the Mac app store. The application developer has full control over the runtime and application entry points.

Ability to modernize the JavaFX stack on Mac OS X: The JavaFX media stack has been ported on Mac OS X® from QTKit and Quicktime, which have been deprecated, to the newer AVFoundation framework. With this, developers using the JavaFX media stack can now gain Mac App Store acceptance and have the opportunity to have their applications released on the Mac App Store. 

Nashorn Support: Numerous Nashorn optimizations including support for dynamic languages are incorporated into this release. Also added is a Nashorn Class Filter, which provides fine-grained control over access to Java classes from JavaScript code via a new filtering interface. 

New Time Zone Date Updater Tool: This tool can consume the ‘raw’ time zone data (tzdata) rules from the IANA time zone registry database and convert those to the necessary format required by the JRE. This provides users with the ability to immediately update the JDK/JRE time zone rules with the latest updates from IANA. 

Find out more details in the release notes

Thursday Sep 04, 2014

Interview with Nikita Salnikov-Tarnovski

Nikita Salnikov-Tarnovski is the co-founder of Plumbr, the memory leak detection product. Besides his daily technical tasks he is an active blogger, a JavaOne RockStar and a frequent conference speaker at Devoxx, JavaOne Russia, 33rd Degree, TopConf, JavaDay, GeekOut, Joker, and Jazoon.

Q: What are your JavaOne sessions about this year?

Salnikov-Tarnovski: My two talks are about identifying and solving memory leaks in applications, one conference session titled “keep memory leaks at bay” and one tutorial called “where is my memory.” Both sessions relate to how Java applications consume and use memory while running. I will discuss how to monitor your production environment; how to detect memory leaks and other memory inefficiencies; what to do if your application fails because of memory leak or becomes unbearable slow due to Garbage Collection taking too long, and so on.

Q: Are you giving tips and tricks during those sessions on how they can use Plumbr’s product?

Salnikov-Tarnovski: Last year, I talked about Java memory leaks and I used our product to present solutions. This year, I will talk about general methodology and techniques on how these problems can be detected and solved with the aid of the best tools on the market including our tool and any other freely available tools.

Q: Why are memory leaks important?

Salnikov-Tarnovski: Memory leaks are one of the top reasons why Java applications crash in production. Other memory related problems, such as inefficient Garbage Collection can make your application just stall for some arbitrarily long time. And your clients will be effected. E.g. when you hit the search button on Amazon.com and this all of a sudden takes too long, it is probably because GC kicked in and said: “Wait some 10 seconds, I will look for some garbage”.

Q: Aside from your sessions, what do you have planned for JavaOne?

Salnikov-Tarnovski: The main reason why I attend conferences - apart from talking about our product, of course – is to meet the many bright speakers and attendees. When you're a senior engineer with 12 years of experience, you want to go to conferences like JavaOne to meet your peers - people who are smarter than you- because you can learn a lot from them. You can discuss your problems and get feedback, and share your ‘war’ stories. This is the main reason why I attend conferences and I advise all my fellow engineers to go to JavaOne and other Java conferences. I'm planning to go to Java conferences as long as I am in this profession.

Learn more about Core Java sessions in the JavaOne content catalog

Thursday Dec 19, 2013

Java Rocks More Than Ever

In a series of blogs full of technical detail and cross-platform comparison, senior developer Geert Bevin from ZeroTurnaround gives 10 reasons why Java is a great technology. He built software for musical instruments using C++, with Juce Library and CPython, and realized that he missed a lot from the Java ecosystem.

He has written the first six blogs, which include Java Compiler, the core API, Open Source, the Java Memory Model, HighPerformance VM and Bytecode. In his first blog about Java Compiler, he gives examples and recommendations on how to use the JVM's just-in-time, the compiler code versus the architecture, runtime rather than static or dynamic linking. 

Upcoming topics include: 
Intelligent IDEs
Profiling Tools
Backwards Compatibility
Maturity With Innovation

Wednesday Aug 07, 2013

Garbage First Garbage Collector Tuning

A new article, now up on otn/java, titled “Garbage First Garbage Collector Tuning,”
by Monica Beckwith, Principal Member of Technical Staff at Oracle, and performance lead for the Java HotSpot VM's Garbage First Garbage Collector (G1 GC), shows how to adapt and tune the G1 GC for evaluation, analysis, and performance.

As Beckwith explains, the Garbage First Garbage Collector is the low-pause, server-style generational garbage collector for Java HotSpot VM. It uses both concurrent and parallel phases to achieve its target pause time and maintain good throughput. A garbage collector is a memory management tool. When G1 GC determines that a garbage collection is necessary, it first collects the regions with the least live data – known as garbage first.

Beckwith describes the collection phases and marking cycles, lists default tuning devices, offers recommendations about how to fine tune and evaluate garbage collection, and shows how to respond to overflow and exhausted log messages.

She concludes her article as follows:

“G1 GC is a regionalized, parallel-concurrent, incremental garbage collector that provides more predictable pauses compared to other HotSpot GCs. The incremental nature lets G1 GC work with larger heaps and still provide reasonable worst-case response times. The adaptive nature of G1 GC just needs a maximum soft-real time pause-time goal along-with the desired maximum and minimum size for the Java heap on the JVM command line.”

Check it out here.

Thursday Jan 24, 2013

Coding on Crete with Java Specialist Heinz Kabutz

In a new article, now up on otn/java by yours truly, titled “Coding on Crete: An Interview with Java Specialist Heinz Kabutz,” noted Java commentator and consultant Dr. Heinz Kabutz shares insights about the Java platform and talks about his exotic life working as a developer on the island of Crete. Kabutz is well known as the author of the Java Specialists’ Newsletter which reaches some 70,000 developers worldwide.

In a previous 2007 interview, Kabutz lamented the large number of developers who do not engage in unit testing. He offered an update on this:

“The one place where unit testing is sorely lacking is with concurrent code. There are some tools that help find race conditions and deadlocks, but they typically find about a dozen faults per line of code. With such an amount of false positives, discovering a real problem is impossible.

Did you know that there is not a single—not even one—unit test for the Java Memory Model (JMM)? We have to just accept that it works on the Java Virtual Machine (JVM) we are running on. The theory is that if we write our Java code according to the JMM, the code will run correctly on any certified JVM. Unfortunately, the certification does not test the JMM thoroughly. Apparently, there are some tests for the java.util.concurrent classes, and so they assume that if these work, then the JMM must also be correct for that JVM.”

When asked about the greatest performance issues he remarked:

“The biggest performance issue today is still that we often cannot pinpoint the bottlenecks. Customers usually approach us with problems that they have not been able to solve, no matter how many man-months they've thrown at them. The most recent issue I looked at boiled down to a simple race condition. If two threads insert an entry into a shared HashMap at the same time, and the key's hash code points to the same entry in the table, then the HashMap can be corrupted and you might get two entries pointing to each other. This means that whenever you try to call contains() on the map, you risk getting an infinite loop.”

Check out the article.

About

Insider News from the Java Team at Oracle!

duke
Links


Search

Archives
« April 2015
SunMonTueWedThuFriSat
   
1
3
4
5
6
8
10
11
12
16
18
19
20
21
22
23
24
25
26
27
28
29
30
  
       
Today