Eclipse/JVM fails to start due to lack of memory

Originally posted on Eclipsed:

Lately, when starting Eclipse, the JVM has failed to start.  A reboot of the system usually fixed the problem.  Until yesterday.  So I had to dig in and solve this problem.

I wanted to share my experiences with debugging this issue.

Added Note: This is not the bug by which Eclipse running under java 1.6u21 fails to pass the permgen size on to the JVM.  If you are running java 1.6u21 with Eclipse, don’t.

Determine why eclipse.exe is crashing with „-debug”

I edited my eclipse.ini and added the -debug option:


Then I ran eclipse.exe from the command-line, hoping to get a bit more information:

$ ./eclipse.exe
Error occurred during initialization of VM
Could not reserve enough space for object heap

Now that’s a clear error message!

I need lots of memory

You may have noticed some pretty…

View original 450 słów więcej

My favorite features of Scala – part I

During the last few months I’ve spent substantial amount of free time learning Scala and consider it time well spent. This article is first part describing my favorite features of Scala

Extractor Objects

Whenever you define a val or var, what comes after the keyword is not simply an identifier but rather a pattern.

val regex = "(\\d+)/(\\d+)/(\\d+)".r
val regex(year, month, day) = "2015/7/29"

The val regex is an instance of Regex, and when you use it in a pattern, you’re implicitly calling regex.unapplySeq , which extracts the match groups into a Seq[String], the elements of which are assigned in order to the variables year, month, and day.

Detecting missing and unnecessarily imported packages in OSGi bundles

When developing OSGi based application in Eclipse adding required import package declaration is assisted by PDE. In practice, it means that import package declarations are never missing – otherwise Eclipse project won’t comile and run. What programmers almost never do is to remove unnecessary declarations. Why would they if it works? In practice bundle manifests polluted with unnecessary imported packages can cause performance issues during bundle resolution and classloading and sometimes confuse Eclipse PDE during development.

To mitigate this problem I’ve created a small application leveraging the power of excellent BND library. I was really surprised when I run this tool against bundles from application I’m currently working on – some had literally hundreds of unnecessarily imported packages.

oipv 1.x
Usage: oipv [options]

  -j <jar1>,<jar2>... | --jars <jar1>,<jar2>...
        jars or folders to include
  -e <package1>,<package2> | --exclude-package <package1>,<package2>
        Package prefixes to exclude from analysis. You may want to
        excluded packages exported by JRE - javax.swing, javax.sql, etc.
        to avoid false positives
        print usage text

Application code available at GitHub ( – The app itself is available here:

Delete all disabled branches of a Bamboo build plan

Recently I found myself doing some Bamboo maintenance. Namely, I had to delete all disabled branches of build plan related to already deleted feature branches that Bamboo failed to automatically remove. At first, I tried this shell script, but it didn’t work for me with Bamboo 5.6.2 and I ended writing my own version. I’m posting it here hoping it will be useful for others too

Usage is very simple

groovy bamboo_delete_disabled_branches.groovy \
      --bamboo-url <BAMBOO_URL, i.e. http://mycompany/bamboo> \
      --plan-key <PLAN_KEY> \
      --user <USER> --password <PASSWORD>

You can also perform a simulation without actually deleting anything with „–dry-run” option.

Sprawdzanie wersji plików JAR

Niedawno znalazłem się w sytuacji, gdy musiałem sprawdzić wersje plików JAR by zapewnić zgodność tworzonego release-a z Javą 6. Nie udało mi się znaleźć gotowego narzędzia, więc napisałem coś własnego:

Program jest napisany w Scali, ale dla użytkownika nie ma to znaczenia. Po zbudowanie projektu użycia jest bardzo proste

$ jarversion

jarversion 1.x
Usage: jarversion [options]

  -j <jar1>,<jar2>... | --jars <jar1>,<jar2>...
        jars to include
        be verbose
        print usage text
Print jar file version number defined as the maximum version of all classes contained within jar file

$ jarversion --jars  "/apps/dev/eclipse-jee-mars-R/eclipse/plugins/,/apps/dev/eclipse-jee-mars-R/eclipse/plugins/com.sun.el_2.2.0.v201303151357.jar"

/apps/dev/eclipse-jee-mars-R/eclipse/plugins/ = ClassVersion(49,0)
/apps/dev/eclipse-jee-mars-R/eclipse/plugins/com.sun.el_2.2.0.v201303151357.jar = ClassVersion(50,0)

Można oczywiście poprawić kilka rzeczy, w szczególności format wyjścia i prezentować informacje, że np. 45.0 to JDK 1.1 a 52.0 to J2SE 8 ale nawet w obecnej postaci aplikacja spełnia swoje zadanie

Bundle-NativeCode: Using platform-specific DLLs from OSGi

Originally posted on holistic tendencies:

I’m currently doing some development on a large RCP application. One recent task required using a Windows DLL to open an email message through MAPI, which is made pretty easy with OSGi. But I encountered a few issues that I’m sure will bite other people.


OSGi now provides some support for resolving and loading shared libraries/DLLs in Java applications. A bundle declaratively specifies its DLLs and associated platform requirements in their bundle manifest using the Bundle-NativeCode header. This header value is then used when loading a DLL through System.loadLibrary().

TheBundle-NativeCode header specifies a number of comma-delimited clauses. For example:

Bundle-NativeCode: lib/win32/x86/http.dll; lib/win/zlib.dll;
    processor=x86; osname=win32, 
  lib/macosx/libhttp.dylib; lib/macosx/libzlib.jnilib;
    osname=macosx; processor=x86; processor=x86_64,

A clause specifies one or more DLLs. A clause is matched to the current platform using a set of parameters (e.g., processor and osname, but also osversion, language, or a selection-filter). Parameters of…

View original 408 słów więcej

Arquillian – solving org.dbunit.database.AmbiguousTableNameException: OL$

Jeśli podczas uruchomienia testów integracyjnych wykorzystujących Arquillian Persistence Extension uruchmionych względem bazy Oracle pojawi się błąd

arquillian.persistence.dbunit.exception.DBUnitDataSetHandlingException: Unable to clean database.
Caused by: org.dbunit.database.AmbiguousTableNameException: OL$
	at org.dbunit.dataset.OrderedTableNameMap.add(
	at org.dbunit.database.DatabaseDataSet.initialize(
	at org.dbunit.database.DatabaseDataSet.getTableNames(
	at org.dbunit.database.DatabaseDataSet.createIterator(
	at org.dbunit.dataset.AbstractDataSet.iterator(
	at org.dbunit.dataset.filter.AbstractTableFilter.iterator(
	at org.dbunit.dataset.FilteredDataSet.createIterator(
	at org.dbunit.dataset.AbstractDataSet.iterator(
	at org.dbunit.operation.DeleteAllOperation.execute(
	at org.jboss.arquillian.persistence.dbunit.cleanup.StrictCleanupStrategyExecutor.cleanupDatabase(
	... 181 more

to rozwiązaniem jest dodanie do pliku arquillian.xml wpisu

<extension qualifier="persistence-dbunit">
	<property name="schema">$nazwa-schematu$</property>