I just downloaded Eclipse on my Mac after a good six months without needing it and had numerous issues using it. First, it wouldn’t start and gave the error message below.
Alert: The JVM shared library "/Library/Java/JavaVirtualMachines/1.7.0.jdk" does not contain the JNI_CreateJavaVM symbol.
I realised that the openjdk 1.7.0 package I’d installed must be somehow overriding or interfering with the 1.6.0 JDK that Apple installs by default. So I went into Applications > Utilities > Java Preferences. As soon as I opened that I was prompted by a message that said that in order to open Java Preferences I must install a Java 6 runtime and asked me if I would like to do so. I obviously said yes after which I reviewed the order of JDKs in Java Preferences which was correct.
I also removed the openjdk 1.7.0 package I’d installed earlier to prevent it from disrupting my work again by running the command below which removed this entry from Java Preferences.
Next, as I created a Java project, I realised Eclipse was still operating with a JRE and unsurprisingly I couldn’t access the source code of the JDK libraries. To resolve both these issues at once I went into Eclipse > Preferences > Java > Installed JREs > Add and added the following path.
You’ll notice this path contains the essential src.jar. Then I went into Project > Properties > Java Build Path > Libraries, removed the existing JRE and added the new JDK. I was now able to open String.class and see the source and all was well.
Why is Java still such a nightmare on OS X after all this time? I really hope it improves with Java 8. Anyway, I wrote all this up in the hope that it helps others also struggling with such problems.
Bug 6941923 – RFE: Handling large log files produced by long running Java Applications
The first fix really made me laugh as this problem has existed for so long, been widely written about on the web and plagued many who made the rather novice and deadly mistake of using hashmap unsynchronized over the years. It’s also been a tricky one to debug once you’re hit with it as nothing really happens other than the one thread executing the hashmap code going into an infinite loop whilst still remaining in a RUNNABLE state and not a BLOCKED state which is what people tend to look for in thread dumps. The application may become unresponsive which may lead you to think that it’s probably just some slow code if you’re working with cpu intensive code like aggregate statistical calculations.
The key to effective debugging of such subtle concurrency bugs is to always have jvisualvm open on local processes and to check the real time thread visualisation tab frequently to see what your application is doing or if running live then to take multiple thread dumps either manually or programmatically and check for differences between them.
The second fix also made me laugh as this is another issue, though less critical than the previous one, has caused much inconvenience to both java developers, system administrators and support staff over the years. Large log files have resulted in periodic process restarts being incorporated and numerous emails being sent about running out of disk space. Can you believe that in this day and age we still run out of disk space? Much bash code has also been written to do log rotation manually as was the case in my last workplace and processing or reading large log files is also much slower.
Though, to be honest, I have to confess I’m a little confused by the Oracle bug system. On the second bug above it says ‘Closed, Will not Fix’ but at the same time under ‘Evaluation’ it says three new flags have been introduced so has the issue been fixed or not? I also noticed another bug which looked interesting: bug 7071826 – UUID.randomUUID() race condition. ID generation is a very critical function of any environment and if there was a race condition it could potentially be a serious and widespread issue but I noticed that in that bug there was no description of the problem; merely pointers to comments elsewhere but where? Where are those comments being held? Help me out if you know.
On a related note JDK7u6 introduces JDK and JRE support for Mac OS X!
The 7u1 release fixes six bugs of which two appear to be loop related (1,2). The bug with loop predication was the one that originally tainted the release of Java 7 as you might remember. If I was working for a startup or running my own company I’d move to 7u1 straight away but in a bank that’ll never happen. Still, at least, I’ve managed to persuade them to move to 1.6.0_25 due to a critical CMS fragmentation bug afflicting 1.6.0_23. 🙁
The 6u29 release appears to have skipped a build number which is justified in the release notes. This one has two bug fixes worthy of mention out of a total of five – one is where ‘java.net.InterfaceAddress’s equals method may throw NPE’ (odd) and the other is where there is a ‘Memory leak of java.lang.ref.WeakReference objects’ (how ironic!).
Regarding the mac release it is great to see the Mac get official recognition on the oracle java homepage and have the release packaged as a dmg rather than needing to be built from source. (It’s quite possible by the way that I’ve only just noticed this one and that it’s been there all along or maybe I’d seen this earlier and have forgotten!). Though I’m liking the steady progress Oracle. Keep up the good work. I hope you are working on Java 8 as planned for end of next year!
Software and bugs always have been and always will be inseparable. Java 7 certainly wasn’t going to be the first exception to this rule. Unsurprisingly, since internal testing can never compete with the testing that takes place through mass adoption, in less than a day after Java 7’s releasebugs surfaced with loop predication.
Oracle are aware of the issues and Mark Reinhold has suggested a work around while they work on fixes for an early update release. Though apparently update 1 will be security fixes only and loop fixes are more likely to appear in update 2 though they will try to push into update 1 if possible. Keep at it Oracle – you have our support.
Supposedly the bugs were found by Apache Lucene and Solr but I’m sure I’m not the first to wonder why these projects neglected to test with all the openjdk nightly snapshots and particularly with the release candidate.
NOTE: If this post interests you you should definitely check out the Java 7 celebration launch and the detailed technical breakout session videos here.
Watch the fascinating video discussion (also embedded below) about upcoming features in Java 7 & 8 between Adam Messinger, Mark Reinhold, John Rose and Joe Darcy. They talk about quite a few things that may not be general knowledge and certainly haven’t been committed to officially yet.
The upcoming Project Lambda in Java 8 will provide multicore support with parallel execution of lambda code. This makes sense as functions just define units of work and whereas the developers define how those units of work are composed they do not need to be concerned about how they are scheduled or sequenced – that’s the VM’s job. An analogy can be drawn between this and the kinds of things that ParallelArray can do.
Java 8 will provide Collection Literals which will finally eliminate boiler plate collection declaration and access code.
Java 8 will merge Jrockit into the Hotspot vm. This work has already begun in Java 7 with JMX enhancements and reduction of the use of permgen space. Permgen will be eliminated altogether in Java 7 updates taking inspiration from JRockit.
Java 8 may have big data support in collections (large collections) – 64 bit support and primitive collections.
There was a considerable amount of talk about the new invokedynamic instruction, the first new instruction since Java5, that will optimise how JVM languages perform but also help with parallelising closures but as I am not a language designer that wasn’t particularly relevant to me though I’m always happy to gain from evolving VM technology as that really is the true essence of Java in my opinion.
Needless to say I cannot wait for Java 7 but I absolutely cannot wait for Java 8. As Mark and Joe said Java 7 is an evolutionary release but Java 8 shall be a revolutionary release. I really must give credit to Oracle for getting all this moving after it remaining stagnant for so many years at Sun. My favourite features in Java7 are Project Coin and NIO2 and in Java 8 will be Project Lambda and Collection Literals though any VM features HotSpot gains from JRockit will obviously be significant.
Also, apparently, Java 7 is out tomorrow (7th July) though that post doesn’t actually clarify whether it’s just the party tomorrow or the release as well. I cannot believe Eclipse still isn’tsupporting Java 7 when every other major editor has had this for quite some time. I guess I’ll have to fall back to Netbeans for a while (IntelliJ I just can’t figure out how to use).
Jdk6u14 has been released with following notable changes (taken from release notes).
Java HotSpot VM 14.0
6u14 includes version 14.0 of the Java HotSpot Virtual Machine, which provides improved reliability, serviceability and performance.
Contributing to increased performance in this release are numerous enhancements to HotSpot’s optimizing compiler, more efficient SoftReference processing and improvements to Parallel Compacting garbage collection. Optionally available are two new features – escape analysis and compressed object pointers. A preliminary version of the new Garbage First (G1) garbage collector is also included.
Optimization Using Escape Analysis
The -XX:+DoEscapeAnalysis option directs HotSpot to look for objects that are created and referenced by a single thread within the scope of a method compilation. Allocation is omitted for such non-escaping objects, and their fields are treated as local variables, often residing in machine registers. Synchronization on non-escaping objects is also elided.
Compressed Object Pointers
The -XX:+UseCompressedOops option can improve performance of the 64-bit JRE when the Java object heap is less than 32 gigabytes in size. In this case, HotSpot compresses object references to 32 bits, reducing the amount of data that it must process.
Garbage First (G1) Garbage Collector
Garbage First, or G1, is a low pause, server style collector. G1’s primary advantages over the Concurrent Mark-Sweep (CMS) collector include incremental compaction, better predictability and ease of use. Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased. [..].
To try G1, specify these command line options:
In addition, the following options can be used to affect G1’s behaviour:
To set the max GC pause time goal in milliseconds that G1 will attempt to meet:
To set the time interval over which GC pauses totaling up to MaxGCPauseMillis may take place:
6u14 includes an experimental implementation of java.util.TreeMap that can improve the performance of applications that iterate over TreeMaps very frequently. This implementation is used when running with the -XX:+AggressiveOpts option.