Biggest Flow

- Residual Graph

- Biggest Stream Lowest cut

- Ford-Fulkerson, O(E*f) f is value of biggest flow

- Edmonds-karp, O(VE^2)

  used BFS to find the path, p, from the Gf. p is shortest path from s to t


- Push & Relabel

(u,v) belongs to E, anti-parallel edge (v, u)

in residual graph

f'(u,v) is c(u,v) - f(u,v)

f'(v,u) is f(u,v). 

they are calculated dynamically based on original f(u,v)

be careful, original f(u,v) could be set to zero in the line 6

- Goldberg, O(V^2E)

- Relabel to Front



Java's Biggest Challenges


The Roundtable Summations: 11 Views on Java's Biggest ChallengesrnIndustry technologists set the agenda for Java directions in the year ahead rnby Dan Rubrnrnrnrn ... oundtable_03_06_25/rnrnrnrnAt the close of the 2003 Java Pro Technology Roundtable, held two weeks ago during JavaOne in San Francisco, participants were asked to assess the greatest challenges facing Java technology and the Java Community. Here are their replies. The participants were senior technology representatives from leading Java vendor companies. The full edited transcript of the roundtable discussion will appear in Java Pro's October 2003 issue.rnrnrnrnNeil McGovernrnDirector of Strategy, E-Business Division, SybasernIf you look at the history of Java, originally, we were concerned about performance. It was never going to be able to run fast enough to do anything useful. Do you remember those days? Then, the next problem was compatibility. We were going write once but have to test everywhere. Remember that? Well, we solved those issues; performance is not an issue in the Java world any longer, and the compatibility problem was a fallacy. rnrnNow, the big issue facing the community is ease of use. The community needs to produce a development environment that is easy to use. A lot of people around this table are doing work on that, and they better get it right because it's the major issue [holding back Java]. rnrnThe second major issue is all the technology that's being dumped into the application server. I'm worried that the integration technology that's being put into application servers may be self-defeating. Integration can't become part of a proprietary stack because the whole nature of integration is that it spans proprietary stacks. I believe we have to work very hard to keep portal and integration servers open so that they run on top of the platform, and not on top of individual proprietary pieces of technology.rnrnDavid LitwackrnSenior Vice President, NovellrnI think that there's been too much focus with Java and J2EE on technology. To paraphrase a former president, "It's about the applications, stupid." People actually buy our stuff because they want to create applications that solve business problems, and if you look at the key thing that's going on and the reason that all of us are struggling in the marketplace and the reason that people aren't buying new stuff is that IT has reached a crisis of complexity. They have too much "stuff"—they feel like it's collapsing under its own weight. And we're at that pause between architectures where the old architecture is collapsing and the new one hasn't quite taken off yet. rnrnThe second phase that is coming is in services-oriented architecture, which is a componentized approach that will allow brittle systems to become agile systems. Today, Microsoft is actually ahead in this area, not because they have better stuff but because they've positioned .Net as an SOA solution, and we [Java vendors] haven't quite succeeded in packaging together all of the pieces required for an SOA solution. Java is a better way of doing it, and as we put together all of the surrounding pieces, I think that SOA will prove to be the second-phase rocket for Java and J2EE.rnrnGraham HamiltonrnFellow and Distinguished Engineer, Sun MicrosystemsrnI think the big challenge for the Java Community is to greatly expand the developer base, to grow the number of people who can successfully use Java for all kinds of applications. This requires some change in thinking in the Java Community about the kind of APIs we develop and the tools we develop. We cannot think of this as a tools problem for [advanced] developers, but we also should try to simplify API design so it's accessible to a wider range of developer. I think there's going to be a trend that will play out over a couple of years. We have already captured the enterprise-developer market quite well; the challenge now is to go after other, perhaps larger, markets for developers of business and departmental applications.rnrnEd LycklamarnChief Architect, Quest/SitrakarnI think of J2EE as an operating system, one with growing maturity and acceptance in the industry, and you can draw analogies to other leading operating systems. While there is a lot to be done yet in terms of strengthening the platform and making it more powerful, I think the central challenge for Java is to make it easier to use. Unix won in the enterprise because of its power, not because of its ease of use. Microsoft won the desktop because of its ease of use, not because of its power. Now, we're seeing a convergence of those two worlds where we need ease of use and power at the same time, and I think that's the central challenge for J2EE and Java.rnrnDavid ChappellrnChief Technology Evangelist, Sonic SoftwarernIT professionals today are being charged with making existing IT assets work together. They have become integration architects. This has spawned a whole new category of software that is all about building an integration fabric, which is not all necessarily meant to be stacked on top of a J2EE app server. What the Java Community needs is a new model for integration that's not necessarily based on an app-server stack, which includes it but isn't built on it. The Java business integration standard of JSR 208 may help move us toward an integration platform. rnrn