Probably not at the language level. If you watch the Goetz talk you linked to he answers this at 50m36s. The bytecode and JVM will be able to represent riefied generics, but at the Java language level they'll still likely maintain erasure for Object types.
Reified generics for reference types is a really, really bad idea. It solves a minor, itsy-bitsy-tiny problem, but pretty much ruins sharing of data structure among languages, because it bakes a specific variance model into the classes. For value types that's not a problem because they don't support subclassing anyway.
> For value types that's not a problem because they don't support subclassing anyway.
Could you please provide a reference for this?
Even a broad one like "a post on the Valhalla mailing list during the past summer" would be very welcome.
I'm eagerly awaiting for this feature and not being able to extend user-defined value types would be a bummer.
You'll have to search for a reference (I don't have one off hand), but obviously value types cannot possibly support subclassing. Why is that a bummer? That's how you'd want value types to behave and the only way they can[1] (without introducing explicit pointers and complex typing rules). Also, why would you ever want to subclass value types? It serves no purpose. Value types, however, will be able to implement interfaces, which, also, is exactly what you'd want.
[1]: For example, if B is a subclass of the value type A, what do you think would happen when you store a value of type B in an array of type A?
The video I linked to above talks about the restrictions (8m20s) placed on value types:
* They have no identity.
* Because they have no identity == comparisons is based on their data.
* They cannot have super classes or sub classes (they can implement interfaces though.)
* They are immutable.
* They cannot be null.
Good thing Kotlin already supports reified generics (with the current caveat that they must be used in inline functions), Java the language is less important these days than the JVM having support for the feature.
The joys of working for a company with in house developers, as long as I don't use something that would be extremely difficult to bring a new developer up to speed on (accounting for the necessity of said solution as well) I can generally make a case to use whatever.
I've got a mix of C#, Python, Kotlin and pl/pgsql code running in production right now and we've also for projects written in Node.js that are live as well. I've even got some F#!
No seriously Unsafe is not removed, it's not even deprecated because there is no replacement. I don't know where people get this idea from. Did anybody check the source? Of course not. Just repeating something somebody wrote on the internet somewhere.
well as others already pointed out, value types.
this changes the way how the JVM uses Memory in certain ways and might be a huge improvement for a lot of stuff.
specialized generics. this is a huge one, too, less boxing is always a win.
JEP-286 less typing.
Maybe Project Panama and maybe a even better AOT.
Compared to what JDK 9 brings, this is huge.
JDK 9 brings a Module system which was already possible (and a lot of stuff around it which didn't exist), a new GC algorithm, Tiff Image I/O, jshell, ALPN, http2 client, reactive-streams. (P.S.: not everything is complete here, but this stuff will probably be used by most)
JDK9 mostly brings stuff that was already missing and provided by other libraries. JDK10 will probably change a lot of more things in the JVM ecosystem.
If you want less typing, then you definitely want Lombok (https://projectlombok.org/). At JavaOne this year, they also showed a proposed shortcut for data object (@Data in Lombok).
public class something(String name, int age) {
...
}
I'm embarrassed to say that I've never understood the use case for Lombok. So, I write my code in Java with Lombok extensions. Then, another Java programmer goes to maintain it... and they have to learn Lombok?
That was my reaction the first time I was introduced to it. I looked at it again two years later and it just clicked. What's really cool is that the developer who has to go maintain it has 20% as much code to maintain.
Say you want a POJO with accessors, mutators along with equals and hashcode. Let it generate the methods by defining a class like:
@Data
public class something {
String name;
int age;
}
Lombok generates:
public String getName() { ... }
public void setName(String name) { ... }
public int getAge() { ... }
public void setAge(int age) { ... }
public boolean equals(Something other) { ... }
public int hashcode() { ... }
public String toString() { ... }
It might be worth a look at Immutables (http://immutables.github.io/) or FreeBuilder (https://github.com/google/FreeBuilder), both of which also use Java's built-in annotation processors to do code generation, but involve slightly less magic and produce generated classes which are not overwriting the original class.
The real win is when you do Effective Java chapter 1 immutable objects with @Builder. I worked at a Big Dumb corp that eschewed lombok, and required full test coverage of getter, setters, builders, toString, equals, and hash mehtods, and 100% javadoc coverage for all methods (even private methods). It was insanity, and carpal tunnel inducing. Lombok would have reduced the workload by 90%.
Yes! ... And there are a lot of stages between a fully immutable object @Value and @Data (described above). The @Builder is so much better than most but you can also easily create a POJO with a portion of its fields immutable too (a combination of @NonNull, @Getter, @Setter and @RequiredArgsConstructor).
One of the nice aspects of it is that if you have, say, a setter method which does something slightly unusual (e.g. setLastName does a call to setName(getFirstName() + " " +lastName) - unlikely example perhaps) then it stands out from the crowd of otherwise straightforward getters and setters.
I believe a similar argument could be made against using any 3rd party library. At some point who ever is maintaining your code will have to understand its dependencies at some level.
For lombok specifically, other languages have these types of features built in which of course people need to learn in order to use it.
I agree it isn't a perfect solution, but java is in dire need of boilerplate reduction features like this and lombok fills this need well.
I've been doing C# for while... soo nice to have this. Coming back to java was like "why am I repeating myself". They already did the diamond operator on the right hand side, this makes the left just as nice.
now let the flames begin!!!
Oh also found a use for SneakyThrows today... I'm bootstrapping a test server in my unit test, where all of the code and interfaces are designed for safety and no-crash... and this lets me short circuit right out of it when something bad happens, which in a test setup is what I want.
Getters and Setters are verbose, but usually model classes are contained in a single class anyway, and can be generated automatically with any IDE. I can glance at a typical bean and ignore the code bloat without any problem.
The real issue is that Lombok generated classes don't play well with the dozens of libraries that expect Java bean style methods for auto marshaling and serialization: json generators, commons bean utils, binding libs, etc.
What problems do you have? Lombok does bytecode generation, I've never had a problem using it with things such as Jackson. How would an external library even know when the bytecode looks the same? I'm entirely aware I might be missing something obvious, this is a genuine question.
You can argue against Lombok for other reasons but was wondering about this specific one.
Everyone has their own priorities, but ValueTypes are huge.
Also, I don't think this falls under Valhalla (and I'm not sure if it's been committed yet), but the possibility of reasonable type inference in Java 10 would make me rather happy.
Valhalla is pretty big. Goetz described it as pulling on a very long string. It's going to touch everything in the JVM, including reifing generics, although as I understand it, erasure of Objects may be here to stay for the language.
Erased generics will surely stay and are a good thing. If they were removed, Scala would be in trouble (or rather, scalac would have to perform erasure itself, which in turn would mean that interop from Java wouldn't be good anymore).
What's broken in the JVM isn't erased generics but instead runtime reflection that is a lie due to erasure. Type erasure though is definitely an example of Java getting something very right for the wrong reasons.
Are you attempting to separate the concepts of specialization vs reified generics? Java does neither right now, and both effects are due to type erasure -- the runtime simply doesn't have the necessary information. I'm not quite sure where you're trying to draw the line.
Furthermore, runtime specialization (as opposed to compile-time) would seem to require reified types. So that further confuses things. But you can definitely have reified types without specialization, which I think is the point that you are trying to convey.
It permits languages on the platform with substantially-richer compile-time type systems than the primary language on the platform with good interior stories (this was, IIRC, a substantial problem with Scala.NET.)
Is it, though? The most basic implementation, where things are still erased at runtime by the JIT, should be fairly simple, although it will not give the expected perf gains, of course.
Either way, CLR and C# did it a long time ago, and in the same time period when Java acquired its type-erased generics.
Value types combined with generic specialisation results in less memory usage, higher data locality, less gc pressure. Basically a big increase in performance on top of the already very good JIT.
Last weekend, I added Bouncy Castle as the security provider in my dev environment, but my server did not show ChaCha20 in the list of available TLS ciphers. I was not convinced that my server was even using BC. Knowing that if you don't know what you're doing and mess around with crypto too much that you can get burned, I gave up. ECDHE RSA AES GCM for now.
I think I see where you're coming on that. For most of my applications, I terminate TLS connections with nginx. I do use ChaCha for high-speed encryption in other areas, though. The BC libraries have always worked great for me.
I appreciate changes that make it easier to monitor and debug applications. Looking forward to some small goodies that I haven't heard much about before:
http://openjdk.java.net/jeps/228 - Add More Diagnostic Commands. For example more insight into JIT:ed methods and the code cache.
http://openjdk.java.net/jeps/158 - Unified JVM Logging. Logging from the JVM, e.g. GC logging and classloader logging, are configured and printed uniformly.
Oh, nice! At any given moment in time, how many server CPUs are burning cycles to create a full StackTraceElement array, just because the logger is set up to provide the convenience of call site information with every write?
Am I missing properties? Dear god it's 2016, with Java8, and we still don't have real, language-defined properties? I mean you can use Lombok (and if you're not, you should be!), but that's something that really need to be built into the language. C# has them, Python has them, Ruby has them .. even other JVM languages like Scala have them!
I'm really glad I get to do Scala development full time. Even with all the recent improvements to Java 8, I feel the future of Java isn't the language, but the JVM and all the other languages that run on top of it (Scala, Groovy, Clojure, JRuby, etc.)
I really don't understand why people love properties so much. Getters and setters are elements of bad style to me - like global variables or gotos. A language like Java (or indeed C#) - specifically designed for huge teams and enterprise programs - shouldn't provide syntax sugar for writing getters and setters.
Probably a rethink of the design. Why are you creating an object, then mutating its name from client code?
The whole point of an object is that client code shouldn't be concerned with such details as maintaining the state of each internal field. Try and think of an object as a single thing you send high level messages to you, instead of a struct, or a bag, or a hashtable.
Calls to mutate state, such as changing the name field, should be rare. I don't see the value in adding syntactic sugar to make it easier to mutate state.
He means you'd call `increment(25)` to say you've got 25 more, or `employee.suspend()` instead of `employee.setAccess(SUSPENDED); employee.setPay(0); employee.setBenefits(NONE);`
a guess, but i'd wager "rare" here meant the code should in the main prefer immutable data structures (etc), not that the invocations per unit time of a particular method should be low.
> a guess, but i'd wager "rare" here meant the code should in the main prefer immutable data structures (etc), not that the invocations per unit time of a particular method should be low.
Yeah I want to say that for us developers, "rare" is not something that we can code, without some serious sophistication.
More likely we code "if" and it is either "yes" or no".
To capture "rare", we need some serious tools - statistics, analytics etc etc. That is way beyond the regular developer toolset.
Something like obj.rename(newName). This might seem like a trivial change, but the underlying idea is that we're no longer dealing with a setter only affecting one particular field, but an abstract message that may affect arbitrary internal state.
It would probably look exactly like setName(newName).
For me a better question is - why is the name being changed?
What high level goal are you trying to accomplish that truly needs you to to directly mutate internal fields, after the object has already been created? Could the object - or system of objects - have been designed with a higher level interface, so that the outside world didn't have to concern itself with such things?
I guess not. Sometimes the cleanest thing to do is to just mutate a field - particularly for GUI objects.
I don't know if it's worth the overhead of having unthinking developers writing { get; set } for every field in every class because it makes things "easier".
> I guess not. Sometimes the cleanest thing to do is to just mutate a field - particularly for GUI objects.
I don't know if it's worth the overhead of having unthinking developers writing { get; set } for every field in every class because it makes things "easier".
I do not understand your point. First you claim that we should not mutate the field, then you claim that we should mutate the field.
Generally not mutate. And if we must mutate, mutate in a batch with a single method with a descriptive name.
We should generally not use goto or local variables either. Avoid reaching for these constructs first. But if it's by far the cleanest, and simplest way of solving the problem - which it usually isn't - go ahead and do it.
I would say that at that point, it ceases to be a simple setter method (or set property). It's not a simple case of mutating some element of a data structure of filenames as strings. There'd be some validation and error handling involved. It's a perfectly valid high level message to send a file object.
As an aside, I'd probably make a method called "rename" that does this, as opposed to something like "setName".
I agree that setter properties are often a code smell, but getter properties are nice for calculated fields. As a very simple example, consider the following (C#):
class Circle
{
public Circle(int radius) { Radius = radius; }
public int Radius { get; }
public int Diameter => Radius * 2;
}
I am yet to work in a Java project where I am allowed to use any of them.
Regarding the properties I really don't get what is the big deal.
No one used to complain about C++ properties, that besides having to write accessors and mutator methods, one needs to declare them on the header files as well.
Or the first version of C# properties isn't much shorter than how it is done in Java, which is still required when extra logic needs to be implemented.
It is been a few years since I have done any Python, but don't do they require two separate functions that are then mapped to a property declaration?
Thing is you don't really need to write getters and setters in modern Java.
They're quite a smell that you have no encapsulation, plus mutable state.
I find myself either
- Writing object oriented code with higher level operations that operate on data internally without exposing it via getters and setters.
or
- Value types that take values in constructor and provide naming and additional behaviour on that data (proper Value Types support will really help with this.)
or
- Data pipelines dealing with n-tuples. For which you might be tempted to reach for getters/setters but I'd tend to either use off the shelf tuple types. i.e. tuple(A,B,C) or classes with public fields, or interfaces with static factory to create instances. I'd love better support for tuples with named attributes (Like new c# has)
Loads of getters/setters is something that the frameworks of the last decade encouraged people to do but aren't really a thing any more.
Adding 8 comment lines doesn't help your argument. More importantly though, you need to consider the mental load of constantly thinking about and remembering whether something is a property or a method.
I used to be an advocate property syntax, but after seeing them used in C# and now in Swift I have completely changed my mind. It's an inconsistent mess that Java has avoided at the small price of some more lines of code (that are mostly auto generated and need no documentation)
Can you clarify what's inconsistent about properties in C# (seeing how this is the most obvious counterpart), and how it doesn't apply to Java's properties-by-convention?
In Java you can be reasonably sure that whenever you need something from an object you call a method of its class. That's one thing you rarely have to think about in practice. Yes there are exceptions (sometimes painfully inconsistent ones) where fields are accessed directly, but at least that gives you some performance guarantees. It's generally not a big concern.
In C# you do have to think about it all the time. Most types have both properties and methods and in many cases it's not obvious whether the author of that type had the same idea about whether or not something should be a property or a method as you do. Where you only have to remember a name in Java, you have to remember both a name and its syntactic category in C#. One more thing to keep in mind equals greater mental load.
In fact, the guidelines for choosing between one and the other include considerations that should be of no concern to the user of a public interface (https://msdn.microsoft.com/en-us/library/ms229054(v=vs.100)....). If any of these implementation details change, the logical conclusion would be to change the public interface from property syntax to method syntax or vice versa. That's what I call inconsistent.
If you're saying that the choice between getX() and x() in Java is also somewhat inconsistent then you are absolutely right. It's just not a problem on the same scale as in C#.
I would argue that the distinction is actually a good thing. If you're working with a reasonably well-designed library, then the fact that something is a method instead of a property tells you it might be doing some serious (or just slow) work. Whereas in Java calling getX() might do just about anything.
And if the implementation of a C# property changes in any of the ways that would make it a method, that probably deserves to be surfaced as a breaking change in the API. That's a feature, not a bug. eg, I would certainly want to know if the implementation of a property was changed from a field access to a network call.
The syntactical distinction makes us believe that there is a technical difference as well, but that is not the case. I find that misleading. If properties don't give us any technical guarantees, then a naming convention as in Java seems more appropriate to me.
And if you look at the guidelines I linked to, you'll see that the criteria that are supposed to tell us whether or not to use a property are much more subtle than making a network call vs accessing a field. Can you really justify a breaking change to a public interface because a type conversion is introduced in the implementation of property?
I think disguising a function call as a direct variable access is much more problematic than calling a function that may or may not do more than return the value of a variable.
That said, I do realize that reasonable people can absolutely disagree on this issue.
I think disguising a simple function call as a variable access is sensible. But yes, people can disagree on this. I think the C# and Java designers are probably all smart people who thought about this a lot more than the two of us. :)
>>Can you really justify a breaking change to a public interface because a type conversion is introduced in the implementation of property?
I just quickly re-read that page, but I don't see what you're referring to here.
"The operation is a conversion, such as the Object.ToString method."
But this only pertains to the conversion of the object on which the property is defined. In other words, you should have methods like ToString or AsEnumerable, rather than properties like String or Enumerable, even though other rules would indicate property to be valid (idempotent, fast, no arguments). This rule is just an indication that properties represent conceptual attributes of an object; and the result of a conversion of an object to something else is not an attribute.
There's no actual syntactic load in practice. You look at the documentation page (or, more often these days, at autocompletion list), and see all members. Whether they are properties or methods is readily indicated, and in case of autocompletion, it'll also insert the parentheses for you for methods.
Semantically, the difference between properties and methods is the same as the difference between data and behavior. Are you saying that it's not a useful distinction to have?
The worst case I tend to encounter across customer code is having properties with big bodies of several lines that should have been made proper methods in first place.
You could do this in Java, but therein lies the cultural problem: From my experience, the Java world is so accustomed to get/set method doing nothing other than getting and setting the value that any attempt to do more (validation included) is seen as "surprising" and is frowned upon in code reviews. I'd typically have to create a special "setWIthValidation" method to please people...
That'll be about as long as Java, sure. But most properties that are actually written in code don't need validation. In fact, most of them don't even have a setter. In C#, this means that I can do:
public Foo Foo { get; }
or for a computed property:
public int Foo => Bar + 1;
The real savings from property come when you use them, though - the extra pair of () doesn't feel like much, but when you start chaining properties, I find that not having () there significantly improves readability. Then, of course, Java also insists on `get` prefix by convention. So you have Java:
foo.getBar().getBaz().blah()
vs C#:
foo.Bar.Baz.Blah()
More importantly, the latter visually emphasizes the difference between accessing data and operating on it. You can see that "Bar" and "Baz" are data members, conceptually similar to "foo", whereas "blah()" is an operation.
> Regarding the properties I really don't get what is the big deal.
I used to feel the same as you, then I dabbled with Rails. I think the deal is that in Java there is a lot of noise in the code. So, developing feels like you need to do a lot of yak shaving before you get to actually work on what you intend to build.
As a result, properties on their own isn't a big deal, but it's one more thing to slow you down and make things a little less enjoyable.
When I see some one complaining code generation being design smell I gag a little at this hackneyed Fowler expression. I'm curios what do you think lambok does?
It does code generation. What id does not is _source_ code generation. That is, you never see the code Lombok generates, never have to maintain it, and never have a chance to break it by editing. You can see it as a macro substitution.
OTOH IDE-generated code is "normal" source code, adding boilerplate to your "real" code, not tracking changes in it automatically, and perfectly breakable.
Properties are not a huge deal, I agree, but they sure are annoyance in Java (compared to e.g. C#).
That is, instead of one line of the code declaring the property, we end up with 10 lines doing the same thing, because we also need to declare getter and setter.
So, a realistic "POJO" that has 8 properties, will have 8 lines of code in C#, but 80 lines of code in Java.
Sure, your IDE will generate the getter and setter, but when you are reading the code, you have to check whether getter and setter are trivial, or perhaps they do something else, too.
It is quite common to get burned by a setter that someone made so that, after setting the value, it also does other shit like, hit Google Analytics, which is why everything is so slow.
The above problem is super easy to spot in 8 lines of code, but much harder to spot in 80 lines of monotonic, repeatable code, especially so when they are decorated with another 100 lines of code that is IDE-generated comments like 'Sets the foo'/'Gets the foo'.
Properties mean a lot of things to different people, and C#'s can do stuff that you don't expect so I would guess won't make it into Java as they tend to prioritise reading code over writing it. Having said that if you look at https://www.oracle.com/javaone/on-demand/index.html?bcid=513... about 30 minutes in you might see Brian talking about something that may be close enough to what most people want from properties to satisfy them.
> Properties mean a lot of things to different people
Thing is, this is true whether your language offers syntactic sugar for them, or not. Properties already exist in Java, they just exist as a matter of convention and custom - but the expectations on how they behave are just as strong, and a misbehaving getter, say, is just as surprising and damaging.
Does anyone have a list of smaller gems that are not on that list? For example JDK 9 contains an implementation of the CRC32C-algorithm which can be used by web developers to create compact entity tags. I read somewhere that there is even hardware support for it but I'm unsure whether it's being utilized by the JRE.
The vast majority of projects, at my employer. I personally upgraded several hundred JVMs running several dozen services - upgrading was simple and almost entirely painless.
In addition to benefiting from the new features, being up-to-date is good for recruiting. You tell someone they'll be working with Java 6 and (in the absence of other evidence) they'll assume it's a legacy product suffering from chronic under-investment. Not exactly the impression you want to give job seekers!
I don't believe, given what they repeat at every Google IO when people ask about it.
Also I don't have any issue with Java as I do like the language and use it since JDK 1.0.1.
My issue is with Android Java, a forked version of Java with cherry picked features of Java 6, 7 and now 8, just because Google didn't want to pay Sun.
A version that will be even harder to write portable code when Java 9 and 10 come out.
Or perhaps they know better than to release confidential information about their roadmap?
I believe Google is running out of solutions to further optimize Android because they keep running into self inflicted Java roadblocks. If Fuchsia is any indication of their future efforts their next major overhaul will support multiple first class languages.
Check the bios of many of the major Android team leads, some of them were former Java developers at Sun, which I think has a big weight on Java's role on Android.
As for Fuchsia and Brillo, it remains to be seen if they will ever be productified.
Also I don't believe that Dart is a better option than Java in regards to performance.
The annoying thing is that Java 8 is the only currently supported version of the language. The glacial development speed somehow still manages to deprecate versions faster than they fall out of use.
While Java 8 is the only version that is freely supported from Oracle, it is still possible to buy commercial support for older versions of Oracle's Java platform.
The speed at which they stop freely supporting older versions feels much like a way to squeeze big, slow moving organizations for support contracts.
Are you serious? Even the worst shops I've been at have at least moved their JVMs to Java7 back around 2014. I mean you can take all your existing JARs from Java4 and run them on Java8 and nothing should break. Recompiling them might be another issue, but still not a huge one.
True, but if you are running something like WebSphere or Weblogic then upgrading your JVM invalidates product support. So, now you have to upgrade product versions, which often requires changes to deployment scripts, breaking changes in those products, new software licenses, etc.
Having said that being on and old supported version of these products means you are at least enjoying Java 6.
Yes, the problem is when you as a developer have zero value for the company IT and have to make the application run on the servers that IT configured for the whole enterprise, not just our snowflake application.
Earlier this year I was working with an outfit that was on Java 4 for A Really Important Business Application. That said, they were looking at moving to IIRC 7 just as I was leaving.
Most not totally old projects are on JDK8. Don't look at some crufty apache product, but look at medium size business apps... those have all been JDK8 for a while now.
Been coding Java for close to 20 years. Can anyone show me what's being done in the language to bring on newcomers, or did that ship sail 10-15 years ago?
Some ideas that would bring people back:
* Wildly new, terse, and clear syntax and a great library of built-in tools that are briefly and intuitively named.
* Easily write and design interfaces that generate both/either back-end or matching integrated front-end code which is off in its own directory and can easily be used by existing JavaScript and HTML.
* Similarly be able to generate the JavaScript front-end code that use those JS client libraries with easily writable/pluggable generators so that it can generate Angular 1.x, 2, ReactJS, Bootstrap, etc. in "best-practice" ways that can be updated frequently as the community changes.
* Simultaneously provide the option to serve very similar pages using straight HTML, degrading even to the point that a text only browser could use the site easily.
* Easily define responsiveness of pages.
* Support multiple 3D, 4D, etc. interfaces with customizable inputs to be forward-compatible without overdoing complexity (i.e. it's really pluggable).
* Similarly support generation of almost any kind of service integration, with easy pluggable authN/R.
* Easily scalable.
* Relational, noSQL, versioning DB (noms) support.
* Make fun books for kids and a site where they can share what they've written, write games, build things, etc.
* Make it integrate with every browser, even some older versions, operating systems.
* Make it compile low-level vs. byte code so it's fast as shit.
> great library of built-in tools that are briefly and intuitively named.
I dunno, guess this depends on what you need. The Java class library has so much in it, but I guess it's not overly intuitive due to the age of a lot of the packages. Personally, I don't think I'd have a hard time getting my .Net-loving colleagues accustomed to everything as is.
Java EE is another matter entirely, I gave up on it after the Java EE 8 clusterfuck that's going on and have just decided to use Spring for everything.
> Easily write and design interfaces that generate both/either back-end or matching integrated front-end code which is off in its own directory and can easily be used by existing JavaScript and HTML.
What are you looking for here? Automagic API's? spring-data-rest says hello. I still find it's better to write my own, but if you need something for a quick prototype there you go.
> Easily scalable.
How are you wanting to scale? Where is your bottleneck? This isn't on the language to solve, it's how you design your application. I can throw up 2,000 instances of an application, but whether the database behind it can handle 100K/tx/sec is another story entirely.
> Relational, noSQL, versioning DB (noms) support.
We've had JDBC, JPA, jOOQ, QueryDSL, etc, forever for the relational story. There's plenty of support out there for various NoSQL databases (Spring even has spring-data-cassandra which I am looking at using right now for an ES/CQRS design).
> Make it integrate with every browser, even some older versions, operating systems.
Why? Java in the browser is dead. If you want to write client-side stuff just use JavaFX and package using WebStart or an installer that bundles your JRE and dependencies.
> Make it compile low-level vs. byte code so it's fast as shit.
Java is already "fast as shit". The warmup time for HotSpot and initializing the JVM is probably the big complaint everyone has, but unless you are writing small command line tools it is a complete non-issue.
With that said, Java 9 will support limited AOT compilation of modules to reduce the time to get basic compiled versions of your classes - HotSpot will still profile the compiled modules, and if finds it is required it will deoptimize, re-profile through bytecode interpretation and reoptimize - just like it does with normal .class files (which are still required to run).
Thanks for the bullets. This is a good list but some of the points like "Easily scalable" and "DB support" are not cheaply available in any runtime and require careful attention to detail as well as domain-specific thinking. IMHO, the JVM already does a lot of heavy-lifting in this regard.
It comes down to this: are those developing the language thinking about how to add features just to try to hone and hold on to the enterprise developers that still use it, or are they thinking about what would make it more fun, productive, and practical?
Java's going to be around a long time. Those that stick with it will be fine. COBOL programmers made a lot of money in 1999, and some people still use Fortran.
But, Java's original big mantra was "write once, run anywhere." Such idealism then. Cool things have been done in the past few years, but can't we do more?
I work for Pivotal so I'm biased. But I'd take a long look at Sprint Boot in terms of "fun , productive , practical" Java: https://projects.spring.io/spring-boot/
In particular:
- curated and tested open source library dependencies to the point that you can generate a single JAR for anything you might want to build on the server: http://start.spring.io/
- Annotations and APIs to make REST service development a breeze
- Cloud connectors to make it easy to run your app on Heroku, Kubernetes, Mesos or Cloud Foundry, or to leverage NetflixOSS components, or to build stream processing applications (Spring cloud stream / data flow)
It is being downloaded and used at a very high rate (a couple million a month).
Spring Boot is awesome, thank you guys for your massive contribution. All of my co-workers are .Net guys and keep trying to say that Java is dead now that .Net Core is out, but I still haven't found a server-side solution better than Spring yet :)
Cool, but much less useful than the full suite of Spring projects (which is why I love Spring in the first place, it's basically batteries included but everything remains modular so I can pick and choose what I want). .Net Core is a great stepping stone, but between deployment headaches (I can just run yum install java-1.8.0-openjdk to get a JVM and run a spring-boot app, .Net Core forces me to bundle the runtime right now) and the lack of a cohesive integrated suite of components keeps my heart with Spring (even if I'm forced to use .Net at work more often than not).
>Make it compile low-level vs. byte code so it's fast as shit.
AOT compilation is not automatically faster than JIT compilation. Java already is fast as shit. If you're worried about that first 100 milliseconds, works is being done on AOT compilation.
AOT isn't for the first 100ms, it's to avoid the 10K invocations required on a method for HotSpot to determine a hot code path and optimize the method - that can take a lot longer than 100ms and why when you see the JVM used in the financial sector, for example, they go through a lot of effort to "warm" the JVM.
Of course without runtime profiling the AOT built code may not be optimized for the hot path correctly, HotSpot will still deoptimize in this case and begin profiling again - so it's not going to be suitable for everything until they allow you to capture profiling details and feed it into the AOT compiler.
Most of that seems overly specific and wouldn't be appropriate for the core of a general purpose language. There's a whole world of software outside of web applications. Leave that stuff to separate libraries and frameworks.
While I can't say with 100% confidence, I listened Graal presentation at Voxxed Days Belgrade one month ago and the presenter (IIRC, Martin Tonchev) said it won't be ready for JDK9 and that they aim at JDK10.
Or you could not make assumptions like this. There are more ways to represent dates than there are bones in my body. What seems like a silly way to you might be the preferred way for someone else, for a variety of reasons.
