Hacker News new | comments | show | ask | jobs | submit login
Java 9 features announced (jaxenter.com)
298 points by xngzng 736 days ago | hide | past | web | 220 comments | favorite



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.


It is addressed by better design.

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.


I disagree. A fundamental, language-level problem with Java is that clients need to know when they are accessing a member var, e.g. obj.foo, vs. calling a method, e.g. obj.foo(). This means that its much safer to always wrap things in a method, because if you ever need to change something (or do things like add logging, delegation, or some other filtering behavior), you can do it behind your method without clients needing to change.

Contrast Java with Ruby or C#. There, the clients don't need to know whether they're accessing a member var or calling a method to get/set a property, NOR SHOULD THEY. The inability to do this in Java fundamentally breaks encapsulation.


> Contrast Java with Ruby or C#. There, the clients don't need to know whether they're accessing a member var or calling a method to get/set a property, NOR SHOULD THEY.

Others have noted that in many contexts in C# there is a difference, so clients do need to know.

As far as Ruby, clients definitely need to know, its just that since public fields can't happen in Ruby, its always method-based access for the normal cases.

Both of these lines are always calling a method on "obj" in Ruby:

  foo = obj.a  # equivalent to foo = obj.a() 
  obj.a = foo  # equivalent to obj.a=(foo)
While these are using instance var (the closest thing to a "field" in Ruby) access:

  foo = obj.instance_variable_get :@a
  obj.instance_variable_set :@a, foo
  foo = obj.instance_eval { @a }
  obj.instance_exec { @a = foo }
There's no common syntax like C#-style properties that unifies field-based and method-based access, so Ruby is sort of the extreme opposite of attempts to have "properties" that make method-based access look the same as field-based access in the same language, even though its method syntax can make method-based access in Ruby look like field-based access in a completely different language.


> 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; }


Which becomes even more useful over a field when you can do:

    public int Foo { get; private 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); }
Typically C# points you towards using a different methodology than ref/out parameters. But I do agree it is annoying when you want to use them.


Python has a solution to this. There are decorators that allow you to access methods as if they are properties:

    class Foo(object):
        def __init__(self, bar):
            self._bar = bar

        @property
        def bar(self):
            return self._bar

        @bar.setter
        def bar(self, value):
            self._bar = value


As does Objective-C, and JavaScript.


You haven't addressed his comment at all. Either you're building an immutable object and fields are the proper choice, or you're building an abstract, stateful, concept in which you should be using methods that may or may not map to fields.


That works alright up until you need to integrate with third party libraries like JSF, Seam, Hibernate, Jaxb, Spring, EL, plenty of other stuff that requires a "javabean"

Sure, you can beat the big ones into working, and there is generally no shortage of libraries in Java. But at some point you are just wasting resource to work around other people code. Java has properties and some libraries use them.

Discussing if you should use them at all is offtopic, the real problem is that java has properties but instead of being a language/compiler supported feature, it is only defined as a "convention" with some half-assed support classes. Seeing how popular properties are, that either needs fixing or deprecation (starting with all the Oracle provided framework that use them)


> It is addressed by better design.

This! A lot of the horrible Java you see around is nothing but an artifact of mindlessly applying patterns to constructs that don't need them.

> a lot of java was created when we still hadn't figured out how to properly do Object Oriented Programming.

Which is quite unforgivable, considering Smalltalk has been around since the early 80's.


My problem is I don't think there's any agreement what Object Oriented Programming is and isn't, so it's pretty hard to "properly do it".

Let's see. OOP generally involves "objects", ie structs or records with visibility controls on fields, sporting "methods," ie functions with a magic/hidden this/self argument. This alone doesn't buy you much, and in fact is quite inflexible when compared to good old ADTs, so let's hope there's more to it.

OOP does not mean "all methods are defined within the class declaration/file" a la Java, plenty of OOPLs allow external method definition. So it doesn't mean "well in OOP I always know the behavior of my class" when you have friend functions etc.

OOP might mean "abstract classes" ie virtual methods. This leads us to inheritance, which is a) not confined to OOP and b) widely criticized. Remember that inheritance != polymorphism, c.f. Visual Basic for instance (at least VB5. Showing my age...). In practice, OOP usually invokes a great-chain-of-being-like hierarchy descending from Object, but again this is not universal.

OOP generally means "polymorphism", but the mechanisms vary widely. OOP's "Classic" inheritance-driven polymorphism is probably the worst way to do it, good for quick code-reuse and that's about it. "Interfaces"/pure virtual classes are a design pattern on top of abstract classes, better expressed as mixins or type-classes.

OOP generally implies strong typing but not always (python). OOP typing is quite clunky, especially in "noun-oriented" Java. You can make an argument that the rise of DI frameworks is in response to having impoverished type systems.

My semi-rant here is because people say things like "do it this way, it's good OOP" without there being any agreement about whether we're discussing polymorphism, inheritance, encapsulation, factoring, normalization, or design patterns that are largely a response to the confusion.

On the other hand we have folks like the clojure crowd bagging on OOP using similarly vague concepts like "OOP means stateful objects/side effects" ...


> This alone doesn't buy you much, and in fact is quite inflexible when compared to good old ADTs, so let's hope there's more to it.

It at least buys you a way of organizing your code that makes it easier to understand not just for yourself, but other programmers who read it in the future. Creating objects and using data types isn't really mutually exclusive, you use both as needed.

> OOP does not mean "all methods are defined within the class declaration/file" a la Java, plenty of OOPLs allow external method definition. So it doesn't mean "well in OOP I always know the behavior of my class" when you have friend functions etc.

This is true. The main benefit of OOP in this regard is to help see the interactions between related groups of functions as organized into objects.

> OOP might mean "abstract classes" ie virtual methods. This leads us to inheritance, which is a) not confined to OOP and b) widely criticized. Remember that inheritance != polymorphism, c.f. Visual Basic for instance (at least VB5. Showing my age...). In practice, OOP usually invokes a great-chain-of-being-like hierarchy descending from Object, but again this is not universal.

Inheritance definitely has downsides and should be considered carefully when used, but it also has valid use cases. As with any language feature, it really is more of a question of is this useful to fix the problem I'm trying to solve? Granted, a lot of programmers (at least from the code I've worked on) seem to see inheritance as a universal hammer to their current problem nail :)

> OOP generally means "polymorphism", but the mechanisms vary widely. OOP's "Classic" inheritance-driven polymorphism is probably the worst way to do it, good for quick code-reuse and that's about it. "Interfaces"/pure virtual classes are a design pattern on top of abstract classes, better expressed as mixins or type-classes.

Whether mixins, type-classes, or a polymorphic inheritance is the right choice really depends on language and problem space. At least with mixins there are definitely circumstances where a mixin could have so many methods that it is essentially a form of multiple inheritance. Again, knowing the right tool for the job and knowing what limitations your development language has is more important than the existence of any one feature or tool.

> OOP generally implies strong typing but not always (python). OOP typing is quite clunky, especially in "noun-oriented" Java. You can make an argument that the rise of DI frameworks is in response to having impoverished type systems.

I'm not sure about DI being the result of impoverished type systems. Generally DI is about insuring that function dependencies are explicitly consumed rather than implicitly existing somewhere as a more global state. DI is more about contract enforcement on functions than anything else.

> My semi-rant here is because people say things like "do it this way, it's good OOP" without there being any agreement about whether we're discussing polymorphism, inheritance, encapsulation, factoring, normalization, or design patterns that are largely a response to the confusion.

This is definitely the crux of it. "Good OOP" is a meaningless phrase for the most part. What exactly is good for a project? Given the amount of tools available in OO languages, many different approaches could be used that would function as good based on your particular problem and developers.


This reminds me of two tweets from Nat Pryce[1][2]:

> Colleagues & I once doubled system's functionality & replaced 750K lines of Java with 50K lines of ... Can you guess the language.

> Of course it was Java!

[1] https://twitter.com/natpryce/status/409034320108867584

[2] https://twitter.com/natpryce/status/409232836945010688


I agree with your design idea, but it fundamentally misses the point of getter auto-properties and that is binary compatibility in the case of future change. That is, if you need to add some functionality to the accessing of the variable. Now I personally don't think this happens much, but it would be nice if the language allowed something that preserved binary compatibility across that change and was not verbose.


I agree and I hate getters, but I am one of those who still hasn't figure out how to do OOP correctly. Do you have an example or maybe some suggested reading? For example, if I have a user object, with name, age, number, how would that work without get/set? I'd love to avoid it, I hate the bloat it creates, and also how frivolous it seems to test get/set.


Here's a tip: instead of changing your objects, you can create a new object with the same values except the ones you want to change.

Another option is to use builders (that are mutable), to build/copy your immutable business (?) objects.


That's what we do at work. Then when work is done, I look at OCaml and repeat the mantra "I'm not going to think about how many lines it takes in Java to do a functional update 'let foo2 = { foo1 with foo_field = "bar" }'".

It is possible to have immutable objects in Java and have the equivalent of functional updates, but it's a hell of a lot of pointless boilerplate. It still beats traditional Java beans, though.


Well, the answer depends on the function, the purpose. I suppose he's saying that you should encapsulate with the object. For example, you have an OrderLine object, you don't `o.setStatus(CANCELLED)`, you `o.cancel()` etc.


That examples makes sense, but what about Strings and other types? I'm not sure you can do the same thing for a User object with name, age etc. I'd love to not have getters/setters but I have yet to see a replacement for all get/set scenarios.


That's a Plain Old Data object and back in the day the Sun Java Coding Conventions recommended public instance variables for classes which "would have been a struct if Java supported it" or something like that.

I suppose it's all about behaviour. If the class is literally just a struct - a box for data, there's no functionality to describe. Choosing public instance variables vs. getter/setter is just a matter of choice at that point.

The latter let you check Preconditions, etc. but that means that you actually have some invariant you intend to preserve (date of birth of the user cannot be in the future, for instance, so your well-formed user has some characteristics). Any members that can take any value their type permits should, in my opinion, just be public. Logically if you perceive that you could have some invariant in the near future, you'd want to have getters/setters but there's no point overdoing it.


The parent would have the `User` type as a value type, with read-only final fields.


Anyone know what the "sjavac" is about? The link just talks about improving it so it can become the new default... but what is better about it? Is it just the new javac?(why not just in-place upgrade javac then?)

(link provides no real details: http://openjdk.java.net/jeps/199)


I was curious myself. I dug up the original proposal to create sjavac, which is here: http://openjdk.java.net/jeps/139


Interesting -- finally bringing multiple-core/process compiling to javac. Although, I must admit, I have yet to work on a project where compile times were a major issue. I guess I'm just in the habit of typing "ant release" and getting some coffee ;)


It's unclear if you are poking fun, but one of the major features of Eclipse (and ejc, by extension) is the "compile on save", so there is no compilation step while working in your IDE (unless, of course, you desired one).

If that is a goal of the sjavac project, then the ability to compile in parallel the different branches of the dependency tree for a set of classes would make for a major upgrade in user experience.


This only works well if we get named parameters, too (and maybe defaults). It is too easy to make mistakes with lots of subsequent constructor arguments of the same type.


We already have that, it's called the Builder pattern.


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();

Preferences preferences = user.getPreferences().toBuilder().setFavorites(favorites).build();

and then you have to work your way up the chain of builders. Such a pain in the ass for something that could be much simpler with getters and setters.


This seems like a perfect example of a pattern applied in the wrong way. The builder pattern is supposed to be used to construct new instances (in other languages named parameters make it pretty redundant). I could perhaps understand allowing people to batch up changes but when you're forced to switch to a builder and back again to make a change to one field you've definitely got a poor design. The example seems particularly egregious because you're also forced to walk the domain where really you should just be able to do:

    user.addFavourite(album);


His example is creating new instances. It just happens to be creating them from existing instances. Basically a clone and change kind of operation.

You are right that normally you'd want the addFavourite method but in his example he is dealing with generated code which has a tendency towards verbosity.

You could add the method if Java allowed extension methods...


If you used the generated builder methods provided by protobufs, would it really be that bad?

  user.getPreferencesBuilder()
      .getFavoritesBuilder()
      .getAlbumsBuilder().addAlbum(album).build()


> 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.


So for every class in Java, we just create a corresponding builder class, because we lack certain features in the language?

This is not a solution, this is a workaround.


> 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.

Bollocks, there were already plenty of OO languages when Java appeared on the block.


Sure, but more radicial OO languages like Smalltalk were full of getters/setters too (e.g. in Smalltalk all member variables are private, so getters/setters are the only way to access those) so it makes sense to think that this was just the way to go.


Eiffel introduced properties in 1985.

The famous CLOS book was written in 1988, which makes use of slots instead.

I am at work now, otherwise I could provide more information.


Then don't use getters and setters... A lot of complaints people have about Java seem to be about the way in which they choose to write Java.

My somewhat unorthodox rules for writing Java:

1. Don't use private. No reason to restrict yourself or others, and do extra typing. Friendly is a perfectly good default.

2. Don't use reflection. Reflection is only useful for making frameworks. Frameworks don't reduce the complexity of the problem you're trying to solve. Don't use them.

3. Don't use getters/setters. Sometimes they make sense for updating a cached value, or using a different underlying representation, but in general it's unnecessary clutter. If you still want them (e.g., for code style reasons), just generate them.

4. Don't use other people's code (tongue-in-cheek). If you use third-party libraries, consider wrapping them in your own interfaces as needed. This makes it easy to change the implementation and perform tests. It's not much effort, since you'll rarely use more than a limited subset of the functionality offered by the library. If you need a large subset, then just use the library directly.

5. Use final. Immutability makes programs simpler, more efficient, and inherently thread-safe.

6. Consider writing bean classes as follows. It's simple, efficient, thread-safe, and has a clean syntax (item.name):

    public class Item {
        public final int id;
        public final String name;

        public Item(int id, String name) {
            this.id = id;
            this.name = name;
        }
    }
7. Use an IDE, refactor, find references, generate code. It's easy to changes names and styles later, so just focus on important things like performance and reliabiltiy.

8. Keep improving the way you write your code, don't listen to the crowd.


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?


Well, in the strictest since, I suppose a "value object" is technically one that is immutable by definition. So, to your point, I should clarify that here I'm instead speaking more loosely of an object that is chiefly comprised of data elements vs. behaviors.

So, a common use case might be loading data from a DB, changing several fields, then writing updates back to the DB.


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)  => left = value - width;
      num get bottom            => top + height;
          set bottom(num value) => top = value - height;
    }
C# is a close 2nd, but it's not binary (or reflection) compatible to change from a field to a property for call-sites (i.e. it's only source-compatible).


Your comment about changing a field to a property being a breaking change in C# is correct, but in practice, C# programmers tend to use auto properties (e.g. public int Left { get; private set; }) rather than public fields. These are fully fledged properties, but the getters and setters are implemented by the compiler (and back directly onto a compiler-generated field). Because they are properties, they can then be changed to computed properties (or e.g. validation added to setters) without breaking binary or reflection compatibility.


Why does it matter if it's binary compatible? How does that affect the programmer? I guess I don't understand the difference/significance between binary and source compatibility?

I'm surprised to hear that it's not reflection compatible. As a Java programmer, I assumed that was the main point of C# properties: Create a property now because there's no logic needed, but if you need logic in the future you can change the code and nobody outside needs to be aware of the change.


Binary compatibility is important when accessing properties of a type defined in another Assembly, i.e. if an Assembly was updated where a Field was changed to a Property it would break access from dependent Assemblies.

In .NET Reflection, Fields and Properties have distinct API's, i.e. fields can be accessed with `type.GetFields()` and properties with `type.GetProperties()`. The API's are basically wrappers around how they work, i.e. Fields let you get/set an instance's field value whereas with Properties you're instead invoking the properties getter/setter method accessors.


> As a Java programmer, I assumed that was the main point of C# properties: Create a property now because there's no logic needed, but if you need logic in the future you can change the code and nobody outside needs to be aware of the change.

That's the point, but its not directed at reflection, and reflection goes around behind the scenes of the superficial access-notation compatibility. Which does make properties a badly leaky abstraction, which is problematic since their main reason for existing is to plug a leak in the abstraction provided by the method/field distinction.


Another important aspect of properties in C# is that they are a target for metadata (i.e. Attributes). This is something that's frustratingly broken with the method getter/setter approach. And while you can fix it by convention (e.g. a priority list for lookup on the getter, then setter, if those exist), it ends up being inconsistent and unnecessarily painful.

Consistency of access in Java is also really problematic for the same reason. Which pair of getter/setter methods represents a reified property? This is often done by naming convention, that's usually, but not always consistent (getFoo/setFoo is common, but there's also isFoo/setFoo, isFoo/setIsFoo, foo()/foo(value), etc.). Worse (and this is something both Android's flavor of Java SDK and Objective-C have fallen prey to), not all properties are written symmetrically (e.g. getText() and the various setText() methods on an EditText in Android, although there are some where all of the setters are subclasses of the only getter -- even worse).


Ruby is quite similar.

attr_accessor :left, :top, :width, :height, :right, :bottom

And you can change these to computed properties (regular methods) later without affecting the callsites


In C#, these aren't 100% source-compatible either. For example, you can't pass properties using ref or out parameters.


Amusingly, your Dart solution is exactly what Groovy does, which is where this whole thread started.


afaik scalas properties are as good as in case of dart. Also, operations like + are also normal methods on numbers.


The purpose of a getter or setter is to abstract the implementation out from the usage. Computed properties (e.g. C#'s ability to replace a concrete property with a virtual property without breaking any code) do this without requiring mindless implementation (boilerplate code) for the common case (a property that is exactly what it seems to be).

As an added bonus, you don't need to write foo.getBar(), you can just write foo.bar and it Just Works, whether foo.bar is a concrete implementation or a computed property.

Look at this blog post for example:

http://java.dzone.com/articles/java-properties-without

The sad thing is the request here is for something more ugly than what is really wanted (this is just automatic getter/setter implementation -- computed properties are better both for developers and consumers of their output.


The problem is that you cant add computed accessor methods to java without breaking code backwards compatibility. This is because a public fields and a public methods have different inheritance semantics - public field access does not trigger polymorphic resolution. Hence auto replacing it with a access method would break any code that relies on the static resolution of the public field (i.e. resolution by referencing type). To fair there probably isnt much code out there that would fall foul of this since there isnt any good reason to write code that relies on public field "hiding" by subclasses, but it would be technically non backwards compatible.


In python the default is that things that look like attributes/properties REALLY are direct access. If you later need to shim them out into a function you use the @property decorator (and foo.setter if you need read/write)

    class Blah(object):
      foo = 2 # A normal property. Direct access

      @property
      def bar(self):
        return self.some_lookup_method()
    
      @bar.setter
      def bar(self, value):
        self.set_the_bar(value)


Thanks for mentioning this. I've found the Python approach works really well in practice.


What's wrong with getters and setters?

It's just redundant code. Most of the time developers don't actually need to override the basic get/set operation on a variable. Yet you have to write the get/set methods over and over.

How do other languages address this issue?

Scala does a good job. You don't need to actually write a get/set method. But if you wanted to modify getFoo() you would simply implement the method with your custom getter


The problem with getters and setters is that the code for them is nearly identical, yet they have to be written in nearly every single class:

  // Sorry if there are any mistakes, I have not
  // written any Java code for quite some time.
  public class Point
  {
    private int x;
    private int y;
    .
    .
    public int getX()
    {
      return x;
    }

    public int getY()
    {
      return y;
    }

    public void setX(int newX)
    {
      x = newX;
    }

    public void setY(int newY)
    {
      y = newY;
    }
  }
Look at how long the class definition is for something so basic!

In Common Lisp there are two ways to define classes/structures, defstruct and defclass. Defstruct[0] automatically automatically defines everything for you:

  (defstruct point  x y)
will define the procedures make-point, point-x, point-y, (setf point-x), and (setf point-y). The cool thing is that they are all procedures. It easily change the class definition without changing the code that uses it. There are also some additional options for defstruct to specify default values, how to print the structure, as well as what prefix to use (the default is the name of the structure, 'point' in this case).

Defclass[1], while much more verbose than defstruct, is much more powerful:

  (defclass point ()
    (x :writer set-x :initarg :x)
    (y :reader get-y :initarg :y)
    (z :accessor z))
will define procedures, set-x, get-y, z, and (setf z). Set-x and (setf z) are the setters, while get-x and z are the getters. To construct a point that is defined this way, one has to use the procedure make-instance which will take keyword parameters[2] :x and :y, for x and y respectively.

  [0] http://www.lispworks.com/documentation/lw445/CLHS/Body/m_defstr.htm
  [1] http://clhs.lisp.se/Body/m_defcla.htm
  [2] http://www.gigamonkeys.com/book/functions.html


For c# just:

public int Age{get;set;}

no need to declare private variable, get or set methods.


And you can replace it with a virtual property in the future (changing the underlying implementation) without breaking anything. And user code ends up simpler and more readable too:

foo.baz += foo.bar;

vs.

foo.setBaz( foo.getBaz() + foo.getBar() );


That example reminds me of this recent post on The Old New Thing: http://blogs.msdn.com/b/oldnewthing/archive/2014/08/14/10549...

Interesting behavior.


Of course, setters don't protect you from this either.


C# introduces the concepts of fields and properties. I dont remember which is which but I think properties are in fact getters and setters,without the verbose "object.getProperty()" syntax , you just write "object.property" and it's call a getter function or a setter function.

Basically you keep states encapsulated without have to manually write methods,you just write methods when you need then.

Java verbosity on that matter is totally unecessary.

Granted when one use an IDE refactoring features can help,but still... A great strenght of the Java language is its stability.But stability doesnt mean a language needs to be that verbose.


> C# introduces the concepts of fields and properties.

This goes back to at least Eiffel (1985).


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
  end


It's worth noting that in Ruby the difference between attr_reader and attr_writer is not the same as read only and write only. You can write to something set with attr_reader. All attr_writer does is allow complete reassignment of that particular instance variable.

This is pretty trivial so bear with me... If you have something that looks like this...

    class Person
      attr_reader :children

      def initialize
        @children = []
      end
    end
You can then do this...

    x = Person.new
    x << "Bobby"
You will have then altered the value of @children without completely reassigning it.


Kotlin is pretty nice for that. Also, project lombok is nice for Java code generation. I wish it became more "standard"


+1

It is pretty astonishing they haven't done something about that. It doesn't seem like it should be a very hard language feature.


This doesn't solve the problem entirely or address your valid complaint, but it does do a good job of hiding it for now: http://projectlombok.org/features/GetterSetter.html


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. cantReadMe would be an invalid right hand variable, and a similar check for the verifier. Any other public field behaves as normal.


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 could be done with a smarter compiler (easy way), or a new JVM bytecode (probably 'better' but not easy).


This is solved in a more general way in Java 8 via monadic optionals. The basic idea is to wrap your nullable objects in an Optional<T>, which then both forces you to deal with the possibility of the value being absent and gives you good tools for doing so. Your example, with Optional, looks like this:

T obj = ...;

Optional.of(obj).map(T::some).map(U::other).map(V::methods).getOrElse(null);

Not quite as clean syntactically, but much more general, as the same operations can be applied to other monadic objects.


The sugar your parent proposed would still be nice and has precedent in other languages with option types. Swift has something very similar[0], and Rust is debating it[1]. Haskell's do-notation and Scala's for-comprehension are other solutions to the same general problem of conveniently using option types.

It may be a good thing to only support that sort of convenience for option types and not for nulls, in order to further encourage their use. Although using nullable types is already pretty darn convenient!

[0]: https://developer.apple.com/library/prerelease/ios/documenta... [1]: https://github.com/rust-lang/rfcs/pull/204


This is kind of a pedantic distinction, but the behavior you've described is actually Functor behavior; I think Monads allow for Functor-like behavior as part of their definition (not sure, I'm neither a category theorist nor an experienced Haskeller), but their use is something a little bit different. Monads allow you to do two things:

1) Lift regular values into monadic ones in a generic way. Let's say that we have two Monads - Optional and List. There should be a way such that we can take a non-monadic value (the part that will go inside) and turn it into a Monad. So, assuming Monad is a Java-like abstract class, the following should be possible:

    Monad<String> m1 = Optional.lift("hello");
    Monad<String> m2 = List.lift("hello");
2) Flat-map, typically called bind in this context. Given a monad and a function that takes a value and returns a monad, we should have some way of combining the resulting monads if we were to map this function over the first monad's internal value. So for instance, given an optional string, and a function that takes a string and returns an optional int, we should have some way of combining the Optional<Optional<Integer>> into just an Optional<Integer>. So, in the following contrived example...

  // Returns a UTF8 string value from a database, may fail
  public Optional<String> getUtf8Name() { ... }

  // Returns the length of a String if it contains exclusively ascii characters
  public Optional<Integer> getAsciiLength(String str) { ... }
... you can compare the differences between it and the Functor's map:

  Optional<Integer> asciiLength = getUtf8Name().bind(getAsciiLength);
  Optional<Integer> otherAsciiLength = getUtf8Name().map(getAsciiLength).getOrElse(Optional.absent());
As it turns out, you can implement the Functor's map method in a generic way using lift and bind.

  public abstract class Monad<A> implements Functor<A> {

    /**
     * Implements Functor's map method.
     */
    @Override
    public <B> Monad<B> map(Function<A, B> fn) {
      return this.bind( innerValue -> this.lift(fn.apply(innerValue)) );
    }

  }


    Monad<String> m1 = Optional.lift("hello");
    Monad<String> m2 = List.lift("hello");

Shouldn't that be

    Option<String> m1 = Optional.lift("hello");
    List<String> m2 = List.lift("hello"); 
?


This is called null-value propagation. It's coming to C# (6) this year.


Groovy does this, although frustratingly not with array accesses last I checked.


I requested array accesses on the Groovy mailing list 7 years ago, see http://groovy.329449.n5.nabble.com/Indexed-properties-td3396...

I never did fill out a GEP but you could try your luck by subbing one, see http://docs.codehaus.org/display/GroovyJSR/Groovy+Enhancemen...


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 "age" field. I quite like that methods have verb-names, but I don't want to verb my fields.


Yes, sort of like final... but different.

I was thinking this is more for _public_ variables... so like internally, a class could modify it's own readable fields, but code external could read only.


I do like how C# handled this, FWIW.

  public int MyProperty{
    get; //public
    private set; //private-only setter
  }
but obviously there are a lot of ways to skin that cat.


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.


> Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address.

We ran out of patience and switched to Scala. Never been happier :)


Groovy replaces package-scoped variables with private vars and autogen'd getter/setters. So much nicer.


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.


In Java culture immutable generally means private final member with only a getter and no setter. I would argue that this is good OO design as the purpose of OO design is to protect your interface from future design changes. If you need to change your accessor, you already have one. If the member needs to be mutable at a later date you need only remove the final keyword and potentially add a setter. The interface remains backwards compatible.


I disagree. If you require an accessor to actual internal state, you should rethink your dependencies and reassign some behaviors. Accessors should be rare, mutators almost non-existent.


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 rest API for instance),that's ok,imho.


I work just fine in a language that has no "private" variables or methods. It's not for everyone, and it requires some discipline to not get burned.

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.


[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, whereas it never could be null before. But if it is, then what the rest of the world saw as v should now be some default value. So we can say:

public T get_v() { if (v != null) return v; else return default_T; }

and life goes on for everybody that was using v. But if all we had was a variable that everybody accesses, then all the users have to change. They either have to access the new getter or, worse, they each have to copy the logic to check for null.

This is how the getter encapsulates the inner workings of the class, and why it's a really good thing.

P.S.: How do I specify code formatting on HN?


Indent the code with two or more spaces:

  public T get_v() {
      return v;
  }
See: https://news.ycombinator.com/formatdoc


"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.


Your public facing methods/accessors are a sort of contract between a class, and whatever uses it.

The contract basically says: "I will behave as you expect me to and as we agreed but only as long as you only interact with me in the predetermined(designed) ways that I allow you to"


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.


Not exactly comparable (because everything is immutable), but Haskell has sort of a cool approach to setting and getting fields.

Let's say you have

    data Point = Point {x :: Int, y :: Int}
If you have a Point object called "point", you can get x by doing

    x_coord = x point
If you want to create a new Point with x set to 5, you can do

    point' = point {x = 5}


F# has a similar concept via the with statement. To use your example:

    type point = { x: int; y:int}
    let z = {x = 5; y = 10} 
    let y = {z with x = 17}


Interesting, Scala equivalent is:

    case class Point(x: Int, y: Int)
    val p1 = Point(5,10)
    val p2 = p1.copy(x=17)
How does F# handle nested data types? In Scala if you want to copy a case class of a case class (of a case class ...) it can get boilerplate-y as you have to copy outside-in through each property a la:

    x.copy(acase.copy(bcase.copy(cprop=1)))


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


I'd use immutable value classes with AutoValue: https://github.com/google/auto/tree/master/value . It's developed by the googlers behind the awesome Guava library.


You can always do something like this http://benjiweber.co.uk/blog/2014/03/20/c-style-properties-i...

Although I prefer not using getters & setters at all.


that's not really because of the language, but mostly because of frameworks and patterns available for the language (Java Beans, reflection-oriented frameworks and so on). Often, getters and setters are more an habit than a need. A while ago I wrote against that: http://www.refactoringideas.com/getters-and-setters-gone-wro...


You can always add Project Lombok as a dependency and the issue is gone. I know it is a third-party library but there's nothing bad about that.


Why not just declaring the fields public and access them directly? Is there anything I am missing?


What if you only want a getter? The `final` keyword is too restrictive.

Also, it breaks encapsulation, because your internal storage should be changeable without ruining your external surface area.


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...


burn your getters


The lack of an official JSON API has been a huge sore point for quite some time and has spawned dozens of libraries re-implementing the same thing over and over (GSON, Jackson, and even my own nanojson). I do hope that we avoid the DocumentBuilderFactory mistakes of XML and just end up with One True JSON implementation this time.


Are you sure that's true? As you say, look at the "standard" API for XML parsing: a complete disaster. Dates, similar. Logging was slightly less disastrous because they took so much from Log4j, but they still made it unwieldy enough that the log4j guys ended up writing an API on top of that which everyone uses.

Now, props where props are due: Sun crushed the collections APIs compared to other languages at the time. And that more than makes up for everything else.

But I see little evidence that standardizing JSON parsing will improve things.


I'll counter that with saying that j.u.l is not actually that bad, IMO, although I might be the only one in the world that thinks that. I always just choose j.u.l in my projects because it works well-enough. I just shim anything with slf4j if it speaks log4j or commons-logging (shudder).

Perhaps Sun should have just adopted slf4j and a simple console-logging stub, but I don't think j.u.l is really any worse than the alternatives -- only a different implementation.

Now date APIs: those do suck, but I think the new Date JSR will finally get things to a place where we can use Java Dates rather than Joda.


XML parsers are so complicated because XML and the DOM are more complicated. A json parser can be simpler.


I really don't see any benefit of introducing a JSON API into the JDK. Jackson works great already. Are they really going to make something that much better?


There is an official JSON API: https://jcp.org/en/jsr/detail?id=353

But it is unclear how many of the existing implementations conform to it, and it definitely doesn't work toward your misguided One True JSON Implementation goal.


That's a Java EE API. I've been working with the Java SE and Java EE folks to make sure that a new version of that will sit on top of the core JDK 9 one.


How did you arrive at the conclusion that a set of interfaces is a JavaEE API?

Above and beyond the fact that in section 2.2 of the JSR it plainly states: "This JSR is targeted for Java SE 6 or higher and Java EE 7 or higher platforms."


We helped test out the RI and TCK - it was in the end up built for Java EE in mind (that's not to say someone couldn't provide a stripped down version that could work for SE - but I don't think anyone has or will).


Im not sure i would call having multiple options a huge sore point. Chances are many of these options would still exist even if there was an official API.

FYI: Just looked at your nanojson, looks good. Might have to try it out, i like the fluent api for object creation.


>>Im not sure i would call having multiple options a huge sore point

It becomes one when serializing and de-serializing across a distributed application like xerces class path issues in different jvm implementations.Not a common sore point though!

>> Chances are many of these options would still exist even if there was an official API.

True and agreed.


Gson worked perfectly for me a few years ago. Why did you end up implementing your own?


Amen to that, brother. JSON is a huge pain point for Java. No wonder so many Java folks keep defending XML--at least it's malleable in their home language.


My Wishlist: 1. Fix Daemonization!

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.


Fix Daemonization

This is fixed by process supervision software such as systemd -- no need to implement it yourself. Just leave your application running in the foreground.

http://0pointer.de/public/systemd-man/daemon.html


For 2, what's required is a module system. OSGi provides such a mechanism but it's not "official". Each OSGi bundle has its own classloader.

Java 8 was supposed to provide modules but they were scrapped so in the meantime, OSGi is the only option.


Project Jigsaw (modularising Java itself and introducing a module system) will be a serious attempt at solving a part of this problem but may not land in its entirety for Java 9 (modularising the source code landed today on trunk). OSGi claims to solve the application layer part, but many developers I speak to have mixed results, primarily due tooling support etc.


I thought one of the things promised in Java 9 was to finally fix the primitive mess, including all of the boxing and pointer chasing. Yet I can't find that here.

I also thought that type reification was being researched.

Does anyone know if either of these is still a thing?


Yes, they are both being worked on. They're just not sure they'll be ready in time for 9.


The project to watch here is project Valhalla - valhalla-dev AT openjdk DOT java DOT net. Indeed the full solution of value types will not land until Java 10, but Java 9 will hopefully contain the very useful Collection of primitives enhancement (you can currently only have Collections of Objects, primitives are auto boxed into their Object equivalents at much greater overhead).


This is a huge let-down after Java 8, but I guess that was inevitable. Lambdas are a tough act to follow and are probably my favorite addition to the JDK ever.


Did they mention if spyware will continue to be in the installer?


Why would they mention features that are still included?

- if continues to be a keyword

- Spyware continues to be included


That has little to do with the language, though.


Was spyware ever bundled with the JDK?


List of proposed JEPs so far.

http://openjdk.java.net/jeps/8048330


I see that their "Process API updates" still don't make it possible to get a NIO Pipe object for redirected stdin, stdout or stderr when ProcessBuilder.Redirect.PIPE is used. Maybe they'll fix that some day...


Sooo this means it will be what 5 years if never before Android starts to adopt some of these new Java 9 features? Kitkat introduced some Java 7 features, but I don't think anything in 8 is near to making it in.


I'm deeply missing hot swapping. I believed it could be included in java 9 but i think we have to wait...


ZeroTurnaround have a payware product (that's highly acclaimed in this space) called JRebel. It swaps out bytecode directly as opposed to using Java's (somewhat broken) classloader mechanism.


Are you aware of DCEVM? https://github.com/DCEVM/DCEVM#readme


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.


It can take up to 5 minutes to restart my application.


So run multiple instances of the app, and put some kind of load balancer / proxy in front of the instances.

Unfortunately, this will require externalization of state data, but if you can't be down for 5 minutes, that's what you need to do.

You probably only need one large server running the instances, rather than a cluster. Java apps don't seem to do well -- longer GC pauses -- when they have over 2 GB of memory, anyway, so run multiple instances of "small" apps on a server with say 12 cores. A single server with a large pool of RAM shared between a large number of cores can do pretty amazing things with a collection of "small" programs on it (DB, web service apps, message queue server, web servers)

Of course, I'm assuming said server isn't Windows...


I don't think he meant hotswapping in productive environments but during development. Load balancing doesn't help here.

The webapp I'm working on currently has a startup time of 50s on my macbook. If I restart the webapp 100 times a day, thats a total waiting time of 30+ minutes. Our team is 6 developers, so we loose 3h per day.

Real hotswapping may be extremely complex but IMO it would be absolutely worth the effort.


Ah, gotcha. It's funny, I used to do very frequent tests like that when I worked in C (particularly the first few years in the language), but tend to do much fewer test runs in Java. Fewer fatalities, but longer build/start times, I guess.


Can't you just break things up to see them in action? If not, you should question your architecture.


of course you can restart your app, but it's not sufficient answer to the problem. Apparently long time ago hot swapping was scheduled around Java 9, but they didn't progress with it since then. See JEP-159 for more details: http://openjdk.java.net/jeps/159


What is hot swapping?


Replacing code while it's running. Currently this is possible but quite limited in the official JDK, you can only replace the contents of method bodies.

Edit: Demo of it in action here, notch is rapidly developing a game in Eclipse by changing the code while it's running: https://www.youtube.com/watch?v=rhN35bGvM8c


notch is rapidly developing a game in Eclipse

He's modifying the Swing object tree from the main thread! Don't do that, Swing isn't thread safe ;-)

https://www.youtube.com/watch?v=rhN35bGvM8c#t=1454

http://docs.oracle.com/javase/7/docs/api/javax/swing/package...


There's always JRebel!



Oh, damn! I just started using jrebel.. (I know I asked what hotswapping was but I was curious if the OP meant hotswapping in the same way as jrebel or something else)

edit: Wait, that is liverebel, not jrebel


Ah, sorry! I though liverebel was the new name.


Isn't this basically what Spring is for? I get that it's not included in the language itself, but that seems more like a feature that should be provided by a framework rather than the language itself...


No, that's not part of Spring. It would be implemented by a container. OSGi was a sort of failed attempt at standardizing it. Right now you have to pay for something like jrebel (worth it, IMO) to get hot swapping.



Still no hash literal :-(


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.


Not really a place for it in a strongly typed language like Java :/ I could maybe see language support for creating Maps or something, but in Java you're supposed to create your own Objects and let the compiler check your code for errors.


I assume you meant statically typed, rather than strongly typed.

Swift has this: var airports: [String: String] = ["TYO": "Tokyo", "DUB": "Dublin"]


:D Thanks for the correction

I like the swift example... Map<String, String> map = new HashMap<>(){"TYO": "Tokyo", "DUB": "Dublin"};


A hash literal syntax in a strong, statically typed language works just fine; conceptually, they aren't much different in that regard than array literals, which Java already has.


Fix the Modularity business properly! Please simplify and make a standard system that most people can get behind. While Jigsaw started out ambitiously, I attended some of the initial meetings and the scope was....awesome.

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.


So the whole JDK will be based on modules that might or not be included in potentially different profiles (for example a Java ME equivalent?), or has that been dropped ?

I remember seeing something about that in a presentation a few years ago.

I think it's a good decision from Oracle to not include much more (compared to Jigsaw) in Java 9, given the huge scope of the Jigsaw change, which might probably be the change with the largest internal code impact so far ever done in Java, or at least one of the largest (if the plan to refactor the JDK for modules goes further).


A lightweight JSON API? Hopefully they don't consider the XML jdk monstrosity lightweight. Java SDKs haven't produced superior technology to OSS libraries for a decade, so I expect Jackson to still be better.

The http client was so basic in the JDK it has spawned TWO apache HttpClients projects.

Jigsaw... fool me three times? Wasn't this supposed to be in JDK7?


This looks more like a minor update, and not as radical as Java 8.


> improved support for multi-gigabyte heaps

I've heard this thrown around before, but what this actually mean? Is it just some optimizations to the garbage collector?


Work on G1 GC. Now it can deal better with humongous regions (can collect them in mixed cycles, not just at the end of a slow and expensive full marking cycle), had a lot of fine tuning work done, and all in all, it seems to me that Oracle allocated/allowed/encouraged JVM GC developers to participate on the hotspot mailing list. ( http://mail.openjdk.java.net/pipermail/hotspot-gc-use/ )

And see also: https://bugs.openjdk.java.net/issues/?jql=project%20in%20(JD...


Looks like they're actually listening to developers


Is it possible to have native JSON parsing with JNI bindings to make parsing faster, or will the overhead cancel out any boost in performance?


Why wouldn't you be able to write JSON parsing fast in Java natively? Even if you can't, it's precisely the kind of thing that would pay a large JNI penalty.


Boxing and unboxing characters is a big part of performance penalties, especially when dealing with Unicode.


I'd worry about correctness more than performance. With a parser that's often used on remote documents, you really don't want there to be security flaws.


yawn..

Maybe around 2020 we'll get some useful stuff like string interpolation, long strings, default param values, and multiple return values!


I had heard a rumor that there ware talks of user defined value types. Does anyone know if there is any hope for this?


It seems that it is almost in prototyping stage, the usual suspects have already written a sketch of a future proposal:

http://cr.openjdk.java.net/~jrose/values/values.html


Awesome! Thanks. I don't know much about the path from idea to standardized feature with the JVM. Is there hope for it in Java 9 or is this much farther out in the future? Probably first and more importantly, what is the chance for this even ever happening?


Likely delivery timeframe for value types in Java 10. Definitely not Java 9. Source - many conversations with Brian Goetz et al.


"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.


My point was that him simply liking/proposing it doesn't mean much.


What JVM instructions would you use to implement user-defined value types?


I'm not sure you'd need to introduce new instructions.

"user-defined value types", i.e. structs, can already be done today by (ab)using the Flyweight pattern and storing data (possibly off-heap with RAII rather than GC semantics) in some byte[].

All a JDK-supplied implementation would really need to do is (1) automate/hide all the painful work necessary to set this up and (2) provide syntactic sugar in the form of operators that can directly manipulate members of these types (+fast implicitly inlined implementations of them, specialized on the member types).


Does anyone know if project jigsaw will improve the startup time for JVM languages?


It will depend on howe small a profile the JVM language can run on. In theory you could run some JVM languages on the compact profile resulting in a n overall faster startup time.


Just get a native compiler, plenty to choose from.


No language features?


There maybe some small ones, but the (and I think correct) decision was made to focus on the JVM for Java 9. Java 8 bought in enough language features to keep Joe/Jane Java developers happy (most bleeding edge folks moved to Scala or other languages).


a new json api to be released 2016. Hopefully by that time json is still relevant. I know most likely it will but at the pace of change that tech has, im not betting.

is there any contender to json at the moment?


JSON likely will be around as it is extremely simple (technologically) and extremely light (in terms of network usage). In order for a JSON killer to appear it would inherently have to be superior to JSON, and it is very hard as for what JSON is used for it does very well indeed.

JSON somewhat replaced XML, but that made sense since XML is more complex and a lot more expensive (both in terms of network AND processing).

I can see people building more complex obstractions on top of JSON in the next for years (essentially re-building what XML was, but in JSON) however I cannot really see JSON being entirely dethroned for what it is good at.


We're talking Java here. Java is used by enterprises all over the world for mission-critical code. I have clients who are just now making the move to Java 7; so of course JSON will continue to be relevant for the next 10 years or more. It may fall out of favor among the Julia/Erlang/Scala crowd, but JSON is here to stay for enterprises.

As far as contenders to JSON, I can't really think of any besides XML. The biggest benefit to JSON is its simplicity; which becomes a huge drawback in a strongly typed language like Java.


I don't think we'll be looking at a contender to JSON for quite some time (at least, for frontend/web consumable APIs). Being able to use it in JS directly pretty much guarantees its stability.

For other message protocols it's a different story. Each system has its own needs, so it's much harder to say.


YAML (http://www.yaml.org) comes to mind, though I think JSON is a much bigger improvement over XML than YAML is over JSON.


Yaml is more for humans to read than json is, and doesn't have native functions in any browser.


I'd much rather have this pace of innovation than trying to keep up with whatever the Ruby community decides to use this week.


As a side note, I realized java 7's Objects class was copied from google's Objects library class, but with name changes. They could have copied the apache API, but nope. This is fine by itself, but these are the same jerkoffs claiming some sort of copyright over the java JDK API. Quite disgusting.


Still 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 syntax and syntactic sugar. Reading and typing speed is not a problem for me. Get stuff done on time is and working around these shortcomings eats up my time.


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.


ah, understood. have you been tracking shenandoah? http://openjdk.java.net/jeps/189


I have heard of it but haven't read up. I think it's great that someone is stepping up to address the issue. Interesting that both the authors listed in the JEP work for Red Hat.


Shenandoah is unlikely to see the light of production release until Java 10. I ran a very early piece on this - http://www.jclarity.com/2014/03/12/shenandoah-experiment-1-w... - really glad to see more experiments in this space. I'll add that G1 from Java 8u5 onwards is pretty darn good out of the box.


If Zing performs as well as you say, why have neither Google nor Oracle purchased it? I imagine that even Microsoft would be interested because they could try adapting it to .NET.


It seems that they published a description of how their algorithm works: http://www.azulsystems.com/sites/default/files/images/c4_pap... My cursory read of the paper suggests that it increases memory requirements by a factor of 100 over the working set and if it cannot get that much memory, the garbage collection will run slower than a standard garbage collector.


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 collector can't handle.

I have not closely reviewed this benchmark but this was one person's experience http://blog.mgm-tp.com/2013/12/benchmarking-g1-and-other-jav...


I'd be cautious of a 2013 report. G1 has had significant work put into it over the past year and is much improved in its latest incarnations. We've seen best results with Java 8u5+ (Disclaimer: I run a company that sells a GC analysis tool).


We had to switch from CMS to G1 when moving to JDK8 for reasons yet unknown, other than CMS used considerably more than CPU it had in JDK7. Fortunately, it's not a service that can't tolerate 500ms pauses here and there.


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: