Did they mention if spyware will continue to be in the installer?
Was spyware ever bundled with the JDK?
Java 9 features announced
211–220 of 228 posts
Re: Java 9 features announced
#212Earlier quoted context omitted.
There is a JEP for alleviating the problem. http://openjdk.java.net/jeps/8048330
And that JEP basically already exists in Guava https://code.google.com/p/guava-libraries/wiki/ImmutableColl... `ImmutableList.of("a", "b", "c")` is not as concise as e.g. Python, but it's not bad.
Once you statically import the method, it is even more concise.
Re: Java 9 features announced
#213Earlier quoted context omitted.
> Others have noted that in many contexts in C# there is a difference, so clients do need to know. Which is why C# added automatic properties. You get the expandability without breaking clients or having to read/write extra code. public int Foo { get; set; }
Last time I checked (long ago), properties in C# don't work as ref or out parameters. Since C# actually distinguishes between ref and out parameters, it would be pretty easy to extend the language such that properties work whenever fields work, but sadly no one but me seems to care.
See the following example for why that is excluded.
public string Foo { get { return ""; } }
private void DoBar(ref string input) { input = "123"; }
public void Main() { DoBar(ref Foo); }
Re: Java 9 features announced
#214Earlier quoted context omitted.
"the path from idea to standardized feature" Guy Steele was asking for value types in 1998 ( http://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf )
Yeah, but he was also asking for operator overloading.
Well, I don't have a problem with that, but it's not really relevant. The community liked one proposal and disliked the other, but it still took almost two decades to handle the one it liked.
Re: Java 9 features announced
#215Earlier quoted context omitted.
Up until recently, I've enjoyed the builder pattern. It becomes a pain in the ass though when your objects are deeply nested. For example, with protocol buffers you end up doing things like. AlbumCollection collection = user.getPreferences().getFavorites().getAlbums().toBuilder().addAlbum(album).build(); Favorites favorites = user.getPrefernces().getFavorties().toBuilder().setAlbumCollection(collection).build(); Pref…
> Up until recently, I've enjoyed the builder pattern. It becomes a pain in the ass though when your objects are deeply nested. That and good luck adding a new required field in your "constructor", because you just gave up on statically checking the parameters of the "constructor".
Can't say I understand the downvotes on this one. If you add a parameter in a traditional constructor but don't update the site calls, your code won't compile. If you add a builder method, your code will still happily compile, you'll have to wait until runtime to get an exception, if you added a check in the build() method. That's something to think about, just like you give up safety for convenience when you move to a DI framework.
Re: Java 9 features announced
#216Nothing 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.
If there's a getter and a setter for a class field, you can just make it public.
The problem is that in Java at least, you cannot.
At least if it will be ever used by code beyond your control.
Because then you'll never be able to add a getter or setter later without breaking people's code.
Java is frustrating in that regard. As it should be able to deal with automatically invoking getters and setters when needed (it already inlines getters and setters at runtime, this is "just" the reverse), but it's a language decision that it doesn't.
As an additional bonus, this would help reduce the (legendary) verbosity of Java. a.b += c.d is much easier to read than a.setB(a.getB() + c.getD()). And don't get me started on Java's generics or lack of operator overloading...
Re: Java 9 features announced
#217Still 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 such a thing is so staggeringly important, why in the world are you on the jvm? use c++ or something, eh? right tools yadda yadda.
Re: Java 9 features announced
#218Earlier quoted context omitted.
It isn't perfect, but Lombok[1] helps with this. It uses annotations to automatically generate getters and setters. The downside, of course, it yet another dependency and more annotations. [1]: http://projectlombok.org/features/GetterSetter.html
You can setup your build process to "delombok" your sources, so that the dependency would only be compile-time (which is pretty neat). Also, Lombok has @Data http://projectlombok.org/features/Data.html
What's even better is @Value with @Builder :) Immutability is the best.
http://projectlombok.org/features/Value.html http://projectlombok.org/features/experimental/Builder.html
Re: Java 9 features announced
#219Earlier quoted context omitted.
Nothing pollutes java source more than code which REQUIRES setter methods for functionality. If you have classes which require constant mutable access to internal state, your design is probably flawed.
> If you have classes which require constant mutable access to internal state, your design is probably flawed. How do you account for value objects in that statement? Are you saying there should be no such thing?
There's no reason value objects need to be mutable. In fact, they shouldn't be mutable. They're just data. Why would you need to mutate them?
Re: Java 9 features announced
#220Earlier quoted context omitted.
Yeah, but he was also asking for operator overloading.
Well, I don't have a problem with that, but it's not really relevant. The community liked one proposal and disliked the other, but it still took almost two decades to handle the one it liked.
My point was that him simply liking/proposing it doesn't mean much.