aspose file tools*
The moose likes Features new in Java 7 and the fly likes Java 7 Auto Resource Collection Syntax Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Features new in Java 7
Bookmark "Java 7 Auto Resource Collection Syntax" Watch "Java 7 Auto Resource Collection Syntax" New topic
Author

Java 7 Auto Resource Collection Syntax

N Nan
Greenhorn

Joined: Apr 21, 2011
Posts: 15
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:





Wouter Oet
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

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.


"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
N Nan
Greenhorn

Joined: Apr 21, 2011
Posts: 15
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
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

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

Joined: Apr 21, 2011
Posts: 15
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.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4490
    
    8

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

Joined: Apr 06, 2010
Posts: 4490
    
    8

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

Joined: Apr 21, 2011
Posts: 15
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
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

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.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18987
    
    8

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

Joined: Apr 21, 2011
Posts: 15
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
Bartender

Joined: Oct 14, 2005
Posts: 18987
    
    8

Right. And the scientific method part?
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4490
    
    8

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

Joined: Apr 21, 2011
Posts: 15
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

Joined: Apr 06, 2010
Posts: 4490
    
    8

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

Joined: Apr 21, 2011
Posts: 15
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
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

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.
Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3097
    
  33

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.


Mohamed Sanaulla | My Blog
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Java 7 Auto Resource Collection Syntax