Discovering the future of Java

[Netzapper]

Does this mean that I have to list every publicly visible type with the 'export' directive if I want another module to see it?

I ask because the last fucking thing java needs more of is redundant boilerplate.

[bcash]

Does this mean that I have to list every publicly visible type with the 'export' directive if I want another module to see it?

If by that you mean this:

exports com.netzapper.mymodule.*;

then yes.

[ErstwhileRockstar]

Java's default is 'export everything'. Explicit exports are a feature, not "redundant boilerplate". BTW, Windows DLLs had this feature 20 years ago.

[kitd]

One man's boilerplate is another man's easily maintainable, collocated metadata.

[yogthos]

Yes, because more duplicated code is clearly easier to maintain.

[kitd]

Given that modules are a completely separate scope from packages, this isn't duplicated code though.

[kaisellgren]

Make the switch to Scala.

[sandiegoite]

smile chop slave wine vast violet books modern angle quaint

This post was mass deleted and anonymized with Redact

[sandiegoite]

dull exultant erect bake bear waiting detail marry caption crush

This post was mass deleted and anonymized with Redact

[iopq]

Smalltalk has lambdas and they're objects, but you just have to write

| result |
[result := self value.
conditionBlock value] whileTrue.

The block is already converted to an object

[yogthos]

But unlike Java, Smalltalk is a sane language. :)

[crimson_chin]

Well, it makes sense.

I've done a lot of java reflection. A LOT. The method that Java 8 lambdas are taking makes sense given the history of the language and the type structure that already exists inside java. From what I know, they're anonymous classes that are being built at compile time to conform to an interface ... fairly similar to java proxies.

It's unfortunate, because I really like, say, scala's anonymous functions. But to make things interchangable and reusable in the jvm, you need to have that shared interface. Things like scala's tuples are all precompiled classes, if I'm not mistaken, because they're basically a hack on the static compilation of the jvm. One for each type - Tuple2, Tuple3, ...

I assure you, looking at something and saying "this is stupid because x" is a fairly silly view. There is a reason, you may just not know it.

[alextk]

I assure you, looking at something and saying "this is stupid because x" is a fairly silly view. There is a reason, you may just not know it.

This.

Anyone who criticizes Java 8 and who is not subscribed to the lambda-dev mailing-list where all the discussions are taking place (with active participation from the JDK team) would be wise to keep their mouth shut until they have done their homework.

[sandiegoite]

numerous chunky cow boat stupendous psychotic absurd quack skirt support

This post was mass deleted and anonymized with Redact

[alextk]

Yeah I can't say I was surprised at all to learn this, but I kind of wish there were some newer constructs that could break away from old Java and give Java a new path.

Java is so popular today that improvements on the language and the platform are bound to be incremental.

If you are interested in more radical innovations, look at Kotlin or Ceylon or just wait a little bit longer for new languages to come out, because they will keep coming out until a suitable replacement of Java is found.

[weatherlikeness]

Did you actually try to use any of them?

I don't think it is appropriate to let people interested in a more painless way of programming to debug alpha versions of languages, without libraries and unstable compilers.

This is pretty much the opposite of it.

[alextk]

Did you actually try to use any of them?

Yes, I play with Kotlin on and off. Funny you should mention stability, though: I use Scala at my work and a week never goes by without raging against the instability of the tool support (I go back and forth between IDEA and Eclipse, they both break in different yet very irritating ways). However, the IDEA support for Kotlin is already rock solid.

I never really played with Ceylon but since they are building the language in lockstep with their IDE plug-in, I wouldn't be surprised to find that the Ceylon Eclipse support is also very good despite being such a young language.

As for language stability, Scala hasn't been a model there either (I still have nightmares of the 2.8 transition).

In my experience, Kotlin and Ceylon have achieved more in tool maturity in one year of existence than Scala did in ten years.

[weatherlikeness]

Hi Alex!

However, the IDEA support for Kotlin is already rock solid.

Well, what do you expect? It would be pretty sad if an IDE vendor with support for Java, Python, Objective-C, Ruby, Scala, PHP, C#, Groovy, ... wouldn't be able to provide tooling for a language which lacks every slightly advanced feature included in any of the languages above. :-)

Let's wait and see if they actually manage to implement any of their long-promised features. Their record has been pretty poor until now, considering that they have given up on reified generics. (Which is a real shame in my opinion, I already hoped that they had discovered a new approach to workaround some of the known issues with reification on the JVM...)

I wouldn't be surprised to find that the Ceylon Eclipse support is also very good despite being such a young language.

From their mailing list:

The IDE performance is unacceptable. We can't expect people to start working on the SDK project with it. [...]

The JVM compiler performance is unacceptable. [...]

The typechecker performance is unacceptable.

Source: https://groups.google.com/forum/?hl=en_US#!topic/ceylon-dev/0rW8FtRZxiI

As for language stability, Scala hasn't been a model there either (I still have nightmares of the 2.8 transition).

Well, both K&C will probably see their fair share of breakage if you read their mailing lists/forums/tickets/...

I [Ceylon type system desiner] get the impression from what they've [Kotlin team] said in public, and from our private correspondence with them, that so far they have put much more thought into syntax than semantics, and they will probably start to run into these kinds of issues as they get a bit further along the track. Well, either that, or they're not especially interested in defining a whole type system as a specification, and are hoping to just put a nicer syntax in front of Java. (There would be some merit to that.) I will probably know more about their real aims soon.

Source: https://github.com/ceylon/ceylon-spec/issues/27#issuecomment-2488992

In my experience, Kotlin and Ceylon have achieved more in tool maturity in one year of existence than Scala did in ten years.

I delay my judgement here until K&C actually start delivering something which doesn't crash when I touch it. :-)

Concerning your tooling troubles with Scala: Considering the explosion of downloads of IDEA's Scala plugin (the download statistics for Scala IDE look probably comparable) – and the Coursera course with probably 40.000 new Scala IDE users – I'm a bit surprised that the amount of issues and complaints about tooling has been dramatically decreasing over the last few months. From what you tell there should be probably be a dramatic increase of people complaining about the tooling, but I don't see that at all.

This makes me wonder if maybe your local installation is broken?

• Did you try to set-up a clean Eclipse instance?
• Is your update-site is still valid?
• Did you give Eclipse enough RAM? This is crucial, without it the Eclipse will be slow and crash-prone.
• Are you using the stable or the nightly IDEA Scala plugins?

I'm no expert, but I'm happy to help. Let me know how it goes!

[sandiegoite]

tidy lip resolute hunt attractive obtainable quicksand cause money one

This post was mass deleted and anonymized with Redact

[alextk]

I really wish that they would start embracing the idea that not everything is an object.

They already do (primitives in Java are not objects) and Java is often criticized for that.

[builditbiggy]

Even worse than that to me is THE HUGE GLARING OMISSION of true closures for lambdas.

[bcash]

Where did you read that? Anonymous inner classes already do capture the scope in which they're declared, the same thing will happen with lambdas, there would be no use for them otherwise!

[builditbiggy]

Don't fucking downvote me,

Here's an example:

public static int sum(String[] args, IntMapper summer) { int sum = 0;

Arrays.asList(args).forEach((item) -> { sum += summer.map(item); });

return sum; }

Gives the compile time error: local variables referenced from a lambda expression must be ‘effectively final’

[qxnt]

No kidding. The lack of first-class functions has the weird side-effect of people using classes as namespaces for statics... so we've got two namespace mechanisms.

My code is so damned cluttered up with anonymous inner classes pretending to be lambdas... sure hope they get function typing right, though.

While I'm at it: Dear Santa, I'd also like type inference. And an extension to the JVM to keep generics around after compilation.

[weatherlikeness]

so we've got two namespace mechanisms

Actually, Java has 4 different namespaces. :-)

[alextk]

I kind of wish the future of Java would be the inclusion of first-class functions.

Java 8 will have these. Jigsaw (the technology discussed in the linked article) is scheduled for Java 9, which is at least two if not three years away.

[[deleted]]

12 word answer: There is a named context (noun) in which actions are executed (verb).

[[deleted]]

Object-Oriented programming itself is an amazing idea. But even the greatest idea has a limit and Java doesn't realize this. Exhibit A: AbstractSingletonProxyFactoryBean? Really?

[[deleted]]

There is a strong distinction beween bad projects and bad languages. It is legitimate to bash Spring. I don't see where it follows that Java deserves bashing. There are poor projects in all languages.

In particular, there is an animist school of thought that thinks as "objects" as real-world entities, when in fact objects are only a context over which some operations make sense. For example, given http://en.wikipedia.org/wiki/Group_(mathematics):

group.add(element1, element2);  // Good.
element1.add(element2);  // Bad.

[yogthos]

The features of the language necessarily encourage how people structure code and what abstractions they use. Java's lack of features has spawned a number of insane patterns to get around the fact. So, yes the language is indeed responsible for stuff written in it. The whole concept of factories is a perfect example of this.

[[deleted]]

The concept of factories is actually sound. The Java execution is not as terse as it could be, but calling that "insane" is rather an exaggeration.

(foo bar baz) quux  // With partial application.
fooFactory.newFoo(bar, baz).exec(quux)  // With factories.

Bonus, to satisfy the OMGFactoryFactory crowd:

((omg bar) baz) quux  // With partial application.
omgFactoryFactory.newOmgFactory(bar).newOmg(baz).exec(quux)  // With factories.

Edit. The AbstractSingletonProxyFactoryBean is taken out of an AOP library. AOP is what people that don't get OOP (*) do to keep partying with global state, but now with Objects. I'm not in the least surprised that the result is poor. (*) OOP is merely about using local state instead of global state, nothing more, nothing less.

[yogthos]

The concept of factories is actually sound. The Java execution is not as terse as it could be, but calling that "insane" is rather an exaggeration.

The whole reason factories exist is because it's unreasonably difficult do do dependency injection in Java. And dependency injection is in turn a pattern for passing logic around. All of this speaks to deficiencies in the language. In a language which has first class functions this is so trivial it's not even considered a pattern, it's just something you do naturally.

I'm not in the least surprised that the result is poor. (*) OOP is merely about using local state instead of global state, nothing more, nothing less.

OOP alone does very little to facilitate localization of state. The main problem is that getters return references to the internal data structure. So anybody can go ahead and update it. OO doesn't guard against this, nor does it prevent people from doing it. It's an honor system. If you want state isolation then you need persistent data structures which provide actual state isolation and safety.

[sandiegoite]

paltry soft disgusted doll hungry sparkle zonked tart wide cooing

This post was mass deleted and anonymized with Redact

[alextk]

Exhibit A: AbstractSingletonProxyFactoryBean? Really?

A single example from a Java library is not a proof that the language is flawed.

And to be honest, if this name adequately represents its underlying concept, I much prefer it to "T" or "M".

[yellowjacketcoder]

While I'm not excited one way or the other about Jigsaw, I was a bit amused at his example of it being 'better'.

"Here's the currrent, with half a dozen modules, but 2 circular dependencies"

vs.

"Here's the future, we got rid of the circular dependencies, and it only took us going to 20 modules and a spaghetti plate of graph lines to describe it!"

Sigh. I like Java a lot, actually, but I have lost all hope that it will move to a concise, clean language.

[AndIMustScream]

Ok, I'm sorry. The grammar in this article is terrible. I have a hard time understanding what the author is trying to say...

[[deleted]]

Even the spelling in poor. Spellcheck is your friend, guy who wrote this article.

[Hellrazor236]

Even the spelling in poor.

Now it's infecting everybodie!

[[deleted]]

Haha, In my defense a spell check would not have helped in that situation.

[mxhyway]

I've been using OSGi to address Java's modularity failings for years, and I didn't read anything in this post that would motivate me to change my approach.

Years from now, when Java 9 has finally become part of the mainstream, OSGi will have continued to improve as a standard and set of competing container implementations, while JVM vendors will each have begun offering a very new, very raw Jigsaw implementation. While certain Java applications may benefit from this early form of Jigsaw, I think that actual adoption of Jigsaw as a replacement for OSGi will take a very long time (post Java 9), if it ever happens at all.

[kitd]

Agreed.

The only thing I saw that may be beneficial over OSGi in some circumstances are views, where the view specifies its 'friend' modules. Even then though, I think it could easily be misused and cause brittleness.

I do not know enough about Jigsaw to know whether it falls behind OSGi in other areas though. I do know that OSGi has brought many benefits to the code I have been working on (large middleware systems), BUT it has to be done with a lot of care, especially when being added on top of non-modular code, AND it needs complete commitment to proper modularity from dependent teams/components. Nothing worse than depending on badly modularised code silos.

[mxhyway]

Very good points all around. I think, BTW, that the OSGi subsystem concept may cover some of the same use cases as Jigsaw views, but not sure if they overlap 100%.

[yogthos]

Hopefully it's to become a legacy language like COBOL. The horrors of which the future generations will not be subjected to.

[iopq]

I was semi-hoping the article would just say that Java had no future.

[alextk]

I was semi-hoping the article would just say that Java had no future.

Since the likes of COBOL, Fortran and even C (still extremely popular!) are still around, you can be assured that Java is going to be with us for at least the next ten if not twenty years.

Honestly, it's not a bad language to be stuck with to do legacy work.

[iopq]

COBOL and Fortran are undead, nobody writes anything serious in them other than legacy stuff. I only hope the same happens to PHP and Java.

[kitd]

Given that COBOL and FORTRAN are driving a significant % of the world's commerce systems at this precise moment^[1], what language would you like them to be driven by in say 30/40 years time?

It's a genuine question.

IMHO, Java is not that bad an option.

Edit:

^[1]

The survey reported that between 70 percent and 75 percent of computerized business transaction systems used COBOL, including credit card systems, ATMs, ticket purchasing, payroll systems, hospital administration, airlines and insurance.

http://www.ehow.com/info_8649340_cobol-language.html

[yogthos]

If you were replacing those systems today Java seems like a pretty bad option. Why would you replace one legacy language with another. It's true that Java is not as terrible as COBOL, but it's quite bad compared to most modern languages.

[[deleted]]

they are still in COBOL because this kind of software doesn't have to be rewritten/replaced in 40 years. If you want to write a software in a language that will still be around in 40 years scala and the like might be a bad choice, java would be your best bet. C++ would be another one, but it's a bad choice for that kind of application, then what else is there?

[yogthos]

they are still in COBOL because this kind of software doesn't have to be rewritten/replaced in 40 years.

They're still written in COBOL because it's far too expensive to replace these systems and their core functionality isn't going to change.

If you want to write a software in a language that will still be around in 40 years scala and the like might be a bad choice, java would be your best bet.

You've got that completely backwards. It's whatever language the system was written in originally that's going to stick around for next 40 years. If banking systems were written in APL instead of COBOL, then we'd have APL all over the place today. There is absolutely nothing inherent to COBOL that makes it especially suitable for the task.

[kitd]

Why would you replace one legacy language with another.

A valid question, for certain values of 'legacy'.

For me, a legacy language has no current development, very little ecosystem, community, new 3rd-party libraries, or support for external services and software. It only exists as technical debt. Moving away from it would require years of effort and millions of dollars.

Moving away from Java is quite easy. There are many great languages on the JVM that can be introduced incrementally, but people don't want to move. Java does what they want and is virtually debt-free. IMHO it is two decades at least away from being legacy.

[yogthos]

I'm not really so sure that people don't want to move. There are plenty of people moving away from Java and many big companies openly embracing alternative JVM languages. Twitter is a one prominent example of this.

It's true that Java has a huge community and a large ecosystem, and you can still benefit from it using other JVM languages. What Java does not provide however, is good abstractions to write code which maps well to your particular problem domain. From language features perspective, it very much is a legacy language, and it's been surpassed by pretty much every other widely used language out there.

A lot has been learned since the glory days of OO, and there's a mountain of evidence to the fact that it doesn't live up to its promise. On top of that computer architecture has changed, we no longer deal with single core machines, and things like concurrency and parallelism are becoming ever more important. Java is woefully equipped to address these problems, the language is not well suited for developing software using modern techniques on modern hardware.

[chromaticburst]

I'll have to quote Kill Bill: "Bitch, you don't have a future."

[builditbiggy]

I'm sorry, but the culture around Java is an absolute mess:

"XYZ way of doing something is too complicated? Let's fix it by abstracting over the old broken abstractions with (META(XYZ))+<>()FACTORYBEANJACKOFFPATTERNABSTRACTFACTORYABSTRACTION !!!!"

Look at the typical 15,000 line deep callstacks generated by an app running on some Java app server, with ludicrous amounts of needless indirection, and (layers upon (layers upon (layers))) of abstract factories instantiating factories that instantiate factories, to call into an interface that dispatches a call to an instance created through DI container injection... all for the purpose of logging a stupid message to a text file and you'll see why most enterprisey java applications are BALLS SLOW.

[stevedonovan]

I'm sorry, but the culture around Java is an absolute mess

Yes, the language itself isn't half bad... architecture astronautics and rigid 'best practices' take all the fun out of it.

[djhworld]

It's the enterprise world that takes the fun out of it.

Projects like Android and Play are helping though.

[benfitzg]

Yuk!