o Reset MAINTAINER to java@.
o Bump PORTREVISION accordingly.
PR: ports/72802
Submitted by: Jeremy Faulkner <gldisater@gldis.ca>
Approved by: maintainer no response
o Use native JDK rather than linux-sun-jdk. [2]
o Utilize WITH_MOZILLA. It provies to use mozilla or firefox. [2]
o Fix some port's bugs. [2]
o Add zip to BUILD_DEPENDS and fix build error without zip. [3]
PR: ports/72990 [1], ports/72475 [2]
Submitted by: Jeremy Faulkner <gldisater@gldis.ca> [1], [2]
Pointed out by: pointy via kris [3]
existing the Solaris base, and similarly to what happened with NSPR, made
a bad assumption on undefined behavior. This broke locking in various
places in Java, for example, causing the the debugging support to be
totally broken. It is worth someone who knows the Java codebase taking
a look to see what other things could have been broken by this on
FreeBSD 5.x+.
The assumption is that pthread_mutex_trylock(3) on a default-type
mutex will fail with EBUSY. This assumption is wrong for our
libpthread, which returns EDEADLK if the owner thread is trying to
acquire the mutex again with trylock. The behavior of performing a
locking operation on a self-locked default-type mutex is explicitly
undefined for pthread_mutex_lock(3).
The POSIX specification is still not very clear. It defines
pthread_mutex_trylock(3) in terms of pthread_mutex_lock(3) yet
does not say what the defined behavior should be for a self-locked
pthread_mutex_trylock(3) for any of the various mutex types, so it is
ambiguous whether the result is clearly undefined or clearly to return
EBUSY.
It is a one line change whether or not to make libpthread return
EDEADLK in this case, where it seems that most implementations do not.
Reference: http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html
The HotSpot code (ab)uses named enums as ints in a number of places.
The problem with this is that according the the C++ spec, the compiler
(essentially) only needs to use an integral type wide enough to hold
the values defined in the enum. Earlier versions of gcc appear to have
just used an int whether they could have got away with a narrower type
or not, hence the code worked as expected. gcc 3.4 now appears to
implement this part of the spec, so using an enum blindly as an int
causes various problems due to overflow.
In this case the enum, Bytecodes::Code, appears to be a genuine enum,
its just assumed to be wide enough to hold an arbitrary int in various
places in the code. The correct fix would be to track down all those
places in the code and fix them. Since there are quite a lot of these
places and 5.3 is close to release for now we just add a value to the
enum set to INT_MAX, forcing the compiler to use at least an int for the
type.
Sleuth work, discussion and code suggestions: peadar
The HotSpot code (ab)uses named enums as ints in a number of places.
The problem with this is that according the the C++ spec, the compiler
(essentially) only needs to use an integral type wide enough to hold
the values defined in the enum. Earlier versions of gcc appear to have
just used an int whether they could have got away with a narrower type
or not, hence the code worked as expected. gcc 3.4 now appears to
implement this part of the spec, so using an enum blindly as an int
causes various problems due to overflow.
This case is particularly bogus since the enums are merely to define
a named integral type within a class (VMReg::Name doesn't even have
any values enumerated in the declaration). So, convert these two
enums to simply be typedef'ed ints.
Sleuth work, discussion and code suggestions: peadar
condition and return NULL". Take account of the NULL in the
appropriate place (which is somewhat worrisome in itself since
ReadChunk() has always had the possibility of returning NULL).
This makes loading a font file a little more resilient to specially
crafted font data which can be used, for example, by an applet to
crash the browser plugin by triggering the assert(). Such an applet
was mentioned on Bugtraq:
http://www.securityfocus.com/archive/1/367331/2004-06-26/2004-07-02/0
and can be found at
http://www.illegalaccess.org/cms/?q=node/view/9
This change stops the browser plugin from crashing.
. Fix some warnings regarding formats in debugging printf's.
(for FreeBSD 4.x neither are defined and for FreeBSD 5.x
O_DSYNC isn't defined). This caused them to be defined to
some bogus values. In particular, O_SYNC would be defined
as 0x800, which is O_EXCL (at least on FreeBSD 4.x). The
result being that the RandomAccessFile class would fail to
open an existing file if you specified "s" as part of the mode.
Fix this by defining O_SYNC and O_DSYNC to O_FSYNC if they
aren't defined.
agree to the company's license requirement before downloading (although
the agreement mostly pertains to their software available for purchase).
PR: ports/71510
Submitted by: mitsuru at riken dot jp (maintainer)
Approved by: portmgr (implicit)
- Use LOCALBASE rather than PREFIX in RUN_DEPENDS
- Now bsd.java.mk 2.0 compliant
- Use CPIO rather than CP
- Use JAVAJARDIR and JAVASHAREDIR
- Removed pkg-plist (use dynamic plist and PORTDOCS)
- Honor NOPORTDOCS
- Honor hier(7): documentation in DOCSDIR and examples in EXAMPLESDIR [2]
- Honor "best practices for a Java library" from Porter's handbook, Java
section: JARs in JAVAJARDIR. [2]
- SIZEify
- Added 'mail' category
PR: 71235 [1]
Submitted by: Rainer Duffner <rainer@ultra-secure.de> [1]
Reviewed by: glewis [2]
Approved by: glewis (mentor)
- Now bsd.java.mk 2.0 compliant
- Use CPIO rather than CP
- Use JAVAJARDIR and JAVASHAREDIR
- Removed pkg-plist (use dynamic plist and PORTDOCS)
- Honor NOPORTDOCS
- Honor hier(7): documentation in DOCSDIR and examples in EXAMPLESDIR
- Honor "best practices for a Java library" from Porter's handbook, Java
section: JARs in JAVAJARDIR.
- Added 'devel' category
- SIZEify
Pointed out by: Rainer Duffner <rainer@ultra-secure.de> [1]
Approved by: glewis (mentor)
