new stuff in 1.8

[Roedy Green]

There are some little surprises in 1.8. Regex checking at compile
time, fake enums, lightweight, that can be retrofitted to magic int
code. I was asking for those back in the Java 1.0 days. Now they come
out is the wash as a side effect of annotations. Units of measure
consistency (without unit conversion).

A nullness checker incompatible with Intellij/FindBug's.

Checks that you remembered to initialise everything.

making sure you don't use == unless you used intern.

Checking GUI thread use.

 

[Joerg Meier]

fake enums, lightweight, that can be retrofitted to magic int
code

I could not find anything about that. Care to elaborate ?

Liebe Gruesse,
Joerg

 

[Roedy Green]

I could not find anything about that. Care to elaborate ?

These are not quite as built-in as I thought. You have to install
them with a rather grim process.

See http://mindprod.com/jgloss/annotations.html#CHECKER
for links to the bits you will need to try them out.

They are called Checker-Framework from the University of Washington.

It is just astounding what they are doing with annotations at compile
time.

Before Java, I mainly coded in Forth and Abundance (a Forth
extension). There you can use the same coding language for compile
time as run time.

Java seemed so hobbled by its complete lack of compile time
computation. You could not even embed a compile date or use alternate
libraries. Java seems to be evolving nicely.

 

[Sarah Connor]

Before Java, I mainly coded in Forth and Abundance (a Forth extension).
There you can use the same coding language for compile time as run time.

Java seemed so hobbled by its complete lack of compile time computation.
You could not even embed a compile date or use alternate libraries. Java
seems to be evolving nicely.

And Lisp did it even earlier and much better.

 

[Roedy Green]

And Lisp did it even earlier and much better.

Even Java drives me crazy counting () and {} nesting depths. Can you
imagine the effect of Lisp?

In Forth, everything is the same precedence. It takes some getting
used to, but eventually is becomes easier to read than precedence
languages. There are no subtle rules to trip you up.

Java trips me up frequently with + meaning either addition or
concatenation depending on the phases of the moon. They really should
have sprung for a separate concatenation operator, or at least have
IDEs display the + in a different colour or font depending on which it
means.

I also choke every time see a cast. Just what in the chain is it
casting?

 

[Simon Lewis]

Even Java drives me crazy counting () and {} nesting depths. Can you
imagine the effect of Lisp?

Seriously, if you are "counting" brackets there is something very very
broken in your approach and knowledge of editors and IDEs.

In Forth, everything is the same precedence. It takes some getting
used to, but eventually is becomes easier to read than precedence
languages. There are no subtle rules to trip you up.

Java trips me up frequently with + meaning either addition or
concatenation depending on the phases of the moon. They really should
have sprung for a separate concatenation operator, or at least have

WHAT? a separate concatenation operator? You may as well suggest they
dump java and go back to C.

IDEs display the + in a different colour or font depending on which it
means.

Some might.

I also choke every time see a cast. Just what in the chain is it
casting?

the type of the variable.... no other.

 

[Joerg Meier]

These are not quite as built-in as I thought. You have to install
them with a rather grim process.

See http://mindprod.com/jgloss/annotations.html#CHECKER
for links to the bits you will need to try them out.

I'm confused as to what this has to do with Java 1.8. As far as I can tell,
that's a third party library completely unrelated to Oracle or Java 1.8.

Liebe Gruesse,
Joerg

 

[Jeff Higgins]

The Checker Framework project may be found here:

I'm confused as to what this has to do with Java 1.8. As far as I can tell,
that's a third party library completely unrelated to Oracle or Java 1.8.

The Checker Framework is a Java annotation processor capable of
processing the new to Java 1.8 type annotations.

It is not "new stuff 'in' Java 1.8".

 

[Roedy Green]

It is not "new stuff 'in' Java 1.8".

Yes. I wasted a lot of time thinking it was.

I got the wrong impression because I learned of it from this
announcement
https://blogs.oracle.com/java-platform-group/entry/java_8_s_new_type

headed "Java 8's new Type Annotations"

 

[Andreas Leitgeb]

Seriously, if you are "counting" brackets there is something very very
broken in your approach and knowledge of editors and IDEs.

In Java, there's at least that distinction between braced structural blocks
and parentheses in expressions. And if expressional parentheses do not
properly pair up inside a structural block, then I can be pretty damn sure
that the compiler will tell me near to the spot and not just at the end
of the source file.

Structural blocks *should* be consistent with indentation, and thus not
necessary to count. (if not consistent, then who's to blame?)

Lisps parentheses are indeed horror.

WHAT? a separate concatenation operator? You may as well suggest they
dump java and go back to C.

I cannot follow *that* logic. Java, while refusing operator overloading
to the programmer, is burdened with one instance of exactly the kind of
overloading that they didn't want programmers to be able to do. Otoh.,
where "+" would really make sense (namely for BigInteger and BigDecimal)
it cannot be used.

How would having e.g. the "#" character for String concatenation
brought anything nearer to C (or C++) ?

Not that I had any false hopes of something changing here, of course.

Some might.

I think the main ones (eclipse and netbeans) don't, but it's been a while
since I last used netbeans, so I don't know if anything changed since back
then.

the type of the variable.... no other.

Are you serious about your interpretation of the question?

I share Roedy's point, when I have to write or read stuff like
(Type2)((Type1)var1.var2.method(foo("xyyz"))).abc.whatever(blah);
ok, it's not all that frequent and somewhat exaggerated, but what I come
across in real code is already more than it would be in an ideal world.

 

[Sarah Connor]

Lisps parentheses are indeed horror.

To someone who isn't using the appropriate tools (in particular,
paredit), it might seem that way, I suppose.

 

[Andreas Leitgeb]

To someone who isn't using the appropriate tools (in particular,
paredit), it might seem that way, I suppose.

Probably the best tool in the sad context of having to produce lisp
(or for slightly less-OT: clojure) code would be a source-level
translator from any decent language to lisp/clojure. (And "cat"
surely doesn't qualify.

PS: googled for paredit and found something related to emacs, but
the layout of those samples still qualifies as "horror" to me.
What's worse, I once had a colleague who used that lisp style
for C++ }}}}}}}}}

 

[Simon Lewis]

In Java, there's at least that distinction between braced structural blocks
and parentheses in expressions. And if expressional parentheses do not

Like a lot of other languages.

This is basic stuff. IDEs cope with them well. Good editors like Emacs
cope with them well. Complaining here is the equivalent of saying "I
cant google" IMO.

properly pair up inside a structural block, then I can be pretty damn sure
that the compiler will tell me near to the spot and not just at the end
of the source file.

or you keep an eye on things as you type/edit. Amazing idea I
know. There's this wonderful rocket science thing called "syntax hiliting".

Structural blocks *should* be consistent with indentation, and thus not
necessary to count. (if not consistent, then who's to blame?)

Lisps parentheses are indeed horror.

Not really. With a good editor. Like Emacs.

 

[Simon Lewis]

To someone who isn't using the appropriate tools (in particular,
paredit), it might seem that way, I suppose.

Or doesn't understand lisp.

It's no worse than anything else in other languages.

 

[Andreas Leitgeb]

Or doesn't understand lisp.
It's no worse than anything else in other languages.

Ok, I admit I'd even prefer lisp to certain other
computer languages, like e.g. Malbolge. ;-)

And now for something completely different...

back to Java.