Skip to main content

Sun JDK Java 6 to OpenJDK Java 7 recompilation on Ubuntu 12.04 and movement to Jetty 9.x

Recently I took up a task of moving our old project from Sun Java 6 to Open Java 7.
As such our project was using Spring, Hibernate, GWT and many more libraries.

There was a lots of fingers crossed when we took up this task, as we did not know the kind of impact it can lead to varying from refactoring to performance.

Kind of refactoring attempt which it took:


  • To begin with we need to do a change in our DataSource implementation as javax.sql.CommonDataSource has added a new method getParentLogger() . So we had to override that method in our class definition. 
          import java.util.logging.*;

          public Logger getParentLogger() {
                    return null;
          }
  • org.apache.commons StringUtils.join now takes an iterator then list. So we need to pass List.listIterator over there.
          StringUtils.join(List.iterator(),..)
  • There were project where maven-war plugin was not specified, that was leading us to problems. A specific pom entry was made to project to point to 2.3.2 version of the plugin.
  • The deb package version should not have any character only numerics and dots are allowed.
  • Jetty 9.x is official release for Java 7. So moving to Jetty 9.x is advised. ChangeLog for Jetty 9.x is available here. The way to start jetty have changed slightly. Java system property for port is not longer supported. Hence, you need to do 
          java -jar start.jar -jetty.port=8080 .

  • Https calls might fail with exception :

          [com.lifesize.mgmt.proxy.manager.tunnelserver.blocking.BlockingTunneledSessionReader] - <>
          javax.net.ssl.SSLException: java.security.ProviderException:                   sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1886)
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1844)
        at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1827)
        at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1753)
        at sun.security.ssl.AppInputStream.read(AppInputStream.java:113)
        at java.io.InputStream.read(InputStream.java:101)
        at    com.lifesize.mgmt.proxy.manager.tunnelserver.blocking.BlockingTunneledSessionReader.run(BlockingT unneledSessionReader.java:31)
       Caused by: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception:       CKR_DOMAIN_PARAMS_INVALID

This is a bug with opnjdk. Refer to the following links to fix this:



Will update this thread with performance issues as I discover more.

Popular posts from this blog

Why India Hasn’t Built Its GPT Moment (Yet)

India has the world’s third-largest startup ecosystem, a thriving developer base, and a mobile-first population larger than the US and Europe combined. Yet, no GPT-4. No DeepMind. No Amazon-style platform. Why? Innovation Isn’t Accidental—It’s Engineered The Zerodha Daily Brief recently asked why India hasn’t built a global product company like Apple. The key argument: India isn’t building for the world. It’s solving for local constraints, scale, and affordability—but global scale requires deep IP, design, and tech differentiation. It’s not just about software, it’s about systems thinking. More importantly, it answers the question: Why do countries innovate? The answer isn’t just genius or ambition—it’s incentives and ecosystems. The U.S. Defense Department, for example, accounted for nearly 70% of federal R&D funding during the Cold War. China has pumped billions into semiconductors and AI with long-term national alignment. These aren’t short-term bets—they are strategic, delibe...

The Death of the Stubborn PM

Product Management is undergoing a seismic shift, much like programming did when compilers replaced assembly language or when Agile dismantled waterfall dogma. Stubborn PMs who cling to outdated rituals—like treating PRDs as sacred texts—will fade into irrelevance. The future belongs to those who embrace AI as a collaborator, not a threat.   AI Will Disrupt the Tactics, Not the Thinking   Historically, tools abstracted manual work: compilers automated code translation, A/B testing replaced gut-driven debates. Similarly, AI will automate tactical PM tasks—data aggregation, routine prioritization, even drafting specs. But this is liberating, not limiting.   The stubborn PM obsesses over *how* to write a PRD; the adaptive PM focuses on *why* a product should exist. AI can’t replicate judgment calls that demand intuition: interpreting unmet customer needs, balancing ethics with growth, or navigating ambiguity when data is sparse. As AI handles execution, the PM...

From Stubborn to Smart: How I Learned to Use AI as a PM

Listen to the article in podcast format on PM-AI Diaries channel on Spotify! Ever since I published "The Death of the Stubborn PM" back in February, my inbox has been buzzing with one big question: “Okay, I get that AI is the future for product managers—but how do I actually use it?” It’s a fair ask. In that piece, I argued that PMs who resist AI are doomed to fade away, like dinosaurs refusing to evolve. As I wrote, “The stubborn PM who clings to old ways will die out, replaced by those who harness AI’s power while leaning into what makes us human.” Now, people want the playbook. So, let’s walk through it with a story—my own journey of figuring this out, backed by some sharp insights from MIT Sloan’s "When Humans and AI Work Best Together—and When Each Is Better Alone" . The Wake-Up Call Picture me a few months back: a PM buried in work, juggling a dozen tasks, and feeling like there weren’t enough hours in the day. Writing user stories, sketching ideas, track...