I'm deeply missing hot swapping. I believed it could be included in java 9 but i think we have to wait...
Are you aware of DCEVM? https://github.com/DCEVM/DCEVM#readme
Java 9 features announced
81–90 of 228 posts
Re: Java 9 features announced
#82Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.
Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?
IMO Dart has the best implementation of properties, which you can start out as normal fields, e.g:
class Rectangle {
num left, top, width, height, right bottom;
}
var height = rect.bottom - rect.top;
class Rectangle {
num left, top, width, height;
num get right => left + width;
set right(num value) => left = value - width;
num get bottom => top + height;
set bottom(num value) => top = value - height;
}
Re: Java 9 features announced
#83Earlier quoted context omitted.
Amen. How about some language keywords like "readable" and "writeable"? public class Foo { public readable int canSeeeMeButCantChange; public writeable int cantReadMe; public int existingBehavior; } These are pretty simple changes to the compiler and verifier. You would make canSeeeMeButCantChange an invalid "left hand" variable in the compiler, and the verifier would have to check for any writes to the fields. cantR…
The other "Missing feature" is null safe ".". Other languages have it, but I don't know what the technical name is... basically: Integer val = some.other.chain.of.objects.value; In Java, this code has a huge potential for NullPointerExceptions. Instead a new operator (yes, I know) like: Integer val = some.?other.?chain.?of.?objects.?value; If any of the intermediate objects are null, the whole assignment becomes null…
This is called null-value propagation. It's coming to C# (6) this year.
Re: Java 9 features announced
#84I'm deeply missing hot swapping. I believed it could be included in java 9 but i think we have to wait...
What is wrong with restarting your application?
Edit: Real Hotswapping will requires profound changes to the memory model. It would introduce too much complexity. I rather restart my application than to suffer from a fragile and leaking platform.
Re: Java 9 features announced
#85Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.
Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?
To add another example to the list, Ruby lets you list which attributes can be read/written and which ones can only be read on top. Something like.
class Car
attr_reader :model, :company # only read
attr_accessor :color # read and write
endRe: Java 9 features announced
#86Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.
And making your instance variables public doesn't solve that for you?
If you want a quick and dirty method that won't bite you in the ass, you can declare the variable public final. If you can live with all that entails.
Re: Java 9 features announced
#87Earlier quoted context omitted.
[deleted]
Here's a class C with a variable v of type T. It's supposed to be something that the rest of the world can access. You can make it public. Or you can make it private, and write public T get_v() { return v; } So far, not much difference. Both let the world access the variable, and both break encapsulation by doing so. The difference comes when the class gets more complicated, and v changes. Now v might be null, wherea…
"P.S.: How do I specify code formatting on HN?"
I'm not sure if there is one. But if you want, just make a pasteIt, or a fiddle. Not sure which one is the one that caters for C/C++ code.
Re: Java 9 features announced
#88Earlier quoted context omitted.
Is that not what final does? I'd be interested in seeing C#-like getters and setters. As long as they're just getting and setting, they're implied, but if you want to introduce a check or some other logic, you can do so without changing the signature of the class . Groovy does some of this, but it requires you to use the name of the field - ie. person.age will check for a getAge() method first, then fall back on the…
Methods that actually do something should be verbs, but if it's just reading a property it should look like it's just reading a property. And having all the methods on a class start with get* is a pain for autocompletion.
Hmm. I guess you're right. I dislike Groovy in other areas so it's not a path I've gone deep down.
Especially for private APIs i Java I have actually tended to default to public final members, without verbs.
Re: Java 9 features announced
#89Still no solution for the GC fragmentation and pauses? Arbitrarily large heaps and data structures? They are going to improve lock performance, but do nothing to help people avoid locking like lightweight threads. Not waking up a thread and not locking is faster... It's weird how so many software projects completely lose sight of the fundamentals. I know I am biased due to how I use Java. I care very little for synta…
If you want to rid yourself of GC problems, go buy Azul's Zing JVM. It works like magic. (disclosure: I'm a very happy customer of theirs)
Zing does not do you any good if you are selling software. Your income is reduced by the license cost of Zing in addition to the additional sales and deployment friction.
The reality is that you have to build software that works on the Oracle JVM.
Re: Java 9 features announced
#90Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.
I admire Java for the fact that it is significantly more painful to write mutable rather than immutable classes. I love C#, but I do wish that setters weren't so easy to define (and that classes were sealed by default, and that fields were read-only, and that all extant warnings would become errors, etc.).
I agree 100%, but the problem is the culture that has grown up around Java. The whole Bean concept encourages violation of encapsulation. IDEs provide automatic generation of accessors and mutators. Many Java programmers have been trained to expect them. At this point, encouraging good OO practice is shouting against the tide.
That being said, I still make my classes immutable unless there is a damn good reason not to.