Showing posts with label JVM. Show all posts
Showing posts with label JVM. Show all posts
Wednesday, May 15, 2013
Monday, November 19, 2012
O'Reilly Media book: Testing in Scala
Testing in Scala: 
Testing in Scala starts with an introduction of the Scala programming language, explains why project infrastructure is critical, and provides compelling reasons to use Scala testing frameworks to not only test Scala code, but Java code too. This book introduces and explains the Simple Build Tool, the Scala answer to Ant, Maven, Gradle, and Buildr. It then explains in detail all the best tools for testing Scala and Java code today--ScalaTest, Specs2, ScalaCheck, and Borachio. Testing in Scala also gives insight on how to integrate coverage tools, continuous integration, web acceptance frameworks, and Java testing frameworks that you already know and love.
Testing in Scala starts with an introduction of the Scala programming language, explains why project infrastructure is critical, and provides compelling reasons to use Scala testing frameworks to not only test Scala code, but Java code too. This book introduces and explains the Simple Build Tool, the Scala answer to Ant, Maven, Gradle, and Buildr. It then explains in detail all the best tools for testing Scala and Java code today--ScalaTest, Specs2, ScalaCheck, and Borachio. Testing in Scala also gives insight on how to integrate coverage tools, continuous integration, web acceptance frameworks, and Java testing frameworks that you already know and love.
Wednesday, September 28, 2011
Clojure 1.3 more Maven friendly - The H Open Source: News and Features
Clojure 1.3 more Maven friendly - The H Open Source: News and Features: The Clojure team has released version 1.3 of its dynamic programming language for the JVM; this includes new functionality, should offer better performance and supports compilation and deployment with Maven
Wednesday, August 31, 2011
Monday, July 11, 2011
iReport: Java Heap Space problems
JasperForge > iReport Forums
This thread discusses, how to solve this problem at filling and also at export time (JasperReports jargon).
Filling time configuration:
Export time configuration:
The above thread discusses how to pass a "java -XmxN" parameter via iReport. (This is good for manipulating the size of the memory allocation pool.)
Traditionally that was to be specified on the iReport command line.
The modern way to achieve this is through
This thread discusses, how to solve this problem at filling and also at export time (JasperReports jargon).
Filling time configuration:
- ... > iReport > Compilation and execution > Execution options > [_] Limit the number of records (=?!= REPORT_MAX_COUNT -> the iReport UG, 6.2.3)
- ... > iReport > Compilation and execution > Execution options > [_] Use virtualizer
- ... > iReport > Compilation and execution > Virtualizer; apress's TDG to iReport treats the Large Report problem (a little) in chapter 18 "Solutions to Common Problems": "... Using Report Virtualizer".
Export time configuration:
The above thread discusses how to pass a "java -XmxN" parameter via iReport. (This is good for manipulating the size of the memory allocation pool.)
Traditionally that was to be specified on the iReport command line.
The modern way to achieve this is through
/etc/ireport.conf
Monday, March 7, 2011
my call monitor software is going jruby
My FRITZ!Box call monitor is written in ruby-1.9. So far I am running it using MRI-ruby-1.9.
This call monitor is a FRITZ!Box call monitor, it does not monitor the calls on my smartphone yet (which is rather, rather sad). Most of the year (for economical reasons) I should sit in a customer's office quite a little away from my place – receiving calls on my smartphone. So it makes much sense to get my call monitor software to monitor the calls on my smartphone one day (rather sooner than later).
Just recently (with the help of RVM) I delved into the the jruby world, and of course I am trying to run my call monitor software also with "jruby --1.9".
My current problems with "jruby-1.6.0.RC2 --1.9" are with I18N and encodings, so I cannot open my gmail address book with "r:UTF-16LE:UTF-8". My evasive strategy is to let it read a UTF-8 version of it.
The ruby CSV module, that parses my address book using regular expressions, seems to give the runtime system yet unseen tasks.
Maybe I am not too far away from running a slightly adapter version of my call monitor in jruby and therefore on a JVM.
Of course, IronRuby (a .Net ruby implementation) is also an option.
There are not that many different smartphone operating systems, that run JVM-s, so we are mainly talking about Android.
Does Android allow non-core software to (sort of) monitor the incoming and outgoing calls?
Once jruby successfully runs my call monitor, the way is free to go for an Android implementation. I am rather hot for it.
Update 2011-03-07:
After a couple of postings on user@jruby.codehouse.org and especially with the support of Thomas E. Enebo, my software now runs just as well with the very, very latest jruby, that I produced through "rvm install jruby-head".
This call monitor is a FRITZ!Box call monitor, it does not monitor the calls on my smartphone yet (which is rather, rather sad). Most of the year (for economical reasons) I should sit in a customer's office quite a little away from my place – receiving calls on my smartphone. So it makes much sense to get my call monitor software to monitor the calls on my smartphone one day (rather sooner than later).
Just recently (with the help of RVM) I delved into the the jruby world, and of course I am trying to run my call monitor software also with "jruby --1.9".
My current problems with "jruby-1.6.0.RC2 --1.9" are with I18N and encodings, so I cannot open my gmail address book with "r:UTF-16LE:UTF-8". My evasive strategy is to let it read a UTF-8 version of it.
The ruby CSV module, that parses my address book using regular expressions, seems to give the runtime system yet unseen tasks.
Maybe I am not too far away from running a slightly adapter version of my call monitor in jruby and therefore on a JVM.
Of course, IronRuby (a .Net ruby implementation) is also an option.
There are not that many different smartphone operating systems, that run JVM-s, so we are mainly talking about Android.
Does Android allow non-core software to (sort of) monitor the incoming and outgoing calls?
Once jruby successfully runs my call monitor, the way is free to go for an Android implementation. I am rather hot for it.
Update 2011-03-07:
After a couple of postings on user@jruby.codehouse.org and especially with the support of Thomas E. Enebo, my software now runs just as well with the very, very latest jruby, that I produced through "rvm install jruby-head".
Update 2011-03-28:
Now it runs reading the XML Google Contacts, which is more comfortable, as I can download it on the command line.
Subscribe to:
Posts (Atom)
