91–100 of 228 posts
Nothing 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.
Earlier quoted context omitted.
What particularly is your issue around GC fragmentation? I ask because I had issues previously, but it was "solved" by moving to the G1 GC, I didn't know if you have considered the same.
G1 still fragments and does long compacting stop the world GCs. G1 pause times are still too long. G1 still doesn't have enough throughput. It's bad enough that people who care aren't using G1 yet. They still use CMS and small heaps and are careful to prevent promotion and fragmentation. You basically end up benefiting from GC for short lived allocations, but pay dearly for using Java when managing state the collecto…
Earlier quoted context omitted.
And making your instance variables public doesn't solve that for you?
States(properties) should never be public or it breaks encapsulation.That's why a language that allows a property to be a method under the hood is usefull, because the state is still encapsulated. State changes can have desirable side effects.If you expose an instance variable directly it's harder to encapsulate that. Of course there are exceptions. If you have a class that is meant to be only a parameter bag(in an r…
Don't get me wrong, I'm big on encapsulation and separation of concerns, etc. But you don't need to force "privacy" onto your class's users in order to achieve it.
The worst thing about having everything public (this is python, btw) is that sometimes it pollutes the auto-complete, and hinders discoverability. It's also not immediately obvious what the user should/shouldn't have access in your class.
Earlier 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…
Then it scaled back to a re-org of the rt.jar to make it easy to run on mobile devices (Ironically we are seeing the full circle - Java started out as a Set-top box language, then graduated to an enterprisey kitchen-sink and now wants to come back to a modular approach).
Now they seem to want to do some half-baked OSGI compliant approach. Have they used OSGI on medium/larger projects? There is literally no amount of money you can pay me to tackle something that hairy and complex.
Nothing 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.
First off, it's important to know the difference between value types and objects.
For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that.
Objects encapsulate mutable state, and getFoo() and setFoo() are inappropriate methods to have. They should be things that affect the behavior of the object, not simple setters and getters.
The big issue is that a lot of java was created when we still hadn't figured out how to properly do Object Oriented Programming. But we know now (well - some of us), and there is nothing in Java that prevents you from doing it well.
Did they mention if spyware will continue to be in the installer?
- if continues to be a keyword
- Spyware continues to be included
Publish an official blessed and supported way of daemonizing processes. Yeah sure, you can use Apache commons-daemon and others of it's ilk. And it will work. But it will feel hacked together (at least it does to me).
2. Fix Dependency hell!
Publish a blessed / supported / standard of supporting / managing different classloaders. Java has this great mostly unused mechanism (classloaders) for managing dependency hell. It would be great to have platform (maybe even language) level support to make that easy to do and a standard way of building software.
Earlier quoted context omitted.
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; } and can access like normal: var height = rect.bottom - rect.top; But can later be changed into a computed property without affecting the above callsites, e.g: class Rectangle { num left, top, width, height; num get right => left + width; set right(num value…