java-devel July 2014

java-devel@lists.fedoraproject.org

11 participants
7 discussions

Apache TomEE rpms
by David Blevins 12 Feb '16

12 Feb '16

Hello Fedora/Java people, First post to the list, so hello! We've crafted up some RPMs for Apache TomEE and are looking to contribute them to Fedora if at all possible. * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-jaxrs-1.5.2-1.noarc… * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-webprofile-1.5.2-1.… * http://dl.bintray.com/hgomez/devops-incubator-rpm/tomee-plus-1.5.2-1.noarch… I haven't much of an idea on what the process for this might be. Dan Allen (RedHat) pointed us this way. Hoping someone here might have insight, even if that is some other list. -David

5 5

/usr/lib/jni support in Fedora
by Florian Weimer 04 Aug '14

04 Aug '14

As far as I can tell, currently, System.loadLibrary() is mostly unusable for Java libraries because they cannot influence the library search path. If you want to transparently load a DSO, you need to use System.load() and hard-code the path. This probably means patching upstream sources. Debian patches the default search path so that System.loadLibrary() searches /usr/lib/jni for DSOs with native code. This means that classes which call System.loadLibrary() just work, assuming that the Debian package installs its DSOs into /usr/lib/jni. Can we do something similar in Fedora? We probably want /usr/lib/jni and /usr/lib64/jni, for consistency with the rest of the system. The upstream default search path starts with "/usr/java/packages/lib/amd64" (and variants for other architectures), but this isn't mentioned in the Fedora guidelines. I'm also not sure if we want to use this file system location because it doesn't look particularly FHS-compliant. But the proprietary JDKs could install a symlink there so that /usr/lib{,64}/jni is searched as well. -- Florian Weimer / Red Hat Product Security

4 5

Re: [fedora-java] /usr/lib/jni support in Fedora
by Florian Weimer 30 Jul '14

30 Jul '14

On 07/29/2014 01:17 PM, Jiri Vanek wrote: > On 07/29/2014 01:05 PM, Florian Weimer wrote: >> As far as I can tell, currently, System.loadLibrary() is mostly >> unusable for Java libraries because >> they cannot influence the library search path. If you want to >> transparently load a DSO, you need to >> use System.load() and hard-code the path. This probably means >> patching upstream sources. >> >> Debian patches the default search path so that System.loadLibrary() >> searches /usr/lib/jni for DSOs >> with native code. This means that classes which call >> System.loadLibrary() just work, assuming that >> the Debian package installs its DSOs into /usr/lib/jni. >> >> Can we do something similar in Fedora? We probably want /usr/lib/jni >> and /usr/lib64/jni, for >> consistency with the rest of the system. > > Then the most simple way is to provide symlinks in > java-1.{7,8}.0-openjdk spec > > from /usr/lib/jni | /usr/lib64/jni, -to> /usr/lib/jvm/java..../... ? (Cc:ing the mailing list again.) Is it a good idea to install files from RPMs through a symbolic link? I suspect it's not, which would mean we'd have to use the upstream default "/usr/java/packages/lib/amd64" in spec files (probably using a macro). If that path is acceptable, it would be fine with me as well, but it looks a bit ugly to me. It certainly has the advantage of being compatible with both the proprietary JDKs and the Debian packaging (which keeps this search path entry, it only adds /usr/lib/jni). -- Florian Weimer / Red Hat Product Security

4 9

Re: [fedora-java] /usr/lib/jni support in Fedora
by Florian Weimer 29 Jul '14

29 Jul '14

On 07/29/2014 04:09 PM, Christopher wrote: > As far as I can tell, currently, System.loadLibrary() is mostly > unusable for Java libraries because they cannot influence the > library search path. If you want to transparently load a DSO, you > need to use System.load() and hard-code the path. This probably > means patching upstream sources. > > > To be clear, you can use LD_LIBRARY_PATH, or -Djava.library.path to > influence the search path in any launch scripts, just like you'd control > the bootstrap classpath in those same scripts. By choosing to use > System.loadLibrary(), instead of System.load(), the developer has > already decided to defer any influence over the search path to something > external, like a script (or the system's ld cache), so I've not found > this to be much of a limitation. I'm sure there are arguments against > doing this, but it is imprecise to say that it's not possible. It's not possible from a library (unless you provide your own class loader, as David explained). A library cannot influence how the launcher is invoked. > Debian patches the default search path so that System.loadLibrary() > searches /usr/lib/jni for DSOs with native code. This means that > classes which call System.loadLibrary() just work, assuming that the > Debian package installs its DSOs into /usr/lib/jni. > > > Forgive my ignorance, but what exactly is wrong with just using > /usr/lib[64], and how does putting them in a separate directory from > other system shared libraries offer any greater degree of control? These Java DSOs are not for general system use. Programmers are not supposed to link against them, for instance. ldconfig processing of files in /usr/lib{,64} is potentially harmful as well. The (non-Java) Fedora Packaging Guidelines seem to imply to me that such DSOs should not be put into /usr/lib{,64}, but the wording isn't completely clear. See <http://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages> and the paragraph starting with “As an additional complication, some software generates unversioned shared objects which are not intended to be used as system libraries.” The Debian Policy does not explicit prevents using /usr/lib, either but I assume that putting the JNI DSOs there (or the equivalent multi-arch directory) would be problematic. -- Florian Weimer / Red Hat Product Security

1 0

Locating jni.h
by Florian Weimer 29 Jul '14

29 Jul '14

What's the recommended way to locate jni.h? There was a proposal to update the packaging guidelines, but it hasn't been applied: https://lists.fedoraproject.org/pipermail/packaging/2009-May/005984.html Is this information still current? -- Florian Weimer / Red Hat Product Security

3 2

Request for help packaging PyCharm for the Fedora Workstation
by Christian Schaller 09 Jul '14

09 Jul '14

Hi everyone, I am part of the Fedora Workstation working group and and one application I would love to have included and easily available for the workstation is PyCharm (http://www.jetbrains.com/pycharm/) It is probably the best Python IDE available currently and thus can be a great tool for python developers on our platform. Especially with the rising importance of OpenStack I would love it if the Fedora Workstation would be able to offer this application. It also supports GTK3 module imports so it is a also great choice for desktop Python development. Despite being a Python IDE it is written in Java, so I am asking if there are any volunteers on this list willing to help with packaging it. I exchanged some emails with Stanislav Ochonicky and Mikolaj Izdebski and they suggested I send an email to this list requesting volunteers. There are some licensing challenges with PyCharm as can be seen in this bug tracker : http://youtrack.jetbrains.com/issue/PY-11008 But Stanislav had a quick look and it seems we should have most of the libraries covered already: javahelp - Fedora has javahelp2 oromatcher - Fedora has jakarta-oro sqljet - packaged in Fedora svnkit - packaged in Fedora Mikolaj has offered to help, but he doesn't want to be the sole maintainer, so I am hoping to get some more volunteers here. Myself and Kalev Lember are also both available to help anyway we can, and if someone is willing to work with us on the core packaging we can handle creating appdata files etc., for PyCharm. Sincerely, Christian Schaller

3 2

Fwd: [Bug 1115920] New: FTBFS on AArch64: java.lang.OutOfMemoryError: Java heap space
by Orion Poplawski 07 Jul '14

07 Jul '14

It appears that on the aarch64 koji builders: uintx MaxHeapSize := 268435456 {product} (see http://arm.koji.fedoraproject.org//work/tasks/8913/2478913/build.log) compared to 2623537152 (x86_64), 1073741824 (i686), 268435456 (armv7hl) (http://koji.fedoraproject.org/koji/taskinfo?taskID=7114637) Is this just a side-effect of the RAM size of the builders or something else? Seems like this might cause issues elsewhere as well and am wondering if a proper fix belongs elsewhere. - Orion -------- Original Message -------- Subject: [Bug 1115920] New: FTBFS on AArch64: java.lang.OutOfMemoryError: Java heap space Date: Thu, 03 Jul 2014 10:43:40 +0000 From: bugzilla(a)redhat.com To: orion(a)cora.nwra.com https://bugzilla.redhat.com/show_bug.cgi?id=1115920 Bug ID: 1115920 Summary: FTBFS on AArch64: java.lang.OutOfMemoryError: Java heap space Product: Fedora Version: rawhide Component: vtk Assignee: axel.thimm(a)atrpms.net Reporter: mjuszkie(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: axel.thimm(a)atrpms.net, fdc(a)fcami.net, jonathan.underwood(a)gmail.com, mrceresa(a)gmail.com, orion(a)cora.nwra.com Description of problem: Building of vtk on AArch64 fails with: The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: Java heap space at com.sun.tools.javac.code.Scope$ImportScope.makeEntry(Scope.java:526) at com.sun.tools.javac.code.Scope.enter(Scope.java:220) at com.sun.tools.javac.code.Scope.enter(Scope.java:202) at com.sun.tools.javac.code.Scope$StarImportScope.importAll(Scope.java:549) at com.sun.tools.javac.comp.MemberEnter.importAll(MemberEnter.java:163) at com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:549) at com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571) at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:447) at com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:526) at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518) at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:435) at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038) at com.sun.tools.javac.code.Symbol.complete(Symbol.java:560) at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1024) at com.sun.tools.javac.comp.Enter.complete(Enter.java:497) at com.sun.tools.javac.comp.Enter.main(Enter.java:475) at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:985) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860) at com.sun.tools.javac.main.Main.compile(Main.java:523) at com.sun.tools.javac.main.Main.compile(Main.java:381) at com.sun.tools.javac.main.Main.compile(Main.java:370) at com.sun.tools.javac.main.Main.compile(Main.java:361) at com.sun.tools.javac.Main.compile(Main.java:56) at com.sun.tools.javac.Main.main(Main.java:42) Wrapping/Java/CMakeFiles/VTKJavaClasses.dir/build.make:1952: recipe for target 'java/javac_stamp.txt' failed make[2]: Leaving directory '/builddir/build/BUILD/VTK-6.1.0/build' CMakeFiles/Makefile2:22685: recipe for target 'Wrapping/Java/CMakeFiles/VTKJavaClasses.dir/all' failed make[2]: *** [java/javac_stamp.txt] Error 3 make[1]: *** [Wrapping/Java/CMakeFiles/VTKJavaClasses.dir/all] Error 2 make: *** [all] Error 2 make[1]: Leaving directory '/builddir/build/BUILD/VTK-6.1.0/build' Makefile:120: recipe for target 'all' failed Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. build package on aarch64 (use "arm-koji build rawhide") 2. watch it fail 3. Actual results: package fails to build Expected results: package builds Additional info: Increasing Java heap size with "JAVA_TOOL_OPTIONS=-Xmx2048m make %{?_smp_mflags}" helps. 2048m size was randomly selected. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=dfeLMxOcug&a=cc_unsubscribe

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel July 2014