Today, I Suck Less.

Yep, productivity not bad at all today. Quality of sleep, general mood, and things like that.

I suck.

Oh yeah. Big time.

Hibernate In-Memory Still Slow

I'm beginning to suspect that Hibernate setup with an in-memory is pretty much as slow as regular database Hibernate. Despite being recommended as a useful alternative for fast automatic testing.

Since I am feeble-minded, I think I shall try to look into it a little, instead of accepting the depressing reality. It's just that it's such a hugely soul-killing drag, despite only chipping away 10-20 seconds of spirit every test. Well, multiplication.

Will be updating here, probably.

Time for a Walk

Tests. Unpredictable OOMs. Slow. How the f* do you debug such things. Why not on every test? Why can't I just run the things I use, why does everything have to be wired in? Why is hibernate startup so f* slow?

Why am I wasting my... right, there is none.

Time for a walk, maybe the emotional turmoil -- I think mostly nervousness, anxiety, probably from a loss-of-control reaction, some anger, some depression -- will settle.

The Tokenizer Tail Wags The Java Syntax Dog

I'd like to register a complaint: the Java rules for package names are stupid.

Why the _ do the folder names, or components, have to be legal Java identifiers? Most probably because the package name is not designed as a syntactical element all by itself. Or even as a lexeme/tokens of its own, but a sequence of tokens. I suppose the Java syntax is designed as a sequence of lexeme/tokens. Probably under the influence of the long tradition of bottom-up syntax grammars, correct me if I am wrong.

And now, with the Java8 designers trying to reclaim some syntactic space from the past mistakes, another keyword is foreshadowed: underscore.

> Warning about single underscore identifier

Already annoyed by Eclipse Luna's (4.4M7) treatment of warning about this (and I haven't found a way to turn it off), I just discovered an even more annoying behavior, which put the annoyance count at two bits, which overflowed into this one post. Unfortunately it's unlikely to leave zero in the annoyance column to the right.

This behavior is that Eclipse won't do the "Move Type to New File..." refactoring as long as this 'warning' is available to make a fuss over. No wait, sorry; apparently now it is an 'error'. This makes no sense at all.

And then for the prize: one can't even rename package names. Presumably because the package name is all retarded, with that un-scannable underscore in it. Maybe it'll be better in the next revision.

A workaround is to comment out any package declaration or import that contains a package name with this terrorist underscore in it. Though that is likely to give other errors, of course...

In fairness, there are probably not many that have discovered the awesome power in naming your packages '_'. But I happen to have it as part of a Brilliant System, so this could get really painful if the Java designers would take this bad idea to completion.

As I started out saying, it makes little sense for packages to have to be 'good' Java names anyway. The requirement could be dropped with no forward compatibility problems at all. Sure, backwards compatibility could be a problem, IOW you may want to be warned when you write code that can't be compiled as Java7 code. OTOH, then why not use a Java(N<8 all="" be="" check="" compiler="" it="" java="" ll="" of="" p="" syntax="" then="" to="" your="">
Do class loaders check class names to not contain keywords, and comply to be identifiers? I don't think it checks resources. And why should it check class names beyond some simple sanity checks? That's only added complexity.

And if no other argument convinces you, how about the fact that there exist other languages, and that the JVM is positioned as and adapted to being multi-lingual, aka polyglot? Why should other languages have to put up with this nonsense?

Java 8, Luna, Subclipse

Yep, going to try Java8 already. I installed the JDK a couple of weeks ago, since I was updating Java7 anyway, and found that it would indeed appear as a JRE in Eclipse; but didn't take it further.

But now I am. Downloaded Eclipse Luna, 4.4M7. Tried to changed Java compiler settings to output version 7 class format, but allow Java 8 source. I had somehow got the idea that that should be allowed. And why would you output legacy 7 code as format 8, anyway? But it isn't allowed. So 8 in, 8 out, then. Seems to work fine.

But with J8 output, I had to install Java8 on a target server; so here's how to do that. You probably don't have to use all of it.

nano /etc/hosts # because sudo complained about not resolving hostname
sudo apt-get install software-properties-common # because 'add-apt-repository' wasn't there

sudo add-apt-repository ppa:webupd8team/java

sudo apt-get update

sudo apt-get install oracle-java8-installer

I also installed Subclipse 1.6. The file/folder status markers were added, but it wouldn't synchronize, "Unable to load default SVN Client", so I tried installing the SvnKit module too. I have the habit to try to install as little as possible, so one thing at a time, although a few restarts are needed. Still no go.

And then I saw the "SVNKit Client Adapter (Not required)", which makes perfect sense; so I installed that, and now these rather old Subclipse modules work inside the latest Eclipse.

So, done and done. Could be easier, but still comparably easy. Java 8 has arrived in my toolchain; to stay, I think. I read that it's very backwards-compatible, source-code wise.

---

Oh, right. Got an OOM during build, so the memory allotment param in eclipse.ini (inside the app) had to be edited too. Changed to "-Xmx1500m" from "-Xmx512m".

---

Ah, trying a lambda expression as first thing, of course. Error: "Lambda expressions are allowed only at source level 1.8 or above". That's nice, it knows about Java8 even at Java7 source setting. There's even a quick tip: "Change project compliance and JRE to 1.8". Well, yes to that, thank you; wow much thoughtful.

And isn't that just cute:

public static void main(String...args) {

   Sam sam = (a, b) -> a + b;

}

interface Sam {

  int bla(int a, int b);

}

---

Trying out what I thought would be the most important feature of Java8, the default (aka defender) methods. Of course, it turns out they don't work as I'd thought.

public class Java8Demo { public static void main(String...args) { Sam sam = (a, b) -> a + b; // SamDefend sd = (a, b) -> a + b; // The target type of this expression must be a functional interface } interface Sam extends SamDefend { int bla(int a, int b); } interface SamDefend { default int bla(int a, int b) { return a + b; } }// Sam sam = new Sam() { // The type new Java8Demo.Sam(){} must implement the inherited abstract method Java8Demo.Sam.bla(int, int)//// @Override//// public int bla(int a, int b) {//// // TODO Auto-generated method stub//// return 0;//// }// };}

Oh #. Blogger/blogspot sucks, especially for blogging software development stuff...why can't I just paste code with formatting intact?

public class Java8Demo {
 public static void main(String...args) {
  Sam sam = (a, b) -> a + b;
  // SamDefend sd = (a, b) -> a + b; // The target type of this expression must be a functional interface
 }
 interface Sam extends SamDefend {
  int bla(int a, int b);
 }
 interface SamDefend {
  default int bla(int a, int b) {
   return a + b;
  }
 }
// Sam sam = new Sam() { // The type new Java8Demo.Sam(){} must implement the inherited abstract method Java8Demo.Sam.bla(int, int)
////  @Override
////  public int bla(int a, int b) {
////   // TODO Auto-generated method stub
////   return 0;
////  }
// };
}

Meh. That's as close as it gets.

Close() But No Cigar

The ByteArrayInputStream.close(), it does nothing! And it thus allows reading bytes from the ByteArrayInputStream object after calling close() on it.

Of course someone like me has to make a mistake, closing the ByteArrayInputStream on creation. I did, by leaving a "try-with-resources" in place during refactoring, returning the 'implicitly' closed stream.

Result: 1-2 hours extra debugging, thinking that my code, using XMLStreamReader, tested with ByteArrayInputStream and string literals, had some error causing it to skip prematurely all the way to the end.

An easy fix is to use your own subclass and override close(). Something like this:

/**

* Otherwise, java input stream might return data even when closed. 

* {@link super#close()} does nothing. 

*/

@Override

public void close() throws IOException {

    this.pos = count + 1; // distinct from the 'real' EOF; might be useful.

    super.close(); // does nothing in super, but whatever. 

}

And why doesn't the standard library do this? There seems to be no performance penalty. Well, maybe there is, maybe it's kind of wrong to return EOF (-1) here, maybe it should throw an exception. But is returning bytes after closing better?