... and included tools turned on, it can consume up ot 385MB of RAM. For quick and dirty tasks or when working with just a handful of classes, I use TextPad. It recognizes Java syntax and has built in support for compiling and running a small app. For everything else, I use Eclipse because it's free and has all the tools you need. I love IntelliJ - very intuitive, but it's not free.

... to load classes. Often the class names are computed at runtime and not visible in some binary. I'm happy not providing a 100%% solution, people can always add extra depends. The idea is just to provide the simple cases. Reflection isn't that common. Another problem is that very often different jars provide classes in the same namespace. Which package do you want to put into ...

... classes. Often the class names are computed at runtime and not visible in some binary. I'm happy not providing a 100%% solution, people can always add extra depends. The idea is just to provide the simple cases. Reflection isn't that common. Reflection is more common then you might think. Another problem is that very often different jars provide classes in ...

... Thu May 03 00:00, Paul Cager wrote: Thanks for submitting this idea - you've reawakened my interest in compiling a "Java Packagers Wishlist"! I think the idea of writing a program to determine Jar dependencies is a good ... without the need for any user "tweaking". But I think your idea would work very well if integrated into "dh_make". The ...

... a --prefer= parameter? Matt Thanks for submitting this idea - you've reawakened my interest in compiling a "Java Packagers Wishlist"! I think the idea of writing a program to determine Jar dependencies is a good one, ... without the need for any user "tweaking". But I think your idea would work very well if integrated into "dh_make". The expectation of ...

...I'm just not sure how feasible it is to make it sufficiently robust for all cases. On the other hand quite a large proportion of Java packages are near-trivial, and could benefit from your idea. Maybe all you need to do is rename it as "dh_simplejavadeps" (for example), and let the packager decide if it is appropriate. Even with cdbs the maintainer would have to explicitly specify the use...

...the other hand quite a large proportion of Java packages are near-trivial, and could benefit from your idea. Maybe all you need to do is rename it as "dh_simplejavadeps" (for example), and let the ... the maintainer would have to explicitly specify the use of ${java:Depends}. I really like the idea. I just wonder how good it will work in the real world. Would you want to attempt ...

I've just setup binfmt_misc to execute jar files regardless of extension. I have an ITP on a package to do this (#423081) and wondered A. if this is something which people think is a good idea and B. what the policy would then be on installing the jars. There are two options I can see, either installing them into /usr/share/java per policy as executable and with the .jar extension and then ...

Hi. I maintain various GPL programs that aren't in Debian, but which are available as .deb packages from http://software.jessies.org/ and I was wondering if anyone here had any good ideas about our Depends: lines. Looking for a solution to my perceived problem (which I'll get to in a moment), I came across the following on this list, which led me to believe this would be a good ...

... to use it. You are right... In the meantime Michael Koch provides a binary maven package that can be used for developing these features. His work couldn't be used for that at the moment because the maven binary package will never reach 'main' as is. And we can't relay on contrib or non-free package to build all our packages. Anyway, it's a cool idea. -- Arnaud Vandyck