• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Java 7 Auto Resource Collection Syntax

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
They say it'll be like this:


That is unnecessary complication.
Would it be better like this:


Very simple. You can also propose something that is even better, but not like the Java 7.

Another example would be:





 
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That is also a solution. It is just another syntax for the same functionality. One problem in your case is that you don't know when to close the resources. It could be done when the variable goes out of scope but that could take for ever.
 
N Nan
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Wouter Oet wrote:That is also a solution. It is just another syntax for the same functionality. One problem in your case is that you don't know when to close the resources. It could be done when the variable goes out of scope but that could take for ever.



The current solution in JDK 7 is when the variable is out of scope (out of that try block). What's difference with this? It's the syntax that is difference. Implementation is just try, finally with code to close a list of resource that has a @autoManage marked. In term of resource cleanup, not much difference than before. Any pointer/handle enter the scope that has the appropriate interface will be closed when the code goes out of the scope.

Why the syntax is important? The proposed syntax is really ugly. It still suffers from the problem of "all auto collect resources must be declared first in the dedicated scope". My proposal is seamless, not really changed much if any from the current Java syntax. That restriction above is just plan dumb to fix one problem, and add another one. This is similar to the NOT-POJO issue with J2EE. They added restriction that is not really needed due to their hacked up solution. Business logic should flow normally. Resource maybe allocated inside if/else. Those business if/else should not suddenly have to be moved to another block on top.
With their proposal, the "try" block must also be there, while my proposal doesn't need one. Code already is inside one block or another currently.

my class is actually just 1 line:

var = @autoManage <statement>;

Business logic would flow just normally:



As you can see, no break in business logic. The code is nice, short and clean.


 
Wouter Oet
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

N Nan wrote:The proposed syntax is really ugly.

Well that is your opinion. I find it quite clear and intuitive.

In your suggestion could you explain when the resources will be closed this the following situation:
 
N Nan
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Wouter Oet wrote:

N Nan wrote:The proposed syntax is really ugly.

Well that is your opinion. I find it quite clear and intuitive.

In your suggestion could you explain when the resources will be closed this the following situation:



It's not opinion in this case. You can use scientific method to find out if more lines of code is needed, if more syntactic sugar is needed, if more restriction is needed.
As I said above, the implementation is the same, so you shouldn't ask that question. But I'll answer here anyway:

when doSomething exits, that buffer will be closed.

For example:

Reader reader;
public void test() {
reader = @autoManager new BufferedReader(...);
//do something

reader = @autoManager new ...Reader(...);
//do something else.
}

It's not the variable going out of scope here.
Everytime an expression is evaluated into a "resource" that implemented the appropriate interface, and that handle has @autoManage marker, then it get added to an invisible list.
The list is cleaned out in the inserted by compiler try/finally. That's how it's probably currently implemented by JDK 7 anyway, so no difference here other than syntax.
 
Bartender
Posts: 4568
9
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What's officially proposed looks very like the C# using mechanism. Which is dead easy to get used to (speaking as someone who's recently started using C#.NET). I don't see why it's an unnecessary complication. As Wouter says, it makes the lifespan of the resource explicit.
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

You can use scientific method to find out if more lines of code is needed.


That, in my opinion, correlates very poorly with readability. Just look at perl .
 
N Nan
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Matthew Brown wrote:

You can use scientific method to find out if more lines of code is needed.


That, in my opinion, correlates very poorly with readability. Just look at perl .



I think you're mistaken different things here. You start to talk general. The number of lines, and other things I mentioned sure cause readability issue if the get abbreviated. I didn't do anything like that to the code.
Just a tag.

For response to other about scoping. Common, everyone know about Java scope. You get out of scope for variables, it's no longer used. Same concept here, just applied to resource.
For C# reference, that's rather strange. We don't have to borrow C# if we have a better solution.

I took the time explain above why the code is better. People here just ignore it.
If you want to discuss a change, go into detail like I said above. Break them down, add pros and cons to each. Not just: oh, I like it, or oh, not difference to me.
 
Wouter Oet
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

N Nan wrote:It's not opinion in this case. You can use scientific method to find out if more lines of code is needed, if more syntactic sugar is needed, if more restriction is needed.


If it is not an opinion could you direct me to a research that proves that the syntax is ugly? Less lines of code don't necessarily mean that it is more clear to programmers.

N Nan wrote:As I said above, the implementation is the same, so you shouldn't ask that question. But I'll answer here anyway:


Well you didn't said that when I responded. You edited your post 2 minutes after my response. Please don't do that. I makes it much harder to follow the flow of the topic.

Regarding your response about closing the resources.

N Nan wrote:It's not the variable going out of scope here.

Indeed in your case that can't be done. That is one of the things I like about the Java 7 syntax. It forces you to think about the scope of your resources. Probably resulting in a smaller scope and thus reducing resource usage.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

N Nan wrote:I took the time explain above why the code is better. People here just ignore it.



Yes, I think that was an explanation. I didn't read it because I'm not really interested in the subject, but let's say for the sake of argument that it was an explanation.

And then you said

You can use scientific method to find out if more lines of code is needed



But this statement had no foundation at all. Where's your experiment? What's the theory you're testing? You're the one with the "talking general" in this case.
 
N Nan
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:

N Nan wrote:I took the time explain above why the code is better. People here just ignore it.



Yes, I think that was an explanation. I didn't read it because I'm not really interested in the subject, but let's say for the sake of argument that it was an explanation.

And then you said

You can use scientific method to find out if more lines of code is needed



But this statement had no foundation at all. Where's your experiment? What's the theory you're testing? You're the one with the "talking general" in this case.



If you didn't see my example above why it's less verbose, and also less strange to Java language, then please see below.

Old way:

try ( somevar = createResource()) {
//do something here
}

That's minimum of 3 lines of code, if the resource creation wasn't part of the business logic. If it is, it will be twisted to get it right.
Here's my way:

somevar = @autoManage createResource();

One line of code. The scope is the similar to Java and many languages. If it gets out of the block (not shown here), it will be collected.
For my other example, where 1 resource needs to be collected, but the other needs not because it needs to be passed to another function for example, the JDK 7 proposed solution would be twisted to implement.
The else block would be handled outside of the try ().







 
Paul Clapham
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Right. And the scientific method part?
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

N Nan wrote:I think you're mistaken different things here. You start to talk general. The number of lines, and other things I mentioned sure cause readability issue if the get abbreviated. I didn't do anything like that to the code.
Just a tag.


I don't think so. You've just added a tag, that's fine, but you've added a new mechanism. The question is whether that tag expresses that new mechanism in a way that is clear to all readers. Then you appeared to try to use the number of lines as proof that the approach was superior (the "scientific method") - I was just pointing out that it isn't. I think the proposed mechanism expresses the proposed meaning more naturally. But, of course, that's just my opinion.

N Nan wrote:For C# reference, that's rather strange. We don't have to borrow C# if we have a better solution.


I think it's a relevant reference, because it means I've recently started using the syntax that you are objecting to for real development, and I know it works well. I'd probably put it as one of my three favourite features that C# has that Java doesn't yet.

 
N Nan
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Matthew Brown wrote:

N Nan wrote:I think you're mistaken different things here. You start to talk general. The number of lines, and other things I mentioned sure cause readability issue if the get abbreviated. I didn't do anything like that to the code.
Just a tag.


I don't think so. You've just added a tag, that's fine, but you've added a new mechanism. The question is whether that tag expresses that new mechanism in a way that is clear to all readers. Then you appeared to try to use the number of lines as proof that the approach was superior (the "scientific method") - I was just pointing out that it isn't. I think the proposed mechanism expresses the proposed meaning more naturally. But, of course, that's just my opinion.

N Nan wrote:For C# reference, that's rather strange. We don't have to borrow C# if we have a better solution.


I think it's a relevant reference, because it means I've recently started using the syntax that you are objecting to for real development, and I know it works well. I'd probably put it as one of my three favourite features that C# has that Java doesn't yet.



Yes, I can see you start to play the "opinion" game with me. I was looking for some one with an open mind, not trying to prove with absolute. When I mentioned the "scientific method", that is to mean you can look at various factors to see the pros and cons. Absolutely, no one can prove something more ugly than the other. When MS showed the Pet project they implemented with less lines of code, Java camp started to says a lot of things. Nothing absolute, but I see their points.

Same here. Sure, you got a point of "opinion". You also got a good point about you using C#, so you can reference that as an experience.

However, I think we need to look at it from outside of the box here. The word @autoManage maybe changed to something more understandable.
How about @autoCollected? I don't know. The point being that giving two groups of people, randomly selected to pick one versus another, which one would they do? Which one would be easier to manage? Which one would be more productive? Less bug?

How would you write my example code:
block {

if (some business logic condition) {
allocate this resource, use it and close it after
} else {
allocate this resource, use it, and pass it to something else for use later
}

You can say my case is a rare case. The point is to show the resource is part of business logic, and breaking down into pieces into various block of code for the sake of conforming to the language is "FINE" as long as you don't have a choice. If you do, then please change the language.

In term of lines of code, I can see the two pieces are both expressive. Just one of them shorter, hence better.

}
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey, I've got an open mind. I'm just disagreeing with you. The construct expresses two things: the concept and the scope. I think it is clearer to express the concept with the keyword and the scope with the brackets: one idea one representation. This is why I disagree with the statement "shorter, hence better" - I prefer "more natural mapping to the meaning, hence better".

You're right that an empirical study would be the only way to be sure, though.
 
N Nan
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Matthew Brown wrote:The construct expresses two things: the concept and the scope. I think it is clearer to express the concept with the keyword and the scope with the brackets: one idea one representation. This is why I disagree with the statement "shorter, hence better" - I prefer "more natural mapping to the meaning, hence better".

You're right that an empirical study would be the only way to be sure, though.



The concept was to auto clean the resource. This is used many places with resources such as annotation is used for resource injection.
The scope in Java are often in 2 representations. When it's in the (), like a for loop, it's often a short piece of code. Anything longer doesn't look that good. That's why expand the try to have this is more a hack when the business logic has the larger scope.
The 2nd representation that most people see is {}. My way uses that to indicate scope. Anything without that scope would work. Furthermore, anything that uses () scope would work, anywhere.

So, now, I have seen something substantial here, and this is where I would say what I like to see, and would not tell people not closed minded.
This is where I concede my method has a hole. I am going to point that out, but I praise you for getting me to see it, not like other argument before by you or others. This is the meat of the discussion:

if (..) {
myvar = @autoCollect getResource();
} else {
myvar = ...
}

//do something with my var.

you can see that in the "if" block, the resource was already collected. That's why the try block was introduced to indicate where to close the resource.
Now that we have a good concrete point of the issue, I can revised it like this, not ideal, and may need refine, but it would be like:

somescope {
if (..) {
myvar = @autoCollect(somescope) getResource();
} else {
myvar = ...
}
}

Basically, add a label to scope. The issue here will be collision of something like this:

if {

}

if is not a label. So, I think we just need a scope annotation:



@scope ("somescope")
if (..) {
myvar = @autoCollect(somescope) getResource();
}
If the scope annotation is not found in any current or ancestor's block, then the 1st scope will be used. The same applied if the scope name is not specified in the auto collect annotation.










 
Wouter Oet
Bartender
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What needs to be kept in mind is that Automatic Resource Management was developed for making handling resources easy. Adding conditional collection of resources and variable scope in which that happens in going totally against that. What would make it complex again.
 
Bartender
Posts: 3225
34
IntelliJ IDE Oracle Spring Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Better to have a look at what Joshua Bloch proposed regarding this: http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html and the discussions which took place after this proposal.

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic