RFS: httpcomponents-client 4.1.1-2 (add OSGi metadata + maintenance)
Dear java packagers, I am looking for a sponsor for package "httpcomponents-client". * Package name: httpcomponents-client Version : 4.1.1-2 Upstream Author : Apache Software Foundation * URL : http://hc.apache.org/httpcomponents-client/index.html * License : Apache-2.0 Section : java It builds those binary packages: libhttpclient-java - HTTP/1.1 compliant HTTP agent implementation libhttpmime-java - HTTP/1.1 compliant HTTP agent implementation - mime4j extension I let maven-bundle-plugin generate OSGi metadata for JAR library (new dependency of eclipse-mylyn 3.7.0), updated Standards-Version and fixed some lintian warnings. Package source can be accessed at pkg-java git repository: http://anonscm.debian.org/gitweb/?p=pkg-java/httpcomponents-client.git I would be glad if someone uploaded this package for me. Kind regards, Jakub Adam -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f74d876.4040...@ktknet.cz
Re: New work on java-package
On 03/27/2012 10:12 AM, Emmanuel Bourg wrote:
> Le 20/03/2012 12:41, Andrew Haley a écrit :
>> Comments like this are infuriating. I want to make OpenJDK
>> competitive, but I can't do anything with this because I don't know
>> what you're talking about. I can't reproduce the problem, so I can't
>> fix it. Is there anything more frustrating than being told there's
>> a problem, but not what it is? It's like something out of Kafka.
>
> There are indeed issues with OpenJDK that do not exist with the Oracle
> JRE. Here is an issue I reported recently:
>
> Tomcat with authbind on OpenVZ throws "SocketException: Cannot allocate
> memory" (works with sun-java6)
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659293
>
> That's the only hurdle that prevents me from migrating my production
> servers to OpenJDK (and the reason why I contributed some changes to
> java-package).
I think the problem is in authbind: it only supports IPv4.
Try this:
$ authbind --depth 2 java -Djava.net.preferIPv4Stack=true ListenTest
ServerSocket[addr=localhost/127.0.0.1,port=0,localport=80]
Andrew.
import java.net.*;
public class ListenTest {
public static void main(String[] args)
throws Throwable {
ServerSocket s = new ServerSocket(80, 0,
InetAddress.getByName("localhost"));
System.out.println(s);
}
}
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f745c75.1020...@redhat.com
Re: New work on java-package - Java2D back-end overview
On Thu, Mar 29, 2012 at 5:03 AM, Xerxes Rånby wrote: > 2012-03-20 21:10, Matthias Klose skrev: >> On 20.03.2012 13:48, Barry Hawkins wrote: >>> On 3/20/12 7:41 AM, Andrew Haley wrote: On 03/19/2012 07:11 PM, Barry Hawkins wrote: > The focus of my message was to point out the need for users of Debian and > its derivatives to be able to install an official JRE or JDK from Oracle. > If I gave the impression of criticizing OpenJDK, my apologies; that was > not the intent. > > Like so many others, I'll be happy when OpenJDK is the de facto choice > for all things based on the JVM. Currently, high performance and > graphical applications still see significant improvement when using the > Oracle JRE/JDK. Actual specific problems with performance are something we can address. Core performance differences are very few: It's the same VM. Oracle does have a few magic optimized classes we don't have, and they have a proprietary font renderer. We don't use Oracle's plugin. There isn't much else. >> >> CCing Xerxes here. He did point out that turning on another renderer does >> improve performance in some cases. > > OpenJDK currently contains 4+ different Java2D renderers, of course only one > are enabled by default. > I will summary the current OpenJDK Java2D situation: > > The well tested ones: > 0. The Oracle JavaSE contains the Ductus Java2D renderer this part have not > been open sourced by Oracle. So we cant use it, this part got replaced in > OpenJDK by "pisces" from phoneme. > > 1. In OpenJDK we the Pisces Java2d rasterizer enabled by default, it work > but its kind of slow and revert to software rendered fall-back for most > operations, unfortunately. > http://openjdk.java.net/groups/2d/ > > The well tested but found not to be working one: > 2. The OpenGL backend, java -Dsun.java2d.xrender=True > This back-end have been included all the time into OpenJDK and also found > in the Oracle JavaSE builds, > It work on GNU/Linux desktop OpenGL hardware. > The main reason why it never got enabled by default are the poor support > for the buggy/fixed-pipeline OpenGL GPU drivers. > > The new kids: > 3a. The Xrender backend created by, Clemens Eisserer, can be enabled at > runtime by passing java -Dsun.java2d.xrender=True > (Use True for verbose output and true for non-verbose output) > This backend makes use of the Xrender GPU driver support that are actually > quite good on Linux systems, For networked X11 applications this back-end > really flies! > Since this back-end have been merged you can simply switch it on at > runtime to test its performance. > http://openjdk.java.net/projects/xrender/ > 3b. The Xrender back-end + jules This part combines the Xrender back-end with > a tweaked Cairo rasterizer, Clemens never had time to clean up the Cairo > patches so this variant only exist as a secret addon > by using the Xrender backend and dropping in the libjules into the JRE. > http://linuxhippy.blogspot.se/2009/11/jules-cairo-binding-001-release.html > > The future: > 4. The pluggable Caciocavallo back-end, created by Mario Torre and Roman > Kenkke, Cacio are a portability layer that is well integrated into OpenJDK > and enables Java2D on new platforms, > the only thing missing in OpenJDK are the new compiled plug-in "peers". > http://openjdk.java.net/projects/caciocavallo/ > By compiling a peer you can get Java2D running on many new interesting > combinations like this Cacao-web HTML5 backend. > http://linuxhippy.blogspot.se/2011/07/prebuilt-demo-release-available.html > > 5. The JogAmp JOGL GLG2D back-end, this new backend under development make > use of the well tested JogAmp JOGL 2.0 library to render hardware accelerated > using the latest OpenGL 2 GPU drivers. > Since JogAmp know how to workaround the many bugs in the OpenGL drivers > this back-end can become a fast, up to 10x improvement, and stable for all > Java2D use. > http://brandonborkholder.github.com/glg2d/ > > Without a testing framework its hard to know when the new back-ends 3a.-5. > are stable and ready to replace the slow 1. Pisces Java2D rasterizer in > OpenJDK. > > Cheers > Xerxes [...] Xerxes, This is excellent information, thanks so much for putting it together. I will try some of these alternatives today. Is there any guidance on what information is good to collect when providing feedback to the OpenJDK project about graphical application performance? General impressions about responsiveness seem too subjective to be of any use. -- Barry Hawkins twitter: @barryhawkins blog: http://barryhawkins.com/blog/ linkedin: http://www.linkedin.com/in/barryhawkins -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAN2i5Pf0tK9S=HoRZRjg=ozere90dpxikaomu6uwa3ixh3...@mail.gmail.com
Re: New work on java-package - Java2D back-end overview
2012-03-29 13:03, Xerxes Rånby skrev: > The well tested but found not to be working one: > 2. The OpenGL backend, java -Dsun.java2d.xrender=True Typo, use -Dsun.java2d.opengl=True here. (Use True for verbose output and true for non-verbose output) > This back-end have been included all the time into OpenJDK and also found > in the Oracle JavaSE builds, > It work on GNU/Linux desktop OpenGL hardware. > The main reason why it never got enabled by default are the poor support > for the buggy/fixed-pipeline OpenGL GPU drivers. Cheers Xerxes -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f74461f.2020...@zafena.se
Re: New work on java-package - Java2D back-end overview
2012-03-20 21:10, Matthias Klose skrev: > On 20.03.2012 13:48, Barry Hawkins wrote: >> On 3/20/12 7:41 AM, Andrew Haley wrote: >>> On 03/19/2012 07:11 PM, Barry Hawkins wrote: The focus of my message was to point out the need for users of Debian and its derivatives to be able to install an official JRE or JDK from Oracle. If I gave the impression of criticizing OpenJDK, my apologies; that was not the intent. Like so many others, I'll be happy when OpenJDK is the de facto choice for all things based on the JVM. Currently, high performance and graphical applications still see significant improvement when using the Oracle JRE/JDK. >>> >>> Actual specific problems with performance are something we can address. >>> Core performance differences are very few: It's the same VM. Oracle does >>> have a few magic optimized classes we don't have, and they have a >>> proprietary font renderer. We don't use Oracle's plugin. There isn't much >>> else. > > CCing Xerxes here. He did point out that turning on another renderer does > improve performance in some cases. OpenJDK currently contains 4+ different Java2D renderers, of course only one are enabled by default. I will summary the current OpenJDK Java2D situation: The well tested ones: 0. The Oracle JavaSE contains the Ductus Java2D renderer this part have not been open sourced by Oracle. So we cant use it, this part got replaced in OpenJDK by "pisces" from phoneme. 1. In OpenJDK we the Pisces Java2d rasterizer enabled by default, it work but its kind of slow and revert to software rendered fall-back for most operations, unfortunately. http://openjdk.java.net/groups/2d/ The well tested but found not to be working one: 2. The OpenGL backend, java -Dsun.java2d.xrender=True This back-end have been included all the time into OpenJDK and also found in the Oracle JavaSE builds, It work on GNU/Linux desktop OpenGL hardware. The main reason why it never got enabled by default are the poor support for the buggy/fixed-pipeline OpenGL GPU drivers. The new kids: 3a. The Xrender backend created by, Clemens Eisserer, can be enabled at runtime by passing java -Dsun.java2d.xrender=True (Use True for verbose output and true for non-verbose output) This backend makes use of the Xrender GPU driver support that are actually quite good on Linux systems, For networked X11 applications this back-end really flies! Since this back-end have been merged you can simply switch it on at runtime to test its performance. http://openjdk.java.net/projects/xrender/ 3b. The Xrender back-end + jules This part combines the Xrender back-end with a tweaked Cairo rasterizer, Clemens never had time to clean up the Cairo patches so this variant only exist as a secret addon by using the Xrender backend and dropping in the libjules into the JRE. http://linuxhippy.blogspot.se/2009/11/jules-cairo-binding-001-release.html The future: 4. The pluggable Caciocavallo back-end, created by Mario Torre and Roman Kenkke, Cacio are a portability layer that is well integrated into OpenJDK and enables Java2D on new platforms, the only thing missing in OpenJDK are the new compiled plug-in "peers". http://openjdk.java.net/projects/caciocavallo/ By compiling a peer you can get Java2D running on many new interesting combinations like this Cacao-web HTML5 backend. http://linuxhippy.blogspot.se/2011/07/prebuilt-demo-release-available.html 5. The JogAmp JOGL GLG2D back-end, this new backend under development make use of the well tested JogAmp JOGL 2.0 library to render hardware accelerated using the latest OpenGL 2 GPU drivers. Since JogAmp know how to workaround the many bugs in the OpenGL drivers this back-end can become a fast, up to 10x improvement, and stable for all Java2D use. http://brandonborkholder.github.com/glg2d/ Without a testing framework its hard to know when the new back-ends 3a.-5. are stable and ready to replace the slow 1. Pisces Java2D rasterizer in OpenJDK. Cheers Xerxes -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f744189.7050...@zafena.se
Re: New work on java-package
On 03/28/2012 11:50 PM, Emmanuel Bourg wrote: > Le 28/03/2012 19:38, Andrew Haley a écrit : >> If you run >> >> strace -f -etrace=net java ... >> >> you'll be able to see the bind call that fails, and we can take it >> from there. > > Thank you for the tip, I'll give it a try. I'm not familiar with strace, > "-etrace=net" seems to be rejected. The syntax bellow is accepted, is it > the right one? > > strace -f -e trace=network java ... Yes. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f743058.6060...@redhat.com
