Shamil's Blog. Software Engineering Processes, Android, CI, Devops.

I installed Debian 10 onto X220 laptop and discovered that it's no official support for Java 8 according to debian mailing list. Also an installation of recommended PPA containing Java 8 which requires adding gpg keys via apt-key fails. Little disappointed by the keys shit. I'm looking for some other options, as Java 8 is critical for me and I really don't wanna mess up with unofficial openjdk builds.

This resembles me a lot this almost comedian video on how hard to describe the life of sysadmin to non-it people. Palm, palm, palm.
Video link

So no Debian 10 for my X220. Thinking about arch (used it for some years, with some luck of failing video drivers - I don't have a good feeling about it being on laptop) or centos (happy with it on server, not sure about client). Also maybe a Debian 9 is a logical choice as seems like it has Java 8 supported by default.

Labels: arch, centos, debian, java, java 8, laptop, linux, openjdk, opensource, x220

In case while building there's flood of "symbol not found: DataBindingComponent" errors (which are fake), try to increase max number of errors with adding javacOptions after dataBinding into app gradle file:

    dataBinding {
        enabled = true
    }
    kapt {
        javacOptions {
            // Increase the max count of errors from annotation processors.
            // Default is 100.
            option("-Xmaxerrs", 500)
        }
    }

Labels: android, build, data binding, databinding, error, gradle, java, kotlin

On a way of migration of teamcity installation from one server and configuration to another I've bumped into https->http redirection in case of apache reverse-proxy setting under ssl.conf. Teamcity really has this bug not fixed yet (now v.7, bug reported for 5). Summary of places to edit in migration: 1. build-data-dir/config/main-config.xml (rootURL attr) 2. config/server.xml (add to connector:

proxyName="xxxxxx.com"
proxyPort="443"
scheme="https"
secure="true"

Httpd config is of no interest, just as manual says:

<VirtualHost [...]>
LoadModule proxy_module bin/mod_proxy.so
LoadModule proxy_http_module bin/mod_proxy_http.so

ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8111/
ProxyPassReverse / http://127.0.0.1:8111/

Labels: apache, http, httpd, https, java, linux, teamcity, tomcat

Just another bookmark:
http://developer.android.com/resources/samples/ApiDemos/src/com/example/android/apis/animation/Rotate3dAnimation.html

http://stackoverflow.com/questions/3452687/better-implementation-of-rotate3danimation-in-android-viewflipper

Labels: android, bookmarks, java, ui

just a bookmark for myself
http://www.helloandroid.com/tutorials/progressbar-updating-using-message-handler

Labels: android, bookmarks, java, links

2 projects (same roots for both actually) found:
- in-the-box (proj goal is to run android apps on ios)
- iSpectrum (sealed on sep 2010 when apple tighten cross-compiling rules)

My goal is to compile and run JokerME under iOS! Need to try this market for JokerME, to see devs interest.

Labels: compiling, ios, java, jokerme

Seen here http://javatechniques.com/blog/faster-deep-copies-of-java-objects/ an advice to use unsynchronized version of ByteArrayOutputStream which is faster than default java.io synchronized version.
It seems to make sense! But I have not yet benchmarked it.

Labels: ByteArray, java, optimization, synchronized

A thoughts of an old-school Java programmer while learning some iOS

..are not designed to be a fast-search-answer book. (search behaves bad actually). It's a tightly linked bundle of articles (with lots of html pop-up annotations!), which you have to read one after anohter. This creates a rich market of developers books, of course. But I'm not fan of overspending :-)

This stands in direct opposition to how Sun's Java docs were presented: to understand how to use library, one need to read only the class/interface descriptions (I can't remember I read package docs, anyone?); each class description is a very short and contains the concept of how it iteracts with others.

I think it comes from language differences: Java presents more plain classes without multi-file classes (.h, .m in ObjectiveC). So with proposed (by Sun?) javadoc inline style documentation Java classes are much easier to describe and support the changes.

Anyway, I spend more time to find information even in cases when I know what I'm looking for, comparing to Java SDK or ME docs or even Android docs.

For the Apple iOS docs, single place for navigating across whole bundle of articles could be very good.

Labels: docs, ios, java, programming

Endre Stølsvik has very detailed research and explanation along with workaround to a problem of broken thread priorities in linux in his blog:
Linux Java Thread Priorities workaround
The kind of situation when you'd like to have priority changed is accepting socket thread under high load (or, of course, a DoS attack ;-) ), or GUI dispatch thread.

BTW, my opinion for running java server-side is strictly solaris-based server, if you can afford it. At least you won't have OS LWP creation overhead for each java thread you start.
I had never tried opensolaris for java deployment, but it seems like just a different build of same beast. Did you?

Labels: java, linux, solaris, thread

http://blog.performize-it.com/
Саня, это для тебя будет интересно, детально про GC:
http://useless-factor.blogspot.com/2008/03/some-more-advanced-gc-techniques.html
Это блог товарища из команды Sun GC:
http://blogs.sun.com/jonthecollector/

Labels: garbage collecting, high performance, java

Escape analysis

JVM options tuning

Useful Hotspot options

---

Netty project (NIO)

Labels: java, jvm, links, netty, optimization

Interesting article on memory allocation policies in xen vs openvz vps: http://hostingfu.com/article/xen-or-openvz. Most interesting part is analysis on predictability vs performance and also notes about why is openvz is bad for java app hosting.

Labels: hosting, java, memory, openvz, vps, xen

Yesterday made simple experiment: recorded in log coordinates (x,y) of pointer press, drags and release events at real devices. During experiment I only clicked (not scroll!) at screen using finger. Devices are: Nokia 5230 and Samsung S5230.
Results impressed me a lot: bounce is up to 23 pixels (for y up to 15, possibly because of finger shape)!
This mean that if you need to differentiate scroll from click, you have to implement some kind of filter that takes into account time and type of movements of pointer.

Labels: click, events, j2me, java, mobile, nokia, pointer, programming, research, samsung, scroll

This cycle never ends!

for (float x = 16777213f; x < 16777218f; x += 1.0f)
{
  System.out.println(x);
}

Read more: Java's new math, Part 2: Floating-point numbers
or russian translation: Новые математические возможности Java: Часть 2. Числа с плавающей точкой

Labels: double, float, fun, java, math

Tested on local connection. Note the relatively large buffer sizes.

Socket=Socket[addr=/127.0.0.1,port=46179,localport=33333]
SEND_BUF=25350
RECV_BUF=43760
REUSE_ADDR=true
SO_TIMEOUT=0
SO_LINGER=-1
OOB_ININE=false
TCP_NODELAY=false
TRAFFIC_CLASS=0

Labels: java, network, socket

To make less mistakes in MIDP graphics it's important to know how is it work. Actually, MIDP docs and books I've read describes clipping and translation very superficially.
The notes 1 and 3 described below was some a surprise for me.
1. Graphics calculates and stores clipping: a) on each clipRect() call; b) in absolute (screen) coords.
Example:

clipRect(0,0,50,25)
translate(0,-25)
fillRect(0,0,50,50)

rect is painted with height 25
you could expect nothing on screen, but it's wrong.
2. (obvious) Graphics' clipRect() offset is expected in current translated coords. (see example below in (3))
3. Graphics always have clipping enabled (by default is's equal to the whole paintable area size, different depending on fullscreen mode).
Example:

translate(0,-25)
clipRect(0,25)
translate(0,25)
fillRect(0,0,50,50)

you get nothing painted, because on clipRect() call clipping was intersected with default clipping -> become (w=0,h=0) which is stored. On second translate call clipping area is not recalculated.

Labels: graphics, j2me, java, midp, programming

...because of two modules cannot have same content source directory.

Labels: idea, intellij, java

NOKIA:
System.getProperty("com.nokia.mid.batterylevel");

SONYERICSSON (via Sensor API, starting from JP-8.3):

SensorInfo[] batteryInfo = SensorManager.findSensors("battery_charge", null);
SensorConnection sensor = (SensorConnection)Connector.open(batteryInfo[0].getUrl());
Data data[] = sensor.getData(1);
String batteryLevel = "Current charge level: "+data[0].getIntValues()[0];

(from http://developer.sonyericsson.com/community/docs/DOC-2956)

Labels: battery, j2me, java, nokia, sensor, sonyericsson

Nokia
System.getProperty("phone.imei");
System.getProperty("com.nokia.IMEI");

Note ; Requires signed midlet. S60 3rd edition device does not requires signing for this to work.

Sony-Ericsson
System.getProperty("com.sonyericsson.imei");

Note ; might not work on all model.

Motorola
System.getProperty("IMEI");
System.getProperty("com.motorola.IMEI");


Samsung
System.getProperty("com.samsung.imei");


Siemens
System.getProperty("com.siemens.imei");

(from mobilepit.com)

Labels: imei, j2me, java, security

When you compile for CDLC 1.0 if you use SomeClass.class, you could get this error: "class file for java.lang.NoClassDefFoundError not found".
There're two ways of workaround: compile for CLDC 1.1 or use this style:
Class class = Class.forName("package.SomeClass");
instead of:
Class class = package.SomeClass.class;, although it has the right syntax.

Labels: j2me, java, NoClassDefFound, programming