what platform do you code on?

[timjowers]

Not really... just identify any obvious front runners... linux mostly
because I am developing on FreeBSD so that is covered and I already
have vista installed and for the purposes of this product that is
close enough to for testing purposes to XP (I can run it in XP compat
mode)... beyond that I was just figuring out what jvm to compile for
and it looks like 1.5 is pretty safe (I use 1.6 for development) and
what IDE's to write plugins for (with eclipse and nb being the only
canidates)

I attended a Borland talk at a JUG this summer where it was stated 80%
of Java projects still run on 1.4. I know that is the case for the 3
major clients I've worked with over the last 3 years.

Fedora 8 at home and work. RHEL, Solaris, XP at work. 1.4 and 1.5.
Major app is BEA WebLogic 8.1 on 1.4 but nobody here uses WebLogic
Workshop. A few use netbeans or others but most use Eclipse. Whatever
version we want. Usually the latest. I know my prior client used WSAD
but maybe they have moved on to Eclipse now. WSAD had an integrated
queue tester and integrated wsdl2java tools and ws test tools.

I've seen and do little to no cmd line Java dev.

Tim

 

[Aryeh M. Friedman]

I'd never heard that before. Are you certain?

I will have to look it up to be sure but I think it is a java-->native
compilor implemented for the gcc framework supporting java 1.2

 

[Joshua Cranmer]

1. Do you use Linux to develop Java? If so what distro and JDK
version?

My current major project is being developed on Gentoo Linux using JDK 6;
I also use Debian Linux with JDK 6.

2. Do you use FreeBSD to develop Java? If so what version (i386 or
amd64?) and what JDK version? Do you use JavaVMWrapper from ports?
No....

3. Do you use Windows (XP or Vista) to develop Java? If so what
version and what version of the JDK?

Windows XP Home with JDK 5 or 6; I haven't touched my Windows for
development in so long that I honestly can't remember.

4. Do you use Eclipse? If so what version and on what OS's?

5. Do you use NetBeans? If so what version on what OS's?

No, no.

6. Do you use command line based Java development? If so on what OS's
and what command shell do you use?

I mostly stick with bash, vim, and exuberant-ctags for all development
needs. On Windows, I use jEdit with the Console plugin as the command shell.

 

[Qu0ll]

1. Do you use Linux to develop Java? If so what distro and JDK
version?

Yes. Fedora 8 and RHEL 5.1 plus latest JSE 6.

2. Do you use FreeBSD to develop Java? If so what version (i386 or
amd64?) and what JDK version? Do you use JavaVMWrapper from ports?
No.

3. Do you use Windows (XP or Vista) to develop Java? If so what
version and what version of the JDK?

Yes. Vista x64 and XP plus latest JSE 6.

4. Do you use Eclipse? If so what version and on what OS's?

Yes. Vista x64. This was my princial development environment but now I
have switched to NetBeans 6.0.

5. Do you use NetBeans? If so what version on what OS's?

Yes. NB 6.0 on Vista x64.

6. Do you use command line based Java development? If so on what OS's
and what command shell do you use?

Never need to.

--
And loving it,

-Q
_________________________________________________
(e-mail address removed)
(Replace the "SixFour" with numbers to email me)

 

[Lew]

I attended a Borland talk at a JUG this summer where it was stated 80%
of Java projects still run on 1.4. I know that is the case for the 3
major clients I've worked with over the last 3 years.

That's certainly true where I work. Some of the applications are starting to
migrate to Java 5 (and in the nick of time, too).

 

[Lew]

I will have to look it up to be sure but I think it is a java-->native
compilor implemented for the gcc framework supporting java 1.2

Yes, it is, and I knew that. I had never heard that OpenOffice required it.
GCJ is well-nigh unusable if you are used to real Java environments.

 

[Lew]

Lew schreef:

No. But if I mark it for uninstall in the package manager, it complains
about missing dependencies for ooffice. The first ‘it’ is
java-1_4_2-gcj-compat. Reading the below, I think it is because I am on
a 64-bit architecture and somehow, Yast thinks Sun’s java6 does not
provide a 64-bit version, though it does. There are some problems
there, e.g. it is also troublesome to deinstall java-1_5_0-sun and set
java-1_6_0-sun instead, I had to run update-alternatives --config=java
to fix broken links afterwards. And of course, no Firefox plugin, but
that is Sun’s issue.

I use Fedora 7. I had all sorts of problems with GCJ artifacts getting in the
way of my real Java code and dependencies for a while. Finally I broke out
the alternatives system and ruthlessly replaced all the GCJ links with
near-equivalents from a real Java. No worries.

 

[Aryeh M. Friedman]

I use Fedora 7. I had all sorts of problems with GCJ artifacts getting in the
way of my real Java code and dependencies for a while. Finally I broke out
the alternatives system and ruthlessly replaced all the GCJ links with
near-equivalents from a real Java. No worries.

Out of courosity are there any decent java to native compilors that
are:

a) portable as to what platforms the compilor will run on
b) Fully support 1.5+
c) Output x86 (any other processor is a plus) code
d) Allow for multi lang mixing in the same executable

 

[Martin Gregorie]

I use Fedora 7. I had all sorts of problems with GCJ artifacts getting
> in the way of my real Java code and dependencies for a while.

Finally > I broke out the alternatives system and ruthlessly replaced
all the

> GCJ links with near-equivalents from a real Java. No worries.
>

Snap. I'm certain using the alternatives is a good solution to avoiding
the gcj problems, but how well will it survive a clean install in FC8? I
ask because I only use alternatives to replace Sendmail with Postfix and
don't understand its internals.

I use another approach. I don't claim my solution is the best, but it
only requires minimal work (copying one file, replacing one symlink) to
reinstate the JDK after a fresh Linux install, e.g the upcoming move
from FC7 to FC8:

- the precondition is that /home must be in a separate partition from
those that contain the the system. This means that I can reformat
the partitions that will contain Linux (/, /boot, /var, /usr) without
losing files I've created or installed under /home.

- I installed the Sun Java JDK and associated stuff (ant, JavaMail,
etc.) in /home/java. /usr/java is a symlink that points to /home/java.

- I put a file, java.sh, in /etc/profile.d which sets up the
classpath, etc. to refer to the Sun JDK. On every login this will
be found and run by the /etc/profile script. I keep a copy of java.sh
in a directory under /home

- That left the annoyance that, unlike FC6, in FC7 the gcj commands
(java, javac, etc) have been put in /usr/bin, so I made sure that
java.sh puts the java JDK before /usr/bin in the default PATH.

- After a fresh install I copy java.sh into /etc/profile.d and recreate
the /usr/java symlink. Job done: Java is back how I want it.

 

[Arne Vajhøj]

Out of courosity are there any decent java to native compilors that
are:

a) portable as to what platforms the compilor will run on
b) Fully support 1.5+
c) Output x86 (any other processor is a plus) code
d) Allow for multi lang mixing in the same executable

I doubt it.

It would require a lot of effort to create and there would
probably be little interest.

The people who argue "if Java were compiled to native it would
run so much faster" should check the calendar - it says 2007 not
1997 !

Arne

 

[Aryeh M. Friedman]

I doubt it.

It would require a lot of effort to create and there would
probably be little interest.

The people who argue "if Java were compiled to native it would
run so much faster" should check the calendar - it says 2007 not
1997 !

Arne

If your intending to true systems level coding it is needed. The
other thing is having true executables that don't need the JRE would
be a good thing if you ask me

 

[Andrew Thompson]

Aryeh M. Friedman wrote:
...

If your [sic] intending to true systems level coding it is needed. ..

What is "true systems level coding"?
What is "*false* systems level coding"?

 

[Aryeh M. Friedman]

Aryeh M. Friedman wrote:

..

If your [sic] intending to true systems level coding it is needed. ..

What is "true systems level coding"?

Something that is below the JRE's services (like GC)... namely one of
my long terms is a Java OS (with just enough assembly to fake/simulate
ptr's and other things that require fixed addr operations)

What is "*false* systems level coding"?

Stuff that assumes the presence of a JRE like substraite

 

[Arne Vajhøj]

If your intending to true systems level coding it is needed.

If you need to interact with certain OS specific calls
then you can use JNI. Yes - the JNI way is a bit cumbersome,
but that cumbersomeness for a few apps can not really
justify a huge effort.

The
other thing is having true executables that don't need the JRE would
be a good thing if you ask me

You will need:
- all the standard Java API classes
- something providing GC
- something that handles dynamic byte code generation

Basically you need the entire JRE code to get the entire
JRE functionality.

Arne

 

[Aryeh M. Friedman]

If you need to interact with certain OS specific calls
then you can use JNI. Yes - the JNI way is a bit cumbersome,
but that cumbersomeness for a few apps can not really
justify a huge effort.

bootable code is a plus... the idea for the OS is just enough JNI to
get around adding ptrs to the lang and writting an OS based on the
resulting model

You will need:
- all the standard Java API classes
- something providing GC
- something that handles dynamic byte code generation

All of which can in theory be provided by 100% java code assuming the
above about ptrs.

 

[Lew]

bootable code is a plus... the idea for the OS is just enough JNI to
get around adding ptrs to the lang and writting an OS based on the
resulting model


All of which can in theory be provided by 100% java code assuming the
above about ptrs.

What you want is C.

 

[Aryeh M. Friedman]

What you want is C.

Not portable enough for what I have in mind, basically except for
stuff that absulutly must use fixed addrs ptrs are not needed and I
want to make them as hard as possible to use to discourage non-device
drive use of them... also the design pretty much forces an OO lang and
C++ has some features that make it the wrong choice (for example how
it implements generics is a piece of crap) and the lack of reflection
is a show stopper (same for C actually)

 

[Lew]

Snap. I'm certain using the alternatives is a good solution to avoiding
the gcj problems, but how well will it survive a clean install in FC8? I
ask because I only use alternatives to replace Sendmail with Postfix and
don't understand its internals.

I use another approach. I don't claim my solution is the best, but it
only requires minimal work (copying one file, replacing one symlink) to
reinstate the JDK after a fresh Linux install, e.g the upcoming move
from FC7 to FC8:

- the precondition is that /home must be in a separate partition from
those that contain the the system. This means that I can reformat
the partitions that will contain Linux (/, /boot, /var, /usr) without
losing files I've created or installed under /home.

- I installed the Sun Java JDK and associated stuff (ant, JavaMail,
etc.) in /home/java. /usr/java is a symlink that points to /home/java.

- I put a file, java.sh, in /etc/profile.d which sets up the
classpath, etc. to refer to the Sun JDK. On every login this will
be found and run by the /etc/profile script. I keep a copy of java.sh
in a directory under /home

- That left the annoyance that, unlike FC6, in FC7 the gcj commands
(java, javac, etc) have been put in /usr/bin, so I made sure that
java.sh puts the java JDK before /usr/bin in the default PATH.

- After a fresh install I copy java.sh into /etc/profile.d and recreate
the /usr/java symlink. Job done: Java is back how I want it.

alternatives works by creating symlinks to what you want. You can override
all the little /usr/bin/ links with --slave options to the alternatives command.

So in my case, /usr/java/java is always a symlink to the current JDK
installation ($JAVA_HOME), or at least the one in which I'm currently interested.

# alternatives --install /usr/java/java jdk /opt/java/jdk1.6.0_03-32 1603 \
--slave /usr/java/jre jre /opt/java/jdk1.6.0_03-32/jre

Right now, "1603" is the highest number for any "jdk" alternative, so it's the
default when in "automatic" mode.

I replace all the /usr/bin symlinks thus:

# ln -s /usr/java/java/bin/java /usr/bin/java
# ln -s /usr/java/java/bin/javac /usr/bin/javac
# ln -s /usr/java/java/bin/javadoc /usr/bin/javadoc
# ln -s /usr/java/java/bin/jar /usr/bin/jar
# ln -s /usr/java/java/bin/javaws /usr/bin/javaws
# ln -s /usr/java/java/bin/jarsigner /usr/bin/jarsigner
# ln -s /usr/java/java/bin/javah /usr/bin/javah
# ln -s /usr/java/java/bin/appletviewer /usr/bin/appletviewer
# ln -s /usr/java/java/bin/rmic /usr/bin/rmic

When I want to use a different JDK, I use

alternatives --set jdk /opt/java/ibm-java2-i386-60

This puts alternatives into "manual" mode and forces the JDK to the desired one.

All the other symlinks follow perforce.

# alternatives --display jdk
jdk - status is auto.
link currently points to /opt/java/jdk1.6.0_03-32
/opt/java/jdk1.5.0_13 - priority 1513
slave jre: /opt/java/jdk1.5.0_13/jre
/opt/java/jdk1.6.0_03 - priority 1600
slave jre: /opt/java/jdk1.6.0_03/jre
/opt/java/jdk1.6.0_03-32 - priority 1603
slave jre: /opt/java/jdk1.6.0_03-32/jre
/opt/java/ibm-java2-i386-60 - priority 600
slave jre: /opt/java/ibm-java2-i386-60/jre
Current `best' version is /opt/java/jdk1.6.0_03-32.

 

[Lew]

Not portable enough for what I have in mind,

What you said you had in mind was systems-level coding, which is inherently
non-portable.

 

[Aryeh M. Friedman]

What you said you had in mind was systems-level coding, which is inherently
non-portable.

For NDA reasons I can't discuss the exact details but even though this
is true at the absolute lowest levels (perhaps a few hundred lines of
Asm) everything else in the design is portable and needs to be